Guía Scrum | 35. Scrum diario

El Daily Scrum no dura más de quince minutos y se realiza siempre en el mismo lugar y a la misma hora para reducir la complejidad innecesaria. A él asisten todos los Desarrolladores que trabajan juntos en el Producto y, opcionalmente, el Scrum Master. El objetivo principal de este Scrum Event es planificar las tareas en las que se centrarán durante el día.

Scrum diario – tabla de contenidos:

1. Introducción
2. La fórmula Scrum diario
3. Problemas con Daily Scrum y el método 5W
4. preguntas de apoyo
5. 5 porqués
6. Resumen

Introducción

Daily Scrum es el más corto y más frecuente de los eventos de Scrum, una descripción general de los cuales se puede encontrar en un artículo separado. La tarea de los Desarrolladores que participan en Daily Scrum es establecer rápidamente objetivos de trabajo para las próximas 24 horas. De esta manera, cada uno de ellos sabe en qué están trabajando los demás y cómo están trabajando hacia un Sprint Goal común.

La fórmula Scrum diario

No existe una fórmula correcta de Daily Scrum. Cada Equipo de Desarrollo desarrolla un formato de reunión que funciona para él. Sin embargo, existe un marco general para que sea más fácil de llevar a cabo.

Un Daily Scrum bien realizado debe permitir que cada participante responda dos preguntas :

• ¿Cuál es la tarea más importante que realizaré hoy?
• ¿Cuáles son los obstáculos para lograr esta tarea?

Sin embargo, preguntarles directamente no es una fórmula obligatoria. Estas son preguntas de muestra que definen el eje de la reunión. Daily Scrum tiene como objetivo mejorar la comunicación en el Equipo de Desarrollo, priorizar tareas y reducir el riesgo de cuellos de botella.

El Daily Scrum es un evento equivalente al Daily Standup en otros métodos ágiles. Y a menudo funciona de manera muy similar, aunque la Guía oficial de Scrum no requiere que los Desarrolladores permanezcan de pie durante este breve Evento. Muy a menudo, sus participantes simplemente se paran mientras hablan en un grupo informal.

Si bien puede parecer que 15 minutos al día es mucho para discutir las tareas diarias, la práctica demuestra que una reunión de este tipo es lo mejor para la eficacia del Equipo de Desarrollo. Con actualizaciones frecuentes y periódicas sobre objetivos y compromisos, todos los desarrolladores se centran en las tareas prioritarias y priorizan el progreso fluido del equipo sobre los resultados individuales.

Problemas con Daily Scrum y el método 5W

Uno de los problemas con Daily Scrum es que los desarrolladores prolongan el tiempo de la reunión. Si este es el caso, es una buena idea introducir una política de anotar en una pizarra, ya sea física o virtual, los problemas que no son centrales para el Daily Scrum pero que son importantes para el Equipo. De esta manera, será posible volver a los problemas que quedaron para ser discutidos durante las discusiones informales durante el día. Y también, si es necesario, durante la Sprint Retrospective, que describiremos con más detalle en un artículo aparte.

Otro problema que suele surgir durante los Daily Scrums es convertirlos en reuniones para resumir el trabajo del día anterior. Luego, los desarrolladores se enfocan en discutir los resultados ya logrados. Esta no es una buena práctica. Es cierto que la orientación actual de los desarrolladores sobre el estado del trabajo que conduce al Sprint Goal es muy importante. Sin embargo, dedicar el Daily Scrum a tareas ya completadas no promueve la eficiencia.

preguntas de apoyo

Si el equipo no se beneficia del Daily Scrum, el Scrum Master puede ayudar a los desarrolladores a identificar problemas observando la reunión para obtener respuestas a las siguientes preguntas:

5 porqués

Después de la identificación inicial del problema, una técnica eficaz para determinar la causa del problema puede ser el método de los 5 por qué, también llamado 5 por qué o 5W de Sakichi Toyoda. Se trata de preguntar varios "¿Por qué?" preguntas seguidas. Esto permite diagnosticar la causa más profunda del problema y, por lo tanto, resolverlo más fácilmente.

Por ejemplo, tomemos el último elemento de la tabla: el problema surge en el área de compromiso con la resolución de problemas por parte del Equipo de Desarrollo. Las cinco preguntas podrían ser las siguientes:

1 x ¿POR QUÉ?

P: ¿Por qué los desarrolladores no ofrecen diferentes formas de resolver los problemas que surgen?

R: Porque el desarrollador Harry siempre es el primero en proponer una solución.

2 x ¿POR QUÉ?

P: ¿Por qué el desarrollador Harry siempre es el primero en proponer una solución?

A: Porque nadie más está hablando.

3 x ¿POR QUÉ?

P: ¿Por qué nadie más habla?

R: Porque otros Desarrolladores no desean buscar mejores soluciones.

4 x ¿POR QUÉ?

P: ¿Por qué otros desarrolladores no tienen ganas de buscar mejores soluciones?

R: Porque encontrar soluciones requiere concentración y es más fácil considerar que la solución de Harry es lo suficientemente buena.

5 x ¿POR QUÉ?

P: ¿Por qué consideraron que la solución de Harry era lo suficientemente buena?

R: Como no son recompensados ​​por proponer alternativas, discutieron sus planes para hoy al comienzo de la reunión y están pensando en comenzar.

En este caso, el problema de la falta de compromiso en la resolución de problemas se puede solucionar cambiando el orden del Daily Scrum y comenzando por este tema. O idear un sistema para premiar la mejor solución, por ejemplo, introduciendo una recompensa simbólica para el autor de la mayor cantidad de soluciones aceptadas por el Equipo en un determinado Sprint.

Resumen

Daily Scrum es una parte clave del trabajo diario del Equipo de Desarrollo. Sin embargo, cada Equipo debe elaborar por sí mismo la fórmula óptima para esta reunión. Un Daily Scrum bien realizado permite el establecimiento continuo de subobjetivos para lograr el Sprint Goal. También permite diagnosticar rápidamente problemas de comunicación y mejorar la cooperación entre Desarrolladores.

Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autora: Carolina Becker

Como Project Manager, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos