charts - tooltips - labels position chart js
Scrum quema tablas, ¿pueden ir negativas? (7)
Trabajo en un pequeño equipo de desarrollo Agile que es parte de una gran corporación de pensamiento no ágil. Actualmente, practicamos Scrum y ocasionalmente, excedemos nuestro compromiso de sprint.
Mi pregunta es, ¿cómo manejas los gráficos de quemado cuando has excedido tu compromiso de sprint? Puedo pensar en dos opciones:
- Extienda el eje y en la dirección negativa y continúe la cuenta atrás
- Agregue más tarjetas / historias / trabajo y haga que el valor de reducción aumente en esa cantidad, consumiéndose cuando termine ese trabajo.
La solución definitiva para mi equipo es clara para el negocio y agrega valor real para los desarrolladores. Hasta el momento, ninguna de estas soluciones ha funcionado a la perfección.
Al extender el eje Y queda muy claro para todos que estás yendo más allá del objetivo de sprint. Por lo general, no es un gran problema porque no se pasa de largo.
Si se convierte en una ocurrencia regular o si rebasas en una cantidad significativa, hay algo mal con tu proceso de estimación. Tal vez sea demasiado cauteloso al tratar con el lado "no ágil" del negocio. Trata de llevar a todos a dar un paseo.
Burndowns muestra el alcance restante dentro de un compromiso. Si agrega algo a su compromiso porque está sobre-entregando, lo agrega al número que está grabando en el cuadro. Como resultado, un equipo que está sobreentregando tendrá una reducción que se dirige hacia cero y luego permanece suspendido allí hasta el final del cuadro de tiempo trazado.
Para mostrar lo que realmente está entregando, considere un diagrama de flujo acumulado o quemado.
EDITAR
- Las quemaduras muestran el trabajo restante para completar "algo" (un sprint, un lanzamiento, un archivo MMF / "Epic", etc.)
- Las quemaduras muestran la acumulación de "algo" (valor comercial ganado, superar la complejidad, etc.)
- Los diagramas de flujo acumulativos muestran ambos + le dan una idea de la calidad de su proceso
Cuando agregamos más elementos al sprint, actualizamos la estimación del trabajo restante para reflejarlo en el gráfico de consumo de sprints:
texto alternativo http://www.movingsummit.co.uk/images/burndown_chart.JPG
Pero como se señala en otras respuestas, esto muestra que la estimación del trabajo restante cambió, no la razón (¿acabamos de volver a estimar el trabajo o agregamos trabajo?) Y no la acumulación de trabajo realizado. Sin embargo, esto podría no ser un problema.
Para representar la acumulación de trabajo realizado, un diagrama de quemado es más apropiado (utilizamos un gráfico de quemado en el nivel de publicación). Una quemadura contra la carga de trabajo permite representar el progreso del trabajo realizado y también un aumento o una disminución en los requisitos (y cómo esto afecta el pronóstico de finalización):
texto alternativo http://www.movingsummit.co.uk/images/burnup_chart.JPG
En mi opinión, los gráficos burndown no pueden ser negativos. Si terminaste con tu trabajo, o bien sigues sentado en tus sillas sin hacer nada, lo que significa que la rampa permanecerá en cero.
Si de hecho hace algo, entonces debería agregarlo a su lista de tareas, lo que significa que el burndown subirá y luego bajará cuando haya terminado con las tareas que agregó a la carga de trabajo de su sprint.
Un sprint donde la carga de trabajo original se haya completado antes de que termine el sprint debería mostrar un pequeño aumento cuando se vuelvan a agregar nuevas tareas (ya sea tareas individuales, por ejemplo correcciones de errores o una o más historias de usuarios nuevas). espacio para más.
Sin embargo, si esto sucede con frecuencia con su equipo, parece que constantemente está subestimando su velocidad y debería comenzar a comprometerse con más tareas desde el principio. No digo que sea malo terminar temprano y realizar más tareas, pero si esto sucede en gran medida es señal de que el equipo no está comprometido desde el principio, ya sea por accidente o para hacer absolutamente seguro de que no hay manera de que fallen el sprint.
Si está bien con el propietario de su producto, que así sea. Si yo fuera el dueño del producto y vería que un equipo siempre termina temprano, trataría de lograr que se comprometan con más tareas desde el principio. Esto puede sonar un poco más duro de lo que pretende sonar.
Extender el eje Y del gráfico burndown debajo de cero es una práctica bien establecida para rastrear el progreso de la liberación .
Ejemplo de lanzamiento burndown chart
En la imagen vinculada, puede ver la tabla de lanzamiento de la versión: todo lo que se agrega al alcance del lanzamiento va más allá de cero.
No recomendaría hacer exactamente lo mismo para sprint burndown chart. Simplemente debe agregar trabajo nuevo al trabajo restante y, obviamente, su consumo se incrementará por un tiempo. Si está utilizando una pizarra blanca para presentar su gráfico de quemadas de sprint, es una buena idea etiquetar el lugar a tiempo cuando agregó nuevas historias / requisitos con el comentario adecuado. De esa manera, será perfectamente visible lo que sucedió y por qué se inició su burndown.
Si persiste negativamente con su quemado, eso indicaría que está constantemente sobreestimando, y así finalizará su trabajo "demasiado pronto". Para solucionar esto, empiece a multiplicar la estimación por un factor de menos de 1 (es decir, 0,75, 3/4) (se me olvida el término correcto para esto, ¿se está "escalando"?). Haga esto para un sprint o tres, vea cómo afecta el resultado, puede tomar un par de iteraciones para obtener el factor correcto para cada desarrollador. Esto significa que podrá caber más dentro del sprint regular y no debería terminar temprano.
Disiento a estar en desacuerdo aquí :-) Trate de considerar el siguiente escenario: el equipo comienza a trabajar en una historia y se da cuenta de que no se ha planificado cierta cantidad de trabajo, y ahora agregan tareas para completar ese trabajo. El burndown aumenta, pero no exactamente por una buena razón, en ese caso no se trata de un cambio de alcance, sino que es una "estimación errónea", que desde una perspectiva de equipo no hace ninguna diferencia, ya que el mensaje sigue siendo: "este es el cantidad de trabajo que debe completarse ".
¿Qué pasa con el propietario del producto? ¿Cuánto quiere comunicar que ha entregado demasiado? ¿Cuánto es importante para el equipo distinguir los dos casos, y usarlos en la retrospectiva para analizar cómo mejorar las estimaciones la próxima vez, o comprometerse a más desde el principio? Se ha usado un enfoque similar para definir el gráfico alternativo de burndown ( http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown ), por lo que al volver a basar el gráfico y grabar más hacia abajo, se muestra claramente un alcance mayor y se quema. podría ser que el equipo descubriera nuevas tareas mientras comenzaba a trabajar en una historia en algún lugar del sprint ;-)
Ciao
ANdreaT