Guía Scrum | 32. Ventajas y desventajas del burndown chart

El gráfico de quemado tiene muchos beneficios. Es una de las principales herramientas de métricas en Scrum por varias razones. Es fácil de crear, escalar y leer. Sin embargo, también tiene inconvenientes que hacen que no sea una herramienta universal. En el artículo de hoy, cubrimos el tema de las desventajas y ventajas del gráfico de trabajo pendiente.

Ventajas y desventajas del burndown chart – tabla de contenidos:

1. Introducción
2. Ventajas del gráfico Burndown
3. Desventajas del gráfico Burndown
4. Resumen

Introducción

Hemos escrito sobre qué es, cómo crear e interpretar un gráfico de trabajo pendiente en artículos anteriores. Hoy nos centraremos en las ventajas y desventajas del Burndown Chart. Sin embargo, la mayoría de ellos no están ocultos en el gráfico simple en sí. Más bien, están relacionados con las formas de utilizar el burndown chart para motivar al Equipo de Desarrollo, ya que describen los resultados de su trabajo y fortalecen la autoorganización.

Ventajas del gráfico Burndown

El gráfico de quemado le permite visualizar el progreso de su proyecto. Su legibilidad y simplicidad lo hacen tan popular. Por eso es una buena idea que Burn Chart no sea solo una métrica constantemente actualizada oculta en una herramienta de gestión de proyectos digitales. Si es posible, vale la pena convertirlo en un punto de referencia para el Equipo de desarrollo visible en el lugar de trabajo físico. Ya sea en forma de visualización en pantalla o de boceto dibujado a mano.

Motiva al Equipo de Desarrollo

La transparencia del gráfico de quemado puede convertirlo en una herramienta para motivar al equipo de desarrollo a trabajar de manera eficiente. Alcanzar el punto “cero” en cada Sprint puede convertirse en una meta ambiciosa del Equipo, por lo que se otorgan recompensas, según los principios de la gamificación empresarial.

La visibilidad de un gráfico de trabajo pendiente actualizado y con un mantenimiento interesante también puede mejorar el espíritu de cooperación y autoorganización. Después de todo, la métrica es una medida del trabajo en equipo. No muestra exactamente quién completó (o no) las tareas planificadas, solo los resultados obtenidos.

Mide el trabajo real realizado.

Los desarrolladores deciden cuántas tareas realizarán en un Sprint determinado. Cuanto más experimentado sea el equipo, con mayor precisión deben predecir sus acciones. Y el gráfico bur-down refleja el progreso real del Sprint.

Por lo tanto, la ventaja del gráfico de quemado no es tanto medir la cantidad objetiva de trabajo realizado, sino la proporción de tareas planificadas y completadas. Así, los Desarrolladores aprenden gradualmente a planificarlos y pueden estimar sus capacidades cada vez con mayor precisión y eliminar errores repetitivos.

Se combina con otras herramientas.

Una de las ventajas significativas del gráfico de trabajo pendiente se refiere a su versatilidad para combinarlo con otras herramientas. Las siguientes herramientas pueden aplicarse a:

• analizando el trabajo del Equipo de Desarrollo
• visualizar el progreso del trabajo en el Producto
• estimar el presupuesto del proyecto

Por ejemplo, en el último caso, el uso del gráfico de evolución de la escala del proyecto permite una comparación del presupuesto planificado y real para todo el proyecto.

Desventajas del gráfico Burndown

A pesar de todas las ventajas del gráfico Burndown descrito anteriormente, puede convertirse en una fuente de confusión para el equipo de desarrollo. Sin embargo, lo que con frecuencia llamamos los "defectos" del gráfico de trabajo pendiente no se deben a imperfecciones de la herramienta en sí. Los problemas que se describen a continuación se refieren a la forma de implementar el diagrama de trabajo pendiente más que a su diseño. A continuación se muestran las fallas que pueden interferir con la representación del progreso del equipo de desarrollo de esta manera.

"El factor humano"

Los gráficos no pueden ser una medida absoluta del progreso de un equipo. Son solo herramientas para aplicar de diferentes maneras, más o menos hábiles. Podemos considerarlo como una desventaja (o ventaja) no solo del gráfico de trabajo pendiente sino también de otras medidas de rendimiento del equipo.

Para crear un gráfico de evolución, necesita que otras personas ingresen datos. En otras palabras, los desarrolladores anotaron el tiempo de finalización de la tarea en el gráfico. Es posible que lo hayan alargado o acortado un poco, ya sea por falta de atención o por querer mejorar las cosas para el equipo. Los desarrolladores también a veces se olvidan de registrar su tiempo. O deja el temporizador encendido. Esto hace que el tiempo de trabajo se extienda a varias horas. Y después de descubrir el error, es difícil reconstruir su curso real.

Cambios en el Sprint Backlog

Sprint Backlog no debe modificarse después del inicio de un Sprint. Sin embargo, en la práctica, tales cambios ocurren con bastante frecuencia. Son el resultado de los requisitos cambiantes de las partes interesadas. O problemas imprevistos que encuentran los desarrolladores.

Esto hace que se escale el gráfico de trabajo pendiente. Esto se debe a que el tiempo necesario para completar las tareas sigue siendo el mismo. Sin embargo, la escala de tareas pendientes aumenta. Esto puede dar la impresión engañosa de que el Equipo de Desarrollo ha planificado incorrectamente el trabajo a realizar en un Sprint determinado. O que funciona demasiado lento.

Los cambios en el Sprint Backlog también pueden deberse a tareas que se programaron para completarse demasiado rápido. En tal situación, el Equipo de Desarrollo suele decidir aumentar el número de tareas. Esto a su vez puede resultar en no completarlos a tiempo. Además, pueden surgir conflictos por la superposición de las tareas restantes del Sprint anterior con tareas nuevas programadas para ser completadas por las partes interesadas y los propietarios del producto.

Cambios en la cartera de productos

Los grandes cambios en el Product Backlog pueden alterar la forma del gráfico de quemado. Y así falsificar fuertemente la imagen del progreso del trabajo y la efectividad del Equipo. Esto sucede cuando aparecen nuevas historias de usuario . Y aquellos que están cerca de la fase de implementación a menudo se dividen en partes más pequeñas. También sucede que el Cliente renuncia a algunas funcionalidades del Producto.

Por lo tanto, al interpretar el Burn Chart, uno debe guiarse por el conocimiento y la experiencia en la evaluación del desempeño del Equipo. Y también tener en cuenta la variabilidad del Backlog. Si el gráfico no es la única métrica utilizada para evaluar el desempeño, los otros gráficos le permitirán ver una imagen más completa del progreso del trabajo.

Resumen

El Burndown Chart puede contribuir significativamente a la motivación del Equipo de Desarrollo. Esto se debe a que proporciona una medida del trabajo real realizado en el plan. Además, su combinación con otras herramientas métricas puede ser una fuente de valioso conocimiento sobre el trabajo del Equipo y la planificación del Producto.

Al aplicar cuidadosamente los principios de Scrum, puede evitar problemas potenciales con el trabajo pendiente. Lo más importante es adaptar las herramientas para mantener el gráfico siguiendo el trabajo real del Equipo Scrum, así como minimizar los cambios en el Sprint y el Product Backlog, sobre los cuales escribimos más en este artículo.

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