SBOK - Cap 5 - Quality (Calidad)

1. La capacidad del producto o productos entregables completados para cumplir los Criterios de Aceptación y alcanzar el valor de negocio que espera el Cliente.

1. Scrum adopta un enfoque de Continuous Improvement en el que el equipo aprende de sus experiencias y del compromiso de los stakeholders
2. Cualquier cambio en los requisitos refleja los cambios en el entorno empresarial interno y externo y permiten que el equipo funcione continuamente y se adapte a alcanzar esos requisitos
3. Los incrementos durante los Sprints, esto hace que los errores o defectos sean detectados durante las pruebas de calidad repetitivas
4. Desarrollo, pruebas y documentación se completan durante el Sprint por el mismo equipo.
   1. En los entregables Done
5. La interacción entre el Scrum Team y Stakeholder asegura que se alcance niveles esperados de calidad

1. Factores de ámbito de aplicación y requisitos de calidad
   1. La necesidad del negocio que el project cumplirá
   2. La capacidad y la buena disposición de la organización para cumplir con las necesidades del negocio
   3. Las necesidades futuras y actuales de la audiencia
2. Alcance de un proyecto
   1. es la suma total de todos los incrementos del product y el trabajo necesario para desarrollar el producto final
3. Calidad
   1. es la capacidad de las entregas para cumplir con los requisitos de calidad del producto y satisfacer las necesidades del Cliente
4. Calidad y Alcance se capturan en el Prioritized Product Backlog

   Annotations:

   • En Scrum, el alcance (scope) y la calidad del proyecto son capturados en el Prioritized Product Backlog.
   1. El alcance de cada Sprint se captura en el Groom Prioritized Product Backlog (PBIs)

      Annotations:

      • El alcance de cada Sprint está determinado por la refinación de los grandes Prioritized Product Backlog Items (PBIs) en un conjunto de pequeños pero detallados User Stories que pueden ser planeados, desarrollados y verificados dentro de un Sprint.
   2. Product Owner (PO) vela que el Prioritized Product Backlog (PPB) este actualizado
      1. Asegura el refinamiento de las User Stories antes de cada Sprint

1. Vinculados estrechamente
2. Fundamental entender la calidad y alcance del proyecto:
   1. Asignar correctamente resultados
   2. Asignar correctamente los beneficios
   3. El alcance ofrezca valor empresarial
3. Determinar el Valor Empresarial del Producto:
   1. Entender la necesidad del negocio que impulsa los requisitos.
   2. La necesidad determina el producto
   3. Producto puede determinar el Valor Empresarial.
4. Calidad
   1. Variable compleja
   2. Aumento en alcance sin aumento en el tiempo, disminuye calidad
   3. “sustainable pace” (ritmo sostenible)
      1. permite mejorar la calidad a medida que transcurre el tiempo.
   4. SGB
      1. Puede definir requisitos mínimos de Calidad
      2. Para todos los proyectos

1. Documento de requisitos individuales
2. Define el alcance del projecto
3. Lista de prioridades de las características del producto o servicio
4. Contiene las necesidades descritas como User Stories
5. User Stories
   1. Requisitos específicos
   2. Señaladas por los los Stakeholders
   3. Cada "User Storie" tiene su correspondiente "User Story Acceptance Criteria"
      1. Acceptance Criteria
         1. Componentes objetivos para evaluar la funcionalidad
         2. Desarrollados por el PO
            1. Basado en su conocimiento experto del requisito del cliente
         3. Debe describir claramente las condiciones para satisfacer el User Storie
         4. El PO revisa en el proceso "Demostrate and Validate Sprint" Sprint Review Meeting
         5. No son sustitutos de la lista de requisitos
   4. El PO los comunica al Scrum Team y solicita su acuerdo
   5. El PO evalua su cumplimiento para aceptar o rechazar las User Stories
      1. Si se aceptan se consideran como "Done"
      2. Los rechazados (Rejected Deliverables) se añaden al Prioritized Product Backlog.

1. Es estado "Done" es blanco y nego, no hay intermedio
2. Debe cumplirse todos los criterios del "Acceptance Criteria"

Annotations:

• Una unidad de negocio de alto nivel puede anunciar un Acceptance Criteria mínimo y obligatorio, lo cual luego se puede convertir en parte de los Acceptance Criteria para cualquier User Story de esa unidad de negocio.

1. Definidos por la Unidad de Negocio
2. Mínimo y obligatorio
3. Puede convertirse en "Acceptance Criteria"
4. Cualquier funcionalidad posterior para esa Unidad de Negocio debe cumplir con ese Criterio
5. Pueden pasar a Programas y Portafolios
6. Ya documentados, pueden pasar al SGB

1. Diferencia entre "Done Criteria" y "Acceptance Criteria"
   1. "Acceptance Criteria"
      1. Único e individual por User Storie
   2. "Done Criteria"
      1. Conjunto de reglas
      2. Aplican a todas las User Stories de un Sprint
      3. Definition of Done (DoD):
         1. Lista de verificación de "Done Criteria"
            1. Debe ser clara para eliminar ambigüedades
         2. Normalmente determinada y documentada en SGB
      4. Podría incluir
         1. Fueron repasados por otros miembros del equipo
         2. Se completó la prueba de unidad del User Story
         3. Llevar a cabo las pruebas de Quality Assurance (Aseguramiento de calidad)
         4. Finalización de toda la documentación relacionada con los User Stories
         5. Todos los issues están arreglados
         6. La demostración exitosa a los Stakeholders y/o representantes de la empresa
   3. Ambos deben cumplirse a cabalidad para lograr el estado de "Done"

1. Unidad de Negocio y Stakeholders participan en la "Sprint Review Meeting"
2. Se le muestra al PO y Stakeholders el producto
3. Solo el PO Acepta o Rechaza
4. Criterios de Aceptación objetivos.
5. El Scrum Master (SM) se asegura que el PO no cambie los criterios durante el Sprint

1. Definición de "DONE"
2. Proporciona la guía para desarrollar "Acceptance Criteria"
3. Define las herramientas que Scrum Team puede usar para desarrollar y verificar el producto

1. Establece mínimo "Acceptance Criteria" de Portafolios
2. Repasa los entregables del portafolio

1. Asegura paso sostenible
2. Centrarse en calidad, no velocidad

1. Establece mínimo "Acceptance Criteria" del Programa
2. Revisa los entregables

1. Asegura paso sostenible
2. Centrarse en calidad, no velocidad

1. Revisa y acepta entregables

1. Define
   1. Business Requirenments del producto
   2. Requisitos claros del Prioritized Product Backlog
   3. Acceptance Criteria (incluye los del programa)
2. Evalúa
   1. Viabilidad
   2. Cumplimiento de calidad
   3. Entregables durante el proceso de "Demostrate and validate Sprint"

1. Propicia
   1. Mentalidad "Primero el equipo"
   2. Eliminar obstáculos
   3. Paso sostenible
   4. Calidad sobre velocidad
   5. El equipo siga las reglas de Scum, incluso el PO

1. Desarrollo y mantenimiento de Entregables
2. Practica y alienta buena comunicación para aclarar requesitos
3. Comparten conocimiento
4. Comparten Experiencia
5. Cambios rápidos a los entregables