Historia de usuario: Cómo desarrollador quiero realizar ceremonias efectivas con mi equipo Scrum para poder sincronizar mi trabajo y entregar el máximo valor posible con el incremento de producto.
Una situación común en equipos que recién adoptan éste marco de trabajo es la aplicación literal de lo planteado por la Guía Scrum como si se tratase de una metodología sin identificar o incentivar el descubrimiento de mejores prácticas o incluso evolucionar sus propios eventos.
Si bien, la forma de llevar el evento no es una receta dura y pura sino que, de forma empírica el equipo desarrollará los conocimientos para llevar los eventos de forma más eficaz, les comparto unos puntos a tener en cuenta que les ayudará con los eventos.
Daily Standup
Este es el evento Scrum con más nombres que he escuchado, Daily standup, Daily Scrum, standup meeting, pero independientemente de cómo le llames lo importante es la sincronización del equipo.
- Siempre realiza la reunión a la misma hora y en el mismo lugar. La puntualidad siempre habla bien de uno mismo y del respeto que le tenemos a los demás. Recuerda que el tiempo para nadie regresa, por lo que valorar el propio tiempo se reflejará también en como aprecias el de los demás y por supuesto te lo agradecerán.
- Normalmente, al realizar esta reunión los equipos responden roboticamente las clásicas tres preguntas del standup: ¿Qué hice ayer?, ¿Qué haré hoy?, ¿Qué impedimentos tengo?, volviendo la reunión monótona, sin conversación y sin ningún valor adicional. Prueba generando una conversación casual, sí claro, que dicho contenido de la conversación pueda responder las preguntas pero sin repetirlo como si se tratase de tablas de multiplicar.
- No te estreses por los 15 minutos. En la mayoría de los casos los Scrum Masters y equipos de desarrollo cuidan más el timebox de los 15 minutos en lugar de crear una reunión eficaz. No importa si toma 20 minutos o un poco más, siempre y cuando se mantenga breve, la reunión diaria debe generar un entorno de sincronización y trabajo en equipo. ¿Haz visto cuando un equipo de fútbol se reúne tomándose hombros y hablando entre ellos para formar una estrategia de juego para el set en curso? Es lo mismo con el Daily, en medida que mejoren la comunicación, sincronización y trabajo en equipo, los 15 minutos parecerán demasiados.
Sprint Planning
En este evento el equipo planifica su trabajo, estima qué ítems del Product Backlog se compromete a construir o implementar y determina aquellas tareas que tiene que hacer para conseguir su correcta implementación. La Guía Oficial de Scrum nos dice que este evento debe producir la inteligencia y estrategia para responder dos preguntas:
- ¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
- ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?
En la primera parte de la reunión el equipo Scrum debe de reunirse con el Dueño de Producto y aclarar todas sus dudas, entender sus necesidades y la priorización de los elementos del Product Backlog. Conforme los PBI queden entendidos el equipo deberá asignarle un tamaño, mi recomendación es que usen Planning Poker para realizar esta actividad.
En la segunda parte el equipo realiza el desglose de tareas requerida por cada elemento del Product Backlog para que su implementación sea correcta, hace esto siempre teniendo en cuenta la Definición de Terminado o Definition of Done. Ten en cuenta siempre el DoD en tu desglose de tareas. Al final, tu Sprint Backlog debe de tener las historias del Sprint, las tareas necesarias para completarlas y su estimación de esfuerzo en puntos.
Sprint Review
Este evento suele ser relativamente fácil de adoptar y es que, incluso no has ejecutado Scrum anteriormente seguramente has hecho demostraciones de tu producto al final de una iteración. Sin embargo, hay algunas diferencias y matices en la Revisión del Sprint que lo hacen diferente frente a las demos tradicionales.
- Como miembro del equipo de desarrollo céntrate en mostrar el producto construido, el Product Owner hablará los detalles de negocio con sus stakeholders.
- Prepara el demo antes de la Review. Es útil preparar dos o tres escenarios de uso del Sprint Backlog desarrollado.
Sprint Retrospective
He notado que este evento es el que, en equipos de recién adopción de Scrum, el menos entendido. ¿Pero por qué? La retrospectiva debe ser un espacio seguro, en donde como miembro del equipo de desarrollo tienes la oportunidad de proponer mejoras en el proceso, en las herramientas que utilizas y sobre todo en tus propias capacidades. El verdadero propósito de la retrospectiva es el analizarse a uno mismo.
La próxima vez que te encuentres en una Retrospectiva de Sprint piensa siempre en «Cómo yo, como miembro de equipo puedo apoyar para mejorar procesos, herramientas, capacidades y conocimientos de mi equipo». A toda costa evita el «Es que si fulano hace bien su trabajo podré hacer el mío» evita culpar. Recuerda que para crecer primero necesitamos crecer en individual. Como resultado una retrospectiva debe producir una unión de equipo sólida, se trata de crear relaciones a través de la interacción humana.
Por último quiero escribir que, si bien estas recomendaciones pueden ser muy útiles recuerda que la forma más óptima de hacer el trabajo es la tuya. Aprende, experimenta y vive Scrum.
Déjenme saber en los comentarios, ¿Cómo ejecutan los eventos en tu proyecto?
Saludos scrummies!