1. 1. Propósito
1.1. La Guía Scrum contiene la definición de Scrum.
1.2. Cambiar el diseño de Scrum: a) Cubre los problemas b) Limita los beneficios de Scrum c) Puede hacerlo inútil.
1.3. Scrum es un marco ligero que ayuda a las organizaciones a generar valor a través de soluciones adaptables para resolver problemas complejos.
2. 2. Definición de Scrum
2.1. Scrum requiere un Scrum Master para que 4 cosas sucedan:
2.1.1. Paso 1: Un dueño del producto que ordene el trabajo (Product Backlog).
2.1.2. Paso 2: Un equipo Scrum (Developers, Scrum Master y dueño de producto) que convierta una porción de trabajo (Sprint Backlog) en un Incremento de valor durante un Periodo de tiempo (Sprint).
2.1.3. Paso 3: Un equipo de Scrum que junto a los Interesados (Stakeholders) deberán inspeccionan el incremento y adaptar el backlog.
2.1.4. Paso 4: Repetir
2.2. El marco de Scrum no da instrucciones detalladas, más bien es una guía.
3. 3. Teoría de Scrum
3.1. Concepto "EMPIRISMO" El conocimiento proviene de la experiencia y la toma de decisiones basadas en lo que se observa.
3.2. Concepto: "PENSAMIENTO LEAN" Reducir los residuos y centrarse en lo esencial.
3.3. Concepto: "ITERATIVO e INCREMENTAL" Optimizar la previsibilidad y controlar el riesgo.
3.4. Scrum tiene 3 PILARES
3.4.1. Pilar: "TRANSPARENCIA" El proceso y el trabajo emergentes deben ser visibles para: a) Quienes realizan el trabajo b) Para los que reciben el trabajo
3.4.1.1. La transparencia permite la inspección. La inspección sin transparencia es engañosa y derrochada.
3.4.2. Pilar: "INSPECCIÓN" Los artefactos de Scrum y el progreso hacia objetivos acordados deben ser inspeccionados con frecuencia
3.4.2.1. La inspección permite la adaptación. La inspección sin adaptación se considera inútil. Los eventos de Scrum están diseñados para provocar cambios.
3.4.3. Pilar: "ADAPTACIÓN" Debe suceder si algún aspecto de un proceso se desvía fuera de los límites aceptables o si el producto resultante es inaceptable.
3.4.3.1. Se espera que un equipo de Scrum se adapte en el momento en que aprenda algo nuevo a través de la inspección
4. 4. Valores de Scrum
4.1. Estos valores dan dirección al equipo de Scrum con respecto a su trabajo, acciones y comportamiento.
4.1.1. Valor 1 "COMPROMISO" El equipo se compromete a lograr sus objetivos y a apoyarse mutuamente.
4.1.2. Valor 2 "ENFOQUE" Su enfoque principal es el trabajo del Sprint.
4.1.3. Valor 3 "APERTURA" Estar abiertos acerca del trabajo y los desafíos.
4.1.4. Valor 4 "RESPETO" Los miembros del equipo de Scrum se respetan mutuamente para ser personas capaces e independientes.
4.1.5. Valor 5 "CORAJE" Tener valor de hacer lo correcto, de trabajar en problemas difíciles.
5. 5. Equipo Scrum
5.1. Caracteristicas del Equipo Scrum
5.1.1. No hay sub-equipos ni jerarquías.
5.1.2. Enfocados en un objetivo a la vez: El objetivo del Producto (Product Goal)
5.1.3. Tienen todas las habilidades necesarias para crear valor en cada Sprint.
5.1.4. Autogestionados, lo que significa que internamente deciden quién hace qué, cuándo y cómo.
5.1.5. Es lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para completar un trabajo significativo dentro de un Sprint. (Máximo 10 personas).
5.1.6. Todo el equipo de Scrum es responsable de crear un incremento valioso y útil en cada Sprint.
5.2. Integrantes
5.2.1. Desarrolladores
5.2.1.1. Concepto
5.2.1.1.1. Se comprometen a crear un Incremento útil (funcional) en cada Sprint.
5.2.1.2. Responsabilidades
5.2.1.2.1. Crean un plan para el Sprint. (Sprint Backlog)
5.2.1.2.2. Adaptar su plan cada día hacia el Objetivo Sprint (Daily Scrum)
5.2.1.2.3. Se responsabilizan mutuamente como profesionales.
5.2.1.2.4. Inculcar la calidad adhiriéndose a una definición de Hecho. (D.O.D.)
5.2.2. Dueño del Producto (Product Owner)
5.2.2.1. Conceptos
5.2.2.1.1. Responsable de maximizar el valor del producto resultante del trabajo del equipo de Scrum.
5.2.2.1.2. El PO puede crear la historias o puede delegar la responsabilidad a otros. Pero sigue siendo responsable.
5.2.2.1.3. Para que los POs tengan éxito, toda la organización debe respetar sus decisiones.
5.2.2.1.4. El PO es una persona, no un comité. El Propietario del Producto puede representar las necesidades de muchas partes interesadas en el trabajo pendiente del producto. Aquellos que deseen cambiar el trabajo pendiente del producto pueden hacerlo tratando de negociar con criterio con el Product Owner.
5.2.2.2. Responsabilidades
5.2.2.2.1. Desarrollar y comunicar explícitamente el Objetivo del Producto.
5.2.2.2.2. Creación y comunicación clara de elementos de trabajo pendiente del producto.
5.2.2.2.3. Asegurarse de que el trabajo pendiente del producto sea transparente, visible y comprendido.
5.2.3. Scrum Master
5.2.3.1. Conceptos
5.2.3.1.1. Responsable de establecer Scrum tal como se define en la Guía de Scrum.
5.2.3.1.2. El Scrum Master es responsable de la efectividad del Scrum Team.
5.2.3.1.3. Es un líder que sirve al equipo Scrum y a toda la organización.
5.2.3.2. Responsabilidades
5.2.3.2.1. Sirve al Equipo Scrum
5.2.3.2.2. Sirve al Dueño del Producto
5.2.3.2.3. Sirve a la Organización
6. 6. Eventos Scrum
6.1. Conceptos
6.1.1. El Sprint es un contenedor para todos los eventos.
6.1.2. Cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar los artefactos de Scrum.
6.1.3. Todos los eventos se llevan a cabo al mismo tiempo y lugar para reducir la complejidad.
6.2. Eventos
6.2.1. El Sprint
6.2.1.1. Conceptos
6.2.1.1.1. Todo el trabajo necesario para lograr el Objetivo del Producto, incluido la Sprint Planning, Daily Scrums, Sprint Review y Sprint Retrospective, ocurre dentro de los Sprints.
6.2.1.1.2. No se realizan cambios que pongan en peligro el Objetivo del Sprint.
6.2.1.1.3. El alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende.
6.2.1.1.4. Solo el Product Owner tiene la autoridad para cancelar el Sprint.
6.2.1.1.5. El Product Backlog se refina según sea necesario.
6.2.1.1.6. Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.
6.2.1.2. Duración
6.2.1.2.1. Son eventos de duración fija de un mes o menos para crear consistencia.
6.2.2. Planeación del Sprint (Sprint planning)
6.2.2.1. Conceptos
6.2.2.1.1. La Sprint Planning inicia el Sprint al establecer el trabajo que se realizará para el Sprint.
6.2.2.1.2. El Product Owner se asegura de que los asistentes estén preparados para discutir los elementos más importantes del Product Backlog y cómo se relacionan con el Objetivo del Producto.
6.2.2.1.3. El Scrum Team también puede invitar a otras personas a asistir a la Sprint Planning para brindar asesoramiento.
6.2.2.2. Agenda
6.2.2.2.1. Tema 1: ¿Por qué es valioso este Sprint? El Product Owner propone cómo el producto podría Incrementar su valor y utilidad en el Sprint actual. Luego, todo el Scrum Team colabora para definir un Objetivo del Sprint que comunica por qué el Sprint es valioso para los interesados.
6.2.2.2.2. Tema 2: ¿Qué se puede hacer en este Sprint? A través de una conversación con el Product Owner, los Developers seleccionan elementos del Product Backlog para incluirlos en el Sprint actual.
6.2.2.2.3. Tema 3: ¿Cómo se realizará el trabajo elegido? Para cada elemento del Product Backlog seleccionado, los Developers planifican el trabajo necesario para crear un Increment que cumpla con la Definición de Terminado. A menudo, esto se hace descomponiendo los elementos del Product Backlog en elementos de trabajo más pequeños de un día o menos. La forma de hacerlo queda a criterio exclusivo de los Developers.
6.2.2.3. Duración
6.2.2.3.1. La Sprint Planning tiene un límite de tiempo de máximo ocho horas para un Sprint de un mes.
6.2.3. Scrum diario (Daily Scrum)
6.2.3.1. Conceptos
6.2.3.1.1. Su propósito es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog
6.2.3.1.2. Si el Product Owner o Scrum Master están trabajando activamente en elementos del Sprint Backlog, participan como Developers.
6.2.3.1.3. Los Developers pueden seleccionar la estructura y las técnicas que deseen.
6.2.3.1.4. Las Daily Scrums eliminan la necesidad de otras reuniones.
6.2.3.1.5. La Daily Scrum no es el único momento en el que los Developers pueden ajustar su plan.
6.2.3.2. Duración
6.2.3.2.1. La Daily Scrum es un evento de 15 minutos para los Developers del Scrum Team. Se lleva a cabo todos los días hábiles del Sprint.
6.2.4. Revision del Sprint (Sprint Review)
6.2.4.1. Conceptos
6.2.4.1.1. El propósito de la Sprint Review es inspeccionar el resultado del Sprint y determinar futuras adaptaciones. Se discute el progreso hacia el Objetivo del Producto.
6.2.4.2. Agenda
6.2.4.2.1. El Scrum Team y los interesados revisan lo que se logró en el Sprint y lo que ha cambiado en su entorno. Con base en esta información, los asistentes colaboran sobre qué hacer a continuación. La Sprint Review es una sesión de trabajo y el Scrum Team debe evitar limitarla a una presentación.
6.2.4.3. Duración
6.2.4.3.1. La Sprint Review es el penúltimo evento del Sprint y tiene un límite de tiempo de máximo cuatro horas para un Sprint de un mes.
6.2.5. Retrospectiva del Sprint (Sprint Retrospective)
6.2.5.1. Conceptos
6.2.5.1.1. El propósito de la Sprint Retrospectiva es planificar formas de aumentar la calidad y la efectividad.
6.2.5.1.2. El Scrum Team inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado. Se identifican los supuestos que los llevaron por mal camino y se exploran sus orígenes.
6.2.5.2. Agenda
6.2.5.2.1. El Scrum Team identifica los cambios más útiles para mejorar su efectividad. Las mejoras más impactantes se pueden agregar al Sprint Backlog para el próximo Sprint.
6.2.5.2.2. El Scrum Team analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.
6.2.5.2.3. La Sprint Retrospective concluye el Sprint.
6.2.5.3. Duración
6.2.5.3.1. Tiene un tiempo limitado a máximo tres horas para un Sprint de un mes.
7. 7. Artefactos de Scrum
7.1. Conceptos
7.1.1. Los artefactos de Scrum representan trabajo o valor. Están diseñados para maximizar la transparencia de la información clave.
7.1.2. Cada artefacto contiene un compromiso para garantizar que proporcione información que mejore la transparencia y el enfoque frente al cual se pueda medir el progreso
7.2. Artefactos y Compromisos
7.2.1. Product Backlog
7.2.1.1. Conceptos
7.2.1.1.1. El Product Backlog es una lista emergente y ordenada de lo que se necesita para mejorar el producto. Es la única fuente del trabajo realizado por el Scrum Team.
7.2.1.1.2. Los elementos del Product Backlog que el Scrum Team puede dar por Terminados dentro de un Sprint se consideran preparados para ser seleccionados en un evento de Sprint Planning.
7.2.1.1.3. Los Developers que realizarán el trabajo son responsables del dimensionamiento.
7.2.1.2. Compromiso: Product Goal
7.2.1.2.1. El Objetivo del Producto describe un estado futuro del producto que puede servir como un objetivo para que el Scrum Team planifique. El Objetivo del Producto está en el Product Backlog. El resto del Product Backlog emerge para definir "qué" cumplirá con el Objetivo del Producto.
7.2.1.2.2. El Objetivo del Producto es el objetivo a largo plazo del Scrum Team. Ellos deben cumplir (o abandonar) un objetivo antes de asumir el siguiente.
7.2.2. Sprint Backlog
7.2.2.1. Conceptos
7.2.2.1.1. El Sprint Backlog se compone del Objetivo del Sprint (por qué), el conjunto de elementos del Product Backlog seleccionados para el Sprint (qué), así como un plan de acción para entregar el Increment (cómo).
7.2.2.1.2. El Sprint Backlog es un plan realizado por y para los Developers.
7.2.2.2. Compromiso: Sprint Goal
7.2.2.2.1. El Objetivo del Sprint es el único propósito del Sprint.
7.2.2.2.2. a) El Objetivo del Sprint se crea durante el evento Sprint Planning y se agrega al Sprint Backlog. b) Si el trabajo resulta ser diferente de lo que esperaban, colaboran con el Product Owner para negociar el alcance del Sprint Backlog dentro del Sprint sin afectar el Objetivo del Sprint.
7.2.3. Incremento
7.2.3.1. Conceptos
7.2.3.1.1. Un Incremento es un peldaño concreto hacia el Objetivo del Producto. Para proporcionar valor, el Incremento debe ser utilizable.
7.2.3.1.2. a) Se pueden crear múltiples Incrementos dentro de un Sprint. b) La suma de los Incrementos se presenta en la Sprint Review apoyando así el empirismo. c) El trabajo no puede considerarse parte de un Incremento a menos que cumpla con la Definición de Terminado.
7.2.3.2. Compromiso: Definition de hecho (Definiton of Done)
7.2.3.2.1. La Definición de Terminado es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto.
7.2.3.2.2. a) En el momento en que un elemento del Product Backlog cumple con la Definición de Terminado, nace un Incremento. b) Si un elemento del Product Backlog no cumple con la Definición de Terminado, no se puede publicar ni presentar en la Sprint Review.
7.2.3.2.3. Si la Definición de Terminado para un Increment es parte de los estándares de la organización, todos los Scrum Teams deben seguirla como mínimo.
7.2.3.2.4. Si hay varios Scrum Teams trabajando juntos en un producto, deben definir y cumplir mutuamente la misma Definición de Terminado.