¿Qué sucede en un Sprint y cuándo?
La implementación exitosa de Scrum incluye una serie de ceremonias importantes. Entre ellas se encuentran el Sprint Planning, el Sprint Review, el Daily Scrum, la Sprint Retrospective y más.
Con frecuencia existen confusiones sobre quién debe participar en qué ceremonias de Scrum, cuándo se realizan, cuánto deben durar, cuál es el objetivo de cada ceremonia, etc.
En este artículo intentamos aclarar estas confusiones:
El Sprint Planning
Cuando comienza el Sprint, también se lleva a cabo el Sprint Planning. Este marca oficialmente el inicio del Sprint.
Todo el equipo Scrum participa en el Sprint Planning; es decir, tanto el equipo de desarrollo como el Scrum Master y el Product Owner. En raras ocasiones, otras personas también pueden participar en este evento, si el Product Owner y el equipo de desarrollo lo consideran apropiado. Si, por ejemplo, en el próximo Sprint se va a desarrollar una funcionalidad que un experto en la materia (que no sea el Product Owner) puede explicar mejor, puede ser útil que esa persona esté presente en el Planning. Sin embargo, en la mayoría de los casos es más conveniente que estas discusiones se lleven a cabo fuera de la reunión de Planning propiamente dicha.
La duración del Sprint Planning es proporcional a la duración del Sprint. Para un Sprint de cuatro semanas, el Planning no debería durar más de ocho horas; para un Sprint de una semana, no más de dos horas, es decir, máximo dos horas por semana de Sprint.
Esta limitación a una duración máxima de una reunión se conoce también como Time Boxing. Recomiendo a los equipos intentar terminar el Sprint Planning aproximadamente en la mitad del Time Box máximo permitido.
Como input para el Sprint Planning, el Scrum Master trae información sobre la Velocity promedio y actual (velocidad de trabajo). El Product Owner trae el Product Backlog o al menos los Backlog Items con mayor prioridad al Planning. En algunos equipos, el Product Owner también presenta un objetivo de Sprint preliminar en el Planning, que luego puede revisarse conjuntamente con el equipo durante la planificación.
El resultado del Sprint Planning es un equipo más informado y mejor preparado para el trabajo que viene. Otros resultados del Planning son el Sprint Backlog y un objetivo de Sprint creado conjuntamente.
Daily Scrum / Daily Standup
El Daily Scrum, también llamado Daily Standup, es una breve ceremonia que se realiza diariamente y en la que los miembros del equipo se sincronizan respecto a su trabajo. Con los Daily Scrums se asegura que las personas adecuadas trabajen en las cosas adecuadas en el momento adecuado.
Cada día, cada miembro del equipo responde las siguientes tres preguntas:
¿Qué hice ayer para alcanzar el objetivo del Sprint?
¿Qué haré hoy para alcanzar el objetivo del Sprint?
¿Tengo impedimentos o problemas que me impidan avanzar, y si es así, cuáles?
Estas preguntas pueden formularse de diversas maneras. Algunos equipos, por ejemplo, prefieren describir lo que han logrado en lugar de lo que han hecho.
Los participantes deberían ser el Scrum Master, el equipo de desarrollo, y en mi opinión también el Product Owner.
En la comunidad Scrum hay algunas discusiones sobre si el Product Owner debería participar o no en el Daily Scrum. Permitir que el Product Owner no participe en el Daily Standup puede alejarlo demasiado del equipo. Un sentimiento de "nosotros contra ellos" ya existe en demasiadas organizaciones. No puedo imaginar por qué un equipo Scrum o su Product Owner querría reforzar aún más esa actitud negativa.
Los Daily Scrums están limitados a una duración máxima de 15 minutos. El objetivo del Daily Scrum es una breve sincronización del equipo. A diferencia del Sprint Planning, aquí no recomiendo terminar en la mitad del tiempo previsto. Para la mayoría de los equipos, 5-7 minutos simplemente no son suficientes para abordar problemas reales o entender qué trabajo se ha completado. Si los Daily Scrums se acortan demasiado, rápidamente se convierten en una rutina con declaraciones como "Ayer hice XY. Hoy haré esto y aquello. No tengo impedimentos."
No hay resultados formales de los Daily Scrums, aparte de la mejora en la coordinación del trabajo en el equipo de desarrollo.
Sprint Review
El Sprint Review se lleva a cabo el último día del Sprint. Deberían estar presentes el Product Owner, el Scrum Master y el equipo de desarrollo, así como los Stakeholders correspondientes. Qué stakeholders deben estar presentes cambia de Sprint a Sprint y depende de lo que se haya entregado en el Sprint.
El Sprint Review tiene un Time Box de máximo cuatro horas para un Sprint de cuatro semanas. Correspondientemente, los Time Boxes son más cortos para Sprints más cortos, por ejemplo, una hora para un Sprint de una semana.
En el Sprint Review se deben mostrar todos los Product Backlog Items que cumplen con la Definition of Done. Esto significa que no se muestran trabajos que aún están en curso, es decir, que aún no están terminados. A veces, por supuesto, puede tener sentido hacer una excepción a esta regla.
La demostración de funcionalidad terminada es la actividad central de una reunión típica de Sprint Review. Sin embargo, la mayoría de los equipos también se toman tiempo para discutir avances y posibles problemas.
El objetivo de la reunión de Review es obtener retroalimentación sobre lo que se ha desarrollado durante el Sprint. El Product Owner recibe todo el feedback y puede, basándose en él, ajustar el Product Backlog si es necesario. El resultado de un Sprint Review es, por lo tanto, un Product Backlog revisado.
Sprint Retrospective
En la Sprint Retrospective, los miembros del equipo tienen la oportunidad de reflexionar sobre cómo pueden mejorar su forma de trabajar. Esto puede significar, por ejemplo, que quieran cambiar la forma en que implementan Scrum y, por ejemplo, ajustar la duración del Sprint. La Retrospective también puede cubrir aspectos generales de la colaboración, como no programar reuniones por la mañana o definir qué temas se pueden discutir en Slack y cuáles deberían resolverse en una conversación personal.
En la Sprint Retrospective debería participar todo el equipo, es decir, el equipo de desarrollo, el Scrum Master y el Product Owner. Cualquier otra cosa solo conduciría a una división en el equipo. Un buen equipo ágil debería evitar cualquier comportamiento que lleve a una mentalidad de "nosotros contra ellos".
Además de la voluntad de mejorar, la Sprint Retrospective no requiere ningún otro input. El resultado de la Retrospective debería ser una lista de cambios o propuestas de mejora que el equipo quiere implementar.
El Time Box para una Retrospective es de máximo 3 horas. De vez en cuando puede durar un poco más, pero en la mayoría de los casos los equipos terminan en menos de una hora.
Product Backlog Refinement
El Product Backlog Refinement debe asegurar que los Items en la parte superior del Backlog estén listos para el siguiente Sprint. Esto puede significar agregar detalles a los items existentes, realizar estimaciones, eliminar ciertos items, reordenar prioridades, dividir Backlog Items en items más pequeños o crear nuevos items.
Aunque el Refinement del Backlog en sí es necesario, esto no significa que un equipo deba hacerlo como una ceremonia oficial o que deba hacerse en cada Sprint. Sin embargo, la mayoría de los equipos realizan reuniones de Backlog Refinement regularmente, típicamente una vez por Sprint o por semana.
Una buena guía es que un equipo no debería dedicar más del 10% de su tiempo total disponible al Backlog Refinement, tanto en la reunión como en las discusiones posteriores que surjan de ella.
En la mayoría de los equipos, todos los miembros del equipo de desarrollo, así como el Product Owner y el Scrum Master, participan en las reuniones. A menos que un equipo esté estimando los Product Backlog Items en sus reuniones de Refinement, creo que aproximadamente la mitad a dos tercios del esfuerzo de desarrollo son suficientes, y la reunión puede mantenerse lo más corta posible para el equipo.
Lo único que se necesita llevar al Refinement son los items superiores del Product Backlog. Los resultados del Refinement son Product Backlog Items más pequeños que son más adecuados para el siguiente Sprint, así como una mejor comprensión de algunos Product Backlog Items.
Estimación del Backlog
Como se mencionó anteriormente, muchos equipos estiman sus Product Backlog Items ya durante la reunión de Refinement. Esta es la situación ideal y, si es posible, todo el equipo de desarrollo participa en el Backlog Refinement.
Si solo una parte del equipo participa en el Refinement, los miembros del equipo se reúnen una vez por Sprint para estimar todos los trabajos nuevos para los cuales el Product Owner necesita una estimación.
En la mayoría de los equipos, estas reuniones de estimación deberían ser muy breves. Los equipos no deberían generar demasiados Product Backlog Items nuevos, ni recibir una avalancha de nuevos items desde fuera. Los trabajos que deben estimarse deberían ser muy importantes o items nuevos o existentes que se han dividido para encajar mejor en el Sprint próximo.
Me gusta realizar el Product Backlog Estimating directamente después de un Daily Scrum y unos días antes del final del Sprint. Es lo suficientemente tarde para que la mayoría de los nuevos items ya se hayan identificado, y lo suficientemente temprano para que el Product Owner pueda cambiar la priorización basándose en la nueva información de las estimaciones.
No recomiendo estimar los items durante el Sprint Planning. Para entonces es demasiado tarde para que el Product Owner ajuste la priorización basándose en las estimaciones. También lleva a que los miembros del equipo dediquen más tiempo a las estimaciones del que deberían. Así que, no realicen las estimaciones de Product Backlog Items durante el Sprint Planning.
Priorización
Antes de que comience un nuevo Sprint, el Product Owner se asegura de que todos los items en la parte superior del Product Backlog estén priorizados. Según el Oxford American Dictionary, priorizar significa: "Poner tareas, problemas, etc. en un orden de importancia para poder abordar los más importantes primero."
Esto significa que no es suficiente decir: "Todos son necesarios." O como un Product Owner me dijo una vez: "No se llaman requisitos por nada; son requeridos."
En la mayoría de los casos, no habrá una ceremonia oficial para la priorización. Es más bien algo que el Product Owner hace solo después de conversar con los stakeholders para aclarar sus necesidades y deseos.
La priorización debería realizarse lo más tarde posible en el Sprint, pero en cualquier caso debería estar terminada antes del siguiente Sprint. Esto puede significar a menudo que se lleve a cabo en uno de los dos últimos días del Sprint.
La priorización normalmente no consume mucho tiempo, ya que el Product Owner típicamente realiza los ajustes finos a lo largo del Sprint basándose en nuevos conocimientos, en lugar de priorizar todo el Backlog en detalle desde el principio.
Las reuniones en un Sprint
Como puedes ver, hay una serie de ceremonias importantes en Scrum que se deben llevar a cabo concienzudamente. Esperamos que este artículo te haya dado una mejor visión general y te haya ayudado a tener más claridad en tu día a día con tu equipo Scrum. Si quieres saber más, nuestras formaciones Scrum son exactamente lo que necesitas.
Este artículo proviene del blog de Mike Cohn y fue traducido al alemán por nosotros.
