El gráfico de quema tiene muchos beneficios. Es una de las principales herramientas métricas en Scrum por varias razones. Es fácil de crear, escalar y leer. Sin embargo, también tiene desventajas 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 quema.
Hemos escrito sobre qué es, cómo crear e interpretar un gráfico de quema en artículos anteriores. Hoy nos centraremos en las ventajas y desventajas del gráfico de quema. Sin embargo, la mayoría de ellas no están ocultas en el simple gráfico en sí. Más bien, están relacionadas con las formas de usar el gráfico de quema para motivar al equipo de desarrollo, ya que describen los resultados de su trabajo y fortalecen la autoorganización.
El gráfico de quema te permite visualizar el progreso de tu proyecto. Su legibilidad y simplicidad lo hacen tan popular. Por eso, es una buena idea que el gráfico de quema no sea solo una métrica constantemente actualizada oculta en una herramienta de gestión de proyectos digital. 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 una visualización en pantalla o un boceto a mano.
La transparencia del gráfico de quema 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 un objetivo ambicioso para el equipo, por el cual se otorgan recompensas – de acuerdo con los principios de la gamificación empresarial.
La visibilidad de un gráfico de quema actualizado y mantenido de manera 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 alcanzados.
Los desarrolladores deciden cuántas tareas realizarán en un Sprint dado. Cuanto más experimentado sea el equipo, más precisamente deberían predecir sus acciones. Y el gráfico de quema refleja el progreso real del Sprint.
Así, la ventaja del gráfico de quema no es tanto medir la cantidad objetiva de trabajo realizado, sino la relación de tareas planificadas a tareas completadas. Así, los desarrolladores aprenden gradualmente a planificarlas y pueden estimar sus capacidades de manera cada vez más precisa y eliminar errores repetitivos.
Una de las ventajas significativas del gráfico de quema se refiere a su versatilidad para combinarse con otras herramientas. Las siguientes herramientas pueden aplicarse a:
Por ejemplo, en este último caso, el uso del gráfico de quema de escala de proyecto permite una comparación del presupuesto planificado y real para todo el proyecto.
A pesar de todas las ventajas del gráfico de quema descritas anteriormente, puede convertirse en una fuente de confusión para el equipo de desarrollo. Sin embargo, lo que frecuentemente llamamos “defectos” del gráfico de quema no se deben a imperfecciones de la herramienta en sí. Los problemas descritos a continuación se refieren a la forma de implementar el gráfico de quema más que a su diseño. A continuación se presentan los defectos que pueden interferir con la representación del progreso del equipo de desarrollo de esta manera.
Los gráficos no pueden ser una medida absoluta del progreso de un equipo. Son solo herramientas que se aplican de diferentes maneras, más o menos hábiles. Podemos considerarlo como una desventaja (o ventaja) no solo del gráfico de quema, sino también de otras medidas del rendimiento del equipo.
Para crear un gráfico de quema, necesitas que otras personas ingresen datos. En otras palabras, los desarrolladores anotan el tiempo de finalización de las tareas en el gráfico. Podrían haberlo 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 olvidan registrar su tiempo. O dejan el temporizador encendido. Esto provoca que el tiempo de trabajo se extienda a varias horas. Y después de descubrir el error, es difícil reconstruir su curso real.
El Sprint Backlog no debe modificarse después del inicio de un Sprint. Sin embargo, en la práctica, tales cambios ocurren con bastante frecuencia. Resultan de cambios en los requisitos de los interesados. O problemas imprevistos que encuentran los desarrolladores.
Esto provoca que el gráfico de quema se escale. Esto se debe a que el tiempo tomado para completar las tareas permanece igual. Sin embargo, la escala de tareas restantes aumenta. Esto puede dar una impresión engañosa de que el equipo de desarrollo ha planificado incorrectamente el trabajo a realizar en un Sprint dado. O que trabaja demasiado lentamente.
Los cambios en el Sprint Backlog también pueden resultar de tareas que fueron programadas para completarse demasiado rápido. En tal situación, el equipo de desarrollo generalmente decide aumentar el número de tareas. Esto, a su vez, puede resultar en no completarlas a tiempo. Además, pueden surgir conflictos por la superposición de tareas restantes del Sprint anterior con nuevas tareas programadas para ser completadas por los interesados y propietarios del producto.
Grandes cambios en el Product Backlog pueden alterar la forma del gráfico de quema. Y así falsificar fuertemente la imagen del progreso del trabajo y la efectividad del equipo. Esto sucede cuando aparecen nuevas historias de usuario. Y aquellas 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 gráfico de quema, uno debe guiarse por el conocimiento y la experiencia en la evaluación del rendimiento 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 rendimiento, los otros gráficos permitirán ver una imagen más completa del progreso del trabajo.
El gráfico de quema 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, puedes evitar problemas potenciales con el gráfico de quema. Lo más importante es adaptar las herramientas para mantener el gráfico siguiendo el trabajo real del equipo de Scrum, así como minimizar los cambios en el Sprint y el Product Backlog, de los cuales escribimos más en este artículo.
Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Como Gerente de Proyectos, 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 presión de tiempo la convierten en la mejor persona para hacer realidad proyectos complicados.
Recientemente, han surgido dos fenómenos en el mercado laboral relacionados con las actitudes de los…
¿Cómo vender en Pinterest y por qué deberías hacerlo? Vender en Pinterest es otra forma…
¿Eres un freelancer que busca formas de promocionar su portafolio? Hoy en día, no solo…
La gestión financiera digital y la contabilidad en línea se han vuelto cada vez más…
Los estatutos del proyecto son el pan y la mantequilla de la gestión de proyectos.…
Las organizaciones de diversas industrias establecen relaciones con posibles empleados, proveedores y socios todos los…