Planificación de la iteración (Sprint Planning)

QUÉ: timebox de alrededor de 2 horas (Si la iteración es de 2 semanas).
- El cliente presenta la lista de requisitos priorizada del producto y propone requisitos más prioritarios a desarrollar.
- El equipo examina la lista, pregunta dudas, añade más condiciones de satisfacción y selecciona los objetivos más prioritarios que prevé completar en la iteración.
CÓMO: timebox de alrededor de 2 horas (Si la iteración es de 2 semanas).
El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor resultado posible con el mínimo esfuerzo.
- Tareas necesarias para poder completar cada objetivo, creando la lista de tareas de la iteración (Sprint Backlog).
- Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.
- Los miembros del equipo se autoasignan las tareas que pueden realizar, se autoorganizan para trabajar con el fin de compartir conocimiento (creando un equipo más resiliente) o para resolver juntos objetivos especialmente complejos.

Ejecución de la iteración (Sprint)

Un proyecto se ejecuta en bloques temporales, cada iteración tiene que proporcionar un resultado completo para cuando el cliente (Product Owner) lo solicite sólo sea necesario un esfuerzo mínimo para que el producto este disponible para ser utilizado. Se llevan a cabo las siguientes dinámicas:

Cada día se realiza una reunión de sincronización donde se inspecciona el trabajo de los otros para hacer las adaptaciones necesarias, actualiza el estado de los sprint backlog y los burndown charts (gráficos de trabajo)
El Facilitador (Scrum Master) se encarga de que se cumplan los objetivos: Elimina los obstáculos que el equipo no pueda resolver por sí mismo y los protege de interrupciones externas.

Recomendación: minimizar el número de objetivos en que el equipo trabaja simultáneamente

Restricciones: no cambiar los objetivos de la iteración en curso.

Reunión diaria de sincronización del equipo (Scrum daily meeting)

Para facilitar la transferencia de información y la colaboración entre miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros. Cada miembro debe responder a las siguientes preguntas:

¿Qué he hecho desde la última reunión de sincronización para ayudar al equipo a cumplir su objetivo?
¿Qué voy a hacer a partir de este momento para ayudar al equipo a cumplir su objetivo?
¿Qué impedimentos tengo o voy a tener que nos impidan conseguir nuestro objetivo?

Beneficios:Aumenta la productividad y el compromiso de equipo Fomentar el aprendizaje de los miembros del equipo Conocer el estado de la iteración

Restricciones: La reunión diaria de estado y sincronización del equipo no es para resolver problemas El equipo debe contar con unos criterios consensuados sobre el proceso de ejecución de las de tareas

Demostración de requisitos completados (Sprint Review)

Reunión informal donde el equipo:

Revisa los resultados obtenidos respecto al objetivo de la iteración, problemas identificados y cómo se resolvieron.
Presenta al cliente los requisitos completados. Como guía de la demostración se puede utilizar los PBIs y sus criterios de aceptación. También se explica si hubo algún PBIs que no se pudo completar

Beneficios: El cliente puede ver de manera objetiva si se cumplen sus expectativas, al inspeccionar un producto tangible, el cliente puede entender mejor qué es lo que necesita, el equipo puede ver si realmente está entendiendo cuáles son los requisitos que le está solicitando y el equipo se siente más satisfecho cuando puede ir mostrando los resultados

Restricciones: Sólo se debería mostrar los requisitos completados, para que el cliente no se haga falsas expectativas y pueda tomar decisiones correctas y objetivas en función de la velocidad de desarrollo y el resultado

Retrospectiva (Sprint Retrospective)

El equipo analiza cómo ha sido su manera de trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que se compremetió al inicio de la iteración y por qué el incremento de producto que acaba de demostrar al cliente era lo que él esperaba o no. Como resultado de una retrospectiva, se pueden encontrar los siguientes:

Plan de acciones de mejora.
Nuevas best practices.
Acuerdos de equipo actualizados.
Impedimentos a escalar.

Beneficios Incrementa la productividad en el proyecto, la calidad del producto y potencia el aprendizaje del equipo de manera sistemática. Aumenta la motivación del equipo

Refinamiento de la lista de requisitos y cambios en el proyecto – Product Backlog Refinement

En las reuniones de planificación de entregas y durante el transcurso de una iteración, el cliente / Product Owner va trabajando en la lista de objetivos/requisitos priorizada del producto o proyecto, añadiendo requisitos, modificándolos, eliminándolos, repriorizándolos (cambiando el contenido de iteraciones, definiendo un calendario de entregas que se ajuste mejor a sus nuevas necesidades) y detallando los requisitos conforme se acerca el momento de su desarrollo.
Los cambios en la lista de requisitos pueden ser debidos a: modificaciones que el cliente solicita tras la demostración, cambios en el contexto del proyecto, nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto, etc.

Cliente (Product Owner)

Su principal misión es encargarse de que exista una priorización clara de los objetivos a conseguir, con el propósito de maximizar el valor del trabajo que lleva a cabo el equipo.

Las responsabilidades del Cliente son:

Conocer el mercado y los comportamientos de los clientes / usuarios finales
Ser el representante de todas las personas interesadas (stakeholders) para conseguir una buena definición de los objetivos del producto o proyecto y de los resultados esperados
Encargarse de que exista una priorización clara de los objetivos a conseguir.
Actuar como interlocutor único ante el equipo, con autoridad para tomar decisiones
Colaborar con el equipo para planificar, revisar y dar detalle a los objetivos de cada iteración
Proporcionar suficiente dedicación para hacer este trabajo

Facilitador (Scrum Master)

Su principal misión es conseguir un equipo de alto rendimiento. Se encarga de conseguir el equipo que conozca y sienta los principios y valores de Agile, así como la teoría y prácticas de Scrum, con el objetivo de que los usen en sus procesos de toma de decisiones.

Lleva a cabo las siguientes responsabilidades:

Velar por que todos los participantes del proyecto sigan los valores y principios ágiles, las reglas y proceso de Scrum y guiar la colaboración intraequipo y con el cliente / Product Owner de manera que las sinergias sean máximas.
Conocer el grado de motivación de cada uno de los miembros del equipo, trabajarla con ellos y/o con las personas de la organización más relacionadas con este aspecto.
Quitar impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada iteración y poder finalizar el proyecto con éxito.
Proteger y aislar al equipo de interrupciones externas durante la ejecución de la iteración. De esta manera, el equipo puede mantener su productividad y el compromiso que adquirió sobre los requisitos que completaría en la iteración
Trabajar con otros Scrum Masters y el equipo de transformación / mejora continua con el objetivo de que la organización sea cada vez más ágil.

Equipo de desarrollo (Development Team)

El equipo en Agile incluye al Cliente / Product Owner y al Facilitador / Scrum Master. Cuando se habla específicamente de “equipo de desarrollo” se refiere al conjunto de personas más “técnicas” que de manera conjunta desarrollan el producto del proyecto.

Para ir alcanzando un estado de alto rendimiento, este equipo es:

Autónomo y multidisciplinar.
Tamaño de equipo de 5 a 9 personas.
Estable y dedicado.
Se auto-organizan, tienen responsabilidad compartida y piensan juntos
Están motivados.
Están sentados juntos(Trabajan en la misma localización).
Interaccionan con Stakeholders (agrupa a trabajadores, organizaciones sociales, accionistas y proveedores, entre muchos otros actores clave que se ven afectados por las decisiones de una empresa)

Lista de objetivos / requisitos priorizada (Product Backlog)

Representa la visión y expectativas del cliente respecto a los objetivos y entregas del producto o proyecto

Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que se suelen expresar en forma de historias de usuario. Para cada objetivo/requisito se indica el valor que aporta al cliente y el coste estimado de completarlo
En la lista se indican las posibles iteraciones y las entregas (releases) esperadas por el cliente.
La lista también tiene que considerar los riesgos del proyecto e incluir los requisitos o tareas necesarios para mitigarlos.
Se evita caer en parálisis de análisis al inicio del proyecto
Se evita analizar en detalle requisitos no prioritarios que podrían cambiar durante el transcurso del proyecto.
Puede llegar a un punto del proyecto en que no valga la pena analizar ni desarrollar los requisitos restantes, dado el poco retorno de inversión (ROI) que tienen.

Iteración de entrega (release sprint)

Cuando el cliente solicita una entrega de los objetivos/requisitos completados hasta ese momento, el equipo puede necesitar añadir una iteración de entrega

Se ha trabajado con una buena Definición de Hecho durante cada iteración del proyecto.
Se hacen entregas muy cortas cada poco tiempo, con lo que la cantidad de cosas a entregar, integrar y probar es pequeña.
Se está realizando un esfuerzo de automatización de estas tareas de pruebas, iteración y entrega durante todo el proyecto

Uso de la lista de objetivos priorizada

Para medir la velocidad de desarrollo del equipo, ver una progresión constante y extrapolar la fecha de las entregas
Cada requisito tiene asociado un factor de complejidad, que permite ajustar su coste estimado en función de la incertidumbre de la complejidad de su desarrollo en el momento de introducirlo en la lista
Si un requisito depende de otro, se coloca en algún punto por debajo del que depende.
Si un requisito no se finaliza en una iteración, se le vuelve a poner en alguna de las siguientes iteraciones
El “origen” permite saber quién podría participar en la definición de un objetivo/requisito y sería conveniente que estuviese presente en el momento de su demostración.

Lista de tareas de la iteración (Sprint Backlog)

Esta lista permite ver las tareas donde el equipo está teniendo problemas y no avanza, con lo que le permite tomar decisiones al respecto.
Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo pendiente para finalizarlas y la autoasignación inicial que han hecho los miembros del equipo.

Uso de la lista

Los objetivos/requisitos están ordenados por orden de prioridad para el cliente.
Si una tarea depende de otra, se coloca en algún punto por debajo de la que depende.
Las tareas deben estar identificadas de manera que tengan un coste semejante para ser completadas, entre 4 y 16 horas. Esto permitirá que las tareas sean suficientemente pequeñas como para poder detectar progreso o estancamiento de manera diaria, que no sean muy pequeñas, que sean suficientemente relevantes, no generen ruido ni microgestión y medir la velocidad de desarrollo del equipo

La lista de objetivos a completar en la iteración (Product Backlog Items) se puede gestionar mediante un tablón de tareas (Scrum Taskboard).