MaxiCantarino
commented
2 years ago Qué es el Sprint Planning Meeting? En Scrum, la reunión de planificación de sprint (sprint planning meeting) cuenta con la participación del product owner, ScrumMaster y todo el equipo de Scrum. Actores externos pueden asistir por invitación del equipo, pero es extraño que suceda en la mayoría de las compañías.
Durante esta reunión de planificación, el product owner describe las características con mayor prioridad al equipo. El equipo realiza las preguntas necesarias para poder convertir una historia de usuario (user story) de alto nivel del product backlog en tareas más específicas a considerar en el sprint backlog.
El product owner no tiene que describir todos los items presentes en el product backlog. Una buena práctica es que el product owner se presente en la sprint planning meeting preparado para hablar de una cantidad de items del product backlog correspondiente a 2 sprints. Para hacer un ejemplo bastante simple, supongamos que un equipo siempre finaliza 5 items del product backlog. Su product owner debe ingresar a la reunión preparado para hablar de las 10 historias de usuario más priorizadas.
Hay 2 artefactos definidos que resultan de la sprint planning meeting:
Un objetivo de sprint Un sprint backlog Un sprint goal (objetivo de sprint) es una descripción corta, de una o dos oraciones, de lo que el equipo tiene previsto alcanzar durante el sprint. Se escribe en conjunto por el equipo y el product owner. Los siguientes son ejemplos de sprint goals de una aplicación eCommerce:
Implementar la funcionalidad básica del carrito de compras, incluyendo agregar, quitar y actualizar cantidades. Desarrollar el proceso de pago: pagar una orden, programar el envío, ordenar que se envuelva como regalo, etc. El sprint goal puede ser usado para informar de forma rápida a quienes están fuera del sprint. Siempre hay stakeholders que quieren saber en qué está trabajando el equipo, pero no necesitan conocer con detalle cada item del product backlog.
El éxito del sprint será posteriormente evaluado durante la sprint review meeting (reunión de revisión) en función al objetivo del sprint, en vez de considerar cada item específico seleccionado del product backlog.
El sprint backlog es el otro artefacto resultante de la sprint planning meeting. Un sprint backlog es una lista de items del product backlog que el equipo se compromete a entregar, más la lista de tareas necesarias para cumplir con cada uno de estos items. Usualmente se suele estimar cada tarea del sprint backlog.
Es importante recalcar que es el equipo el que selecciona el trabajo que se va a realizar en el sprint que está por iniciar. El product owner no determina la cantidad de trabajo que se va a realizar. Hemos de esperar que el equipo haga tanto como sea necesario para lograr finalizar con éxito el proyecto (o más), pero es el equipo el que determina qué tanto es capaz de hacer en el sprint.
¿Que es Daily Scrum? El Daily Scrum (o Scrum diario) es uno de los 5 eventos de Scrum con un bloque de tiempo de 15 minutos para que los Developers se sincronicen.
Esta reunión diaria se realiza a la misma hora y en el mismo lugar para reducir la complejidad. Aquí se busca la transparencia y la inspección de lo realizado para tener una oportunidad de adaptación para el día siguiente.
¿Cuál es el objetivo de la Daily Scrum? El propósito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario. Se busca que los Developers logren sincronizarse. Para ello se planea el trabajo de las siguientes 24 horas.
Esto optimiza la colaboración y el desempeño del equipo inspeccionando el trabajo avanzado desde el último Daily Scrum Meeting y haciendo una proyección del trabajo restante del Sprint.
Los Developers usan el Daily Scrum para evaluar su progreso hacia el Sprint Goal y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo del Sprint en curso.
Ya que la reunión tiene un timebox de solo 15 minutos cada persona debe realizar una breve síntesis de lo que cree más importante para lograr sincronizarse con el resto de sus compañeros.
¿Quién debe asistir al Daily Scrum? La Daily Scrum es una evento interna de los Develoeprs. Si el Product Owner o el Scrum Master están trabajando activamente en elementos del Sprint Backlog, participan como Developers. Si otras personas están presentes, el Scrum Master se asegura de que no interrumpan con el objetivo de la reunión.
Las personas ajenas a los Developers pueden asistir a esta reunión diaria de sincronización por invitación de ellos. Los Developers pueden desear considerar que hay un espíritu de transparencia en Scrum. Pero, por otro lado, los extraños pueden influir en la reunión por su propia presencia. En cualquier caso, solo los Developers participan activamente en la reunión. Esto se aplica tanto al Product Owner como a cualquier otra persona que no sean los Developers.
Daily Scrum 3 preguntas Una técnica popular es que cada persona de los Developers conteste las siguientes 3 preguntas en 2 a 3 minutos por integrante, a modo de agenda para optimizar la eficiencia del tiempo:
¿Qué hice ayer para ayudar a lograr el Sprint Goal (Objetivo del Sprint)? ¿Qué voy a hacer hoy para ayudar a lograr el Sprint Goal? ¿Veo algún impedimento que evite que el resto de Developers o yo logremos el Sprint Goal? Cabe destacar que esas 3 preguntas son solo un ejemplo de cómo llevar a cabo dicho este evento. Los Developers son los encargados de establecer la estructura de la reunión y esta se puede conducir de diferentes maneras siempre y cuando se enfoque en el progreso hacia el Sprint Goal.
Daily Scrum 1 sola pregunta Otra técnica que aprendí hace un tiempo del mismo Jeff Sutherland tiene que ver con centrarse en tratar de responder a una única pregunta durante la Daily Scrum:
¿Por qué el PBI más importante del Sprint Backlog aún no está terminado?
Desde mi punto de vista esta técnica es más efectiva aún que la de las 3 preguntas ya que fomenta mucho más la colaboración de los Developers hacia el cumplimiento del Objetivo del Sprint.
El rol del Scrum Master en la Daily Scrum El Scrum Master como facilitador se asegura de que los Developers tenga el evento pero son los Developers los responsables de dirigir el Daily Scrum. El Scrum Master enseña a los Developers a mantener el Daily Scrum meeting en los límites del bloque de tiempo de 15 minutos.
Beneficios del Daily Scrum Optimización: El Daily Scrum meeting optimiza las posibilidades de que los Developers cumplan con el Sprint Goal. Reduce tiempo perdido: Los Developers hacen visibles los impedimentos diariamente. Mejora la coordinación: Ayuda a encontrar oportunidades de coordinación porque todos saben en qué están trabajando los demás. Promueve el intercambio de conocimientos: el Daily Scrum identifica lagunas de conocimiento y permite el crecimiento del equipo. Fortalece la cultura: Lo realiza a través de rituales compartidos y la participación activa. Aumenta la productividad: permite ganar eficiencia en el proceso.
Buenas prácticas del DAILY SCRUM Los equipos Scrum de alto desempeño aprovechan este evento para actualizar su tablero Kanban también conocido como “tablero Scrum”.
El equipo colocará la última información del estado de las tareas, con el fin de transparentar los avances e impedimentos y ver de qué manera pueden colaborar entre ellos para terminar PRIMERO los ítems que aportan más valor al Sprint Goal.
burndown-chart También pueden usar parte del tiempo de esta reunión de sincronización para actualizar su métrica Burndown chart, con el objetivo de visualizar cuan cerca o lejos se encuentran de cumplir el Sprint Goal y poder adaptar su plan con esa información.
En cada Sprint tendremos un nuevo gráfico y a lo largo del proyecto podemos observar las tendencias y cuáles son los mayores impedimentos que hacen que el proyecto se retrase.
Hay que tener en cuenta que a medida que los miembros del equipo expresan sus impedimentos, existe una tendencia natural a querer profundizar en ellos e intentar plantear posibles soluciones.
Recuerda, un Daily Scrum es una reunión para volver a planificar y tomar decisiones, no para resolver problemas. Para tratar dichos problemas las personas involucradas pueden acordar reunirse cuando la Daily termine o bien a cierta hora del día para encontrar la solución, sin perder el tiempo de los demás. En la siguiente Daily van a contar que decisión finalmente tomaron o como resolvieron el problema.
Antipatrones del Daily Scrum Reporte de estado Algo que sucede en este evento con bastante frecuencia es que los Developers reportan el estado de las tareas del proyecto al Scrum Master, Product Owner o alguien externo al equipo Scrum. Esto trae varios problemas:
La colaboración del equipo disminuye considerablemente, ya que cada persona se siente responsable solamente de sus tareas y no del Objetivo del Sprint. Hay muchas tareas en proceso y al final del Sprint no se termina ninguna o casi ninguna. Baja la transparencia de los impedimentos que encuentran tanto para el Sprint en curso como a futuro, por ejemplo la deuda técnica. Los temas no tienen conexión Esto sucede cuando los Developers, si bien responden las 3 preguntas durante la Scrum Daily Meeting que mencionamos, hablan de temas completamente diversos, sin una conexión. Esto es un síntoma de que las personas están trabajando en funcionalidades muy distintas y no como como un equipo por lo que raramente haya colaboración para lograr el Sprint Goal. Eventualmente no le encuentran el sentido a este evento y dejan de hacerlo. El Scrum Master asigna las tareas Cuando el Scrum Master u otra persona asigna las tareas a cada miembro, no se incentiva la auto organización de los Developers. Esto produce ineficiencia en el proceso ya que si una persona termina su trabajo y el Scrum Master o quien asigna tareas no se encuentra disponible, quedará con tiempos muertos.
Por otro lado no se promueve la responsabilidad compartida de cumplir con el Objetivo de Sprint como algo más importante que solamente terminar ítems del Product Backlog.
Se toman tareas sin respetar el orden de prioridades del Sprint Backlog Al finalizar su tarea, un miembro del equipo toma una nueva sin considerar primero:
Si puede colaborar con otro miembro de los Developers a terminar alguna en curso. SI hay tareas que aportan mayor valor al cumplimiento del Sprint Goal. Cuando el Scrum Master no está, no se hace la Daily Como ya charlamos antes, el objetivo es lograr la sincronización de los Developers, y el Scrum Master solamente esta en este evento con rol de facilitador para que se respeten las reglas básicas como el timebox establecido.
Si esto sucede debemos preguntarnos si realmente está sucediendo la sincronización en la Daily o si viene siendo una reunión de seguimiento o reporte de estado y reflexionar al respecto. Puede ser un buen tema a tratar en la retrospectiva del Sprint.
Este antipatrón también nos puede estar indicando que el equipo es Scrum Master dependiente. Recordemos que una de las responsabilidades del Scrum Master es lograr que el equipo sea auto-organizado.
Conclusiones Los Developers pueden seleccionar la estructura y las técnicas que deseen, siempre que su Daily Scrum se centre en el progreso hacia el Objetivo del Sprint y produzca un plan viable para el siguiente día de trabajo. Esto crea foco y mejora la autogestión. Las Daily Scrums mejoran la comunicación, identifican impedimentos, promueven la toma rápida de decisiones y, en consecuencia, eliminan la necesidad de otras reuniones.
gracias por su tiempo!! Maximiliano
Buscar información sobre sprint planning meeting y daily scrum meeting (ceremonias de scrum)
Uno o dos párrafos de síntesis y el resto desarrollo con información que creas relevante. Valen enlaces, subir archivos, lo que consideres.
Lo pongo en un sprint de una semana, como punto inicio. En caso de ser necesario más tiempo, no hay problema.
Saludos y gracias de antemano.