Guía Scrum | 31. ¿Cómo crear e interpretar un burndown chart?

Un gráfico de trabajo pendiente es relativamente fácil de crear. Hay muchas herramientas disponibles para generarlo a partir del trabajo registrado por los miembros del Equipo de Desarrollo. A pesar de su sencillez, su interpretación puede aportar información valiosa para todo el Scrum Team. Lea este artículo para descubrir cómo crear e interpretar un gráfico de evolución.

¿Cómo crear e interpretar un gráfico de evolución? - Tabla de contenido:

1. ¿Cómo crear un gráfico de quemado?
2. ¿Quién es el responsable del Burndown Chart?
3. ¿Cómo interpretar un gráfico de burndown?
4. Burndown chart real e ideal
5. Selección de la unidad de medida
6. Resumen

¿Cómo crear un gráfico de quemado?

El Equipo de Desarrollo debe monitorear su trabajo diario. Esta es la base no sólo para evaluar su eficacia sino también para mejorarla. Y una de las herramientas más simples y comprobadas para este propósito es el gráfico de quemado.

Puede crearlo manualmente dibujando un sistema de coordenadas en una hoja de papel. En el eje Y, debe trazar la cantidad de trabajo expresada en una unidad elegida, por ejemplo, puntos de historia. En el eje X, dibuje una escala que indique los días consecutivos del Sprint. Dibuja una línea del sprint ideal y luego marca la cantidad de tareas completadas de manera realista para cada día. Aunque esta solución es encantadora y compromete al equipo, no es muy práctica. Tampoco es necesariamente adecuado para equipos remotos.

Por lo tanto, los medios digitales para crear un gráfico de trabajo pendiente son mucho más comunes. Muchas herramientas para registrar el trabajo en tareas distribuidas entre los miembros del equipo vienen con una opción para crear automáticamente un gráfico de trabajo pendiente. Luego, todo lo que tiene que hacer un desarrollador es marcar el inicio y el final del trabajo en una función de producto en particular, y su contribución se refleja en el gráfico de quemado.

Con las herramientas adecuadas, también es posible escalar libremente el gráfico. Esto da una idea de la combustión no solo en el nivel de un Sprint determinado sino también en la escala de una cuarta parte o de todo el proyecto.

Un factor importante a considerar al elegir una herramienta para crear un gráfico de trabajo pendiente es su accesibilidad para todos los miembros del Equipo Scrum. La visibilidad del gráfico de trabajo pendiente para todo el equipo de desarrollo es un factor de motivación clave. Igualmente importante es una mirada diaria a la línea que muestra el trabajo que queda por hacer. Hablando de quemado durante el Scrum diario , hace que los desarrolladores piensen en las formas en que trabajan y el estado actual del producto.

¿Quién es el responsable del Burndown Chart?

La cuestión de la propiedad de la tabla de quemado es algo controvertida. Por un lado, debe pertenecer al Scrum Master, porque es una herramienta para asegurarse de que el Equipo está trabajando de manera eficiente y de acuerdo con el plan. Por otro, debe quedar en manos del Product Owner, porque refleja el progreso hacia una Meta del Producto que se le comunica al Cliente. Además, un tercero que reclama su propiedad es el Equipo de desarrollo, ya que el gráfico funciona como su herramienta interna.

El Burndown Chart es una métrica esencial para evaluar la efectividad del Equipo de Desarrollo y es adoptado por todos los miembros del Equipo Scrum. Es por eso que la transparencia y la accesibilidad son cruciales. Sin embargo, su propósito es servir al Equipo. Se supone que debe fortalecer su autoorganización, mejorar la motivación y dar una imagen real del estado del trabajo en las tareas que se le asignan. Por lo tanto, en teoría, cada miembro del Equipo de Desarrollo puede actualizar el gráfico de quemado.

En la práctica, sin embargo, la tarea de actualizar el gráfico de trabajo pendiente generalmente recae en el Scrum Master. Esto sucede especialmente al comienzo de su trabajo con un nuevo Equipo de Desarrollo cuando la Velocidad del Equipo aún es variable y difícil de estimar. No obstante, se recomienda delegar esta tarea a uno de los Desarrolladores. Después de todo, el gráfico pretende ser una medida honesta e interna del progreso del trabajo según lo juzgan los propios desarrolladores.

¿Cómo interpretar un gráfico de burndown?

Describimos la apariencia del gráfico de avance en detalle en un artículo anterior. Aquí solo te recordaremos que el eje X muestra el tiempo que falta para completar el trabajo. Por otro lado, el eje Y muestra la cantidad de trabajo que queda por hacer.

Burndown chart real e ideal

Para interpretar un gráfico de quemado, el factor clave no es solo el trazado regular de la "combustión" real, es decir, la ejecución de tareas por parte del Equipo de Desarrollo. Igualmente importante para la imagen es su comparación con la caída ideal de la línea de combustión (guía).

Al comparar la línea de quemado ideal con la reducción real del trabajo marcada en el gráfico de quemado, se pueden evaluar dos parámetros muy importantes. Primero, para ver si el trabajo continúa al ritmo actual, el Equipo de Desarrollo cumplirá el Sprint Goal o el Product Goal a tiempo. En segundo lugar, para tener una idea de cuándo se completará el trabajo manteniendo el ritmo actual. En otras palabras, el gráfico de quemado muestra el ritmo real de las tareas y la línea ideal muestra a qué ritmo debe trabajar el equipo para completar las tareas.

El gráfico de quemado también le permite determinar un valor denominado Velocidad del equipo de desarrollo a largo plazo. Le dedicaremos un artículo aparte. Aquí solo mencionaremos que es un valor determinado por la cantidad de trabajo realizado durante un Sprint.

Gracias a que el gráfico de quemado ilustra la comparación de una línea de quemado ideal con una disminución real en el número de tareas, le permite estimar el ritmo de trabajo. Y así anticiparse al riesgo de retrasos en los proyectos.

Selección de la unidad de medida

La velocidad del equipo generalmente se mide en unidades llamadas puntos de historia. Define el número de historias de usuario que se han realizado. Estos pueden requerir cantidades muy diferentes de trabajo.

Esta es la razón por la que muchos Equipos Scrum utilizan una medida basada en el tiempo. Dependiendo de la escala, estos son días u horas-hombre. Cada Desarrollador estima y luego registra la cantidad de tiempo dedicado a sus tareas.

Otra opción es adoptar las tareas como una unidad. Estas son unidades un poco más grandes, a las que a su vez se les asigna un valor expresado en puntos de historia, o en días u horas-hombre. Es una unidad que permite al cliente presentar el progreso del trabajo en el producto de una manera más clara.

Independientemente de la unidad de medida, vale la pena recordar el principio de calcular la velocidad del Equipo de Desarrollo. En un día o Sprint determinado, solo cuentan las tareas que realmente se completaron. Significa que las tareas iniciadas se contarán para el día siguiente o Sprint, incluso si solo faltan las pruebas finales.

Resumen

Con las herramientas de supervisión del equipo disponibles, crear un gráfico de trabajo pendiente se convierte en una tarea sencilla. La cuestión más importante es garantizar su coherencia, claridad y accesibilidad para todos los miembros del Equipo Scrum.

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