agile - online - Problemas de Scrum Burndown

release burndown chart (11)

Hemos estado usando Scrum por alrededor de 9 meses y ha tenido mucho éxito. Sin embargo, nuestros gráficos de burndown rara vez se parecen a los gráficos "modelo", en lugar de parecer más de una montaña rusa terrorífica con algunas subidas y bajadas de vómito.

Para tratar de combatir esto, estamos pasando más tiempo antes de la creación de prototipos y el diseño de sprints, pero parece que todavía descubrimos mucho más trabajo de lo que inicialmente se pensaba. Nota: con esto me refiero a que el trabajo requerido para cumplir con la cartera de pedidos está más involucrado de lo que se pensó en primer lugar, en lugar de que hayamos identificado nuevos elementos para la acumulación.

¿Es este un problema común con Scrum y alguien tiene algún consejo para ayudar a suavizar el viaje?

Debo señalar que la mayor parte de nuestro trabajo de desarrollo no es totalmente nuevo, por lo que estamos manteniendo la funcionalidad en una aplicación existente grande y compleja. ¿El scrum es menos adecuado para este tipo de desarrollo simplemente porque no sabes qué problemas va a arrojar el código existente?

¿Cuánto tiempo deberíamos pasar antes de que el sprint comience a detallar el desarrollo?

ACTUALIZACIÓN: Estamos teniendo más éxito y un viaje más suave ahora. Esto se debe en gran parte a que hemos tenido una visión más pesimista al estimar cuál nos está dando más espacio para lidiar con las cosas cuando no van según lo planeado. Podrías decir que nos permite ser más ''ágiles''. También estamos tratando de cambiar la percepción de que el gráfico de reducción de emisiones es algún tipo de programa en lugar de una indicación de recursos de alcance v.

Algunos consejos para suavizar las cosas.

1) Como han dicho otros: intente dividir las tareas en trozos más pequeños. La forma más obvia de hacer esto es tratar de dividir las tareas técnicas en mayor detalle. Siempre que sea posible, le animo a que hable con el propietario del producto y vea si puede reducir el alcance o "diluir" la historia. Encuentro este último más efectivo. Hacer malabarismos con las prioridades y las estimaciones es más fácil si el equipo y el propietario del producto entienden lo que se está discutiendo.

Mi regla general es que cualquier estimación mayor a la mitad de un día ideal es probablemente incorrecta :-)

2) Intenta hacer sprints más cortos. Si está haciendo sprints de un mes, intente dos semanas. Si estás haciendo dos semanas, prueba uno.

Actúa como un limitador en el tamaño de la historia: anima al propietario del producto y al equipo a trabajar en historias más pequeñas que son más fáciles de estimar con precisión.
Recibes comentarios más a menudo sobre tus estimaciones, y es más fácil ver las conexiones entre las decisiones que tomaste al comienzo del sprint y lo que realmente sucedió
Todo mejora con la práctica :-)

3) Use los soportes y las retrospectivas para ver un poco más las razones de los altibajos. ¿Es cuando pasas tiempo con áreas particulares de la base de código? ¿Es causado por gente que no entiende bien al propietario del producto? ¿Emergencias aleatorias que alejan el tiempo de desarrollo del equipo? Una vez que tenga una idea más clara de dónde vienen los altibajos, a menudo puede abordar esos problemas específicamente. Nuevamente, los sprints más cortos pueden ayudar a hacer esto más obvio.

4) Crea tu historia. Probablemente sepas esto ... pero lo diré de todos modos :-) Si jugar con el espantoso legado del paquete Foo tomó 3 veces más de lo que pensabas que duraría el sprint, entonces también tomará 3 veces el tiempo que creas el próximo sprint. No importa cuánto más efectivo piense que será esta vez ;-) Confíe en la historia y use cosas como el Tiempo de ayer para guiar sus estimaciones en la próxima primavera.

¡Espero que esto ayude!

Como otros han dicho, yo esperaría que un burndown esté arriba y abajo. ¡Estas cosas pasan! Debe usar los bits "arriba y abajo" como forraje para sus retrospectivas.

Asegúrese de que todos tengan claro lo que significa "hacer" y utilice esa comprensión conjunta para ayudar a conducir sus sesiones de planificación. A menudo, tener una lista de lo que constituye un hecho disponible le ayudará (a) a recordar cosas que podría olvidar y (b) probablemente desencadenará más ideas para tareas que de otro modo surgirían más adelante.

Otro punto para pensar: si trabaja mes a mes con una base de código impredecible, aún espero que su velocidad se normalice a un ritmo razonablemente constante. Simplemente haga un seguimiento de su éxito en relación con su trabajo planificado y solo use elementos completos como máximo al planificar. Luego concéntrese en sus tareas no planificadas y vea si hay patrones que sugieran que hay cosas que puede hacer de manera diferente para incluir esas cosas en el trabajo planificado.

En mi experiencia, Scrum definitivamente está más orientado hacia un nuevo desarrollo que hacia el mantenimiento. El desarrollo nuevo es mucho más predecible que mantener una base de código grande y antigua.

Dicho esto, un posible problema es que no estás dividiendo las tareas en trozos suficientemente pequeños. Un problema común que tienen las personas con la planificación de software en general es que piensan "oh, esta tarea debería llevarme 2 días" sin realmente pensar en lo que implica hacer esa tarea. A menudo, encontrará que si se sienta y piensa en ello, esa tarea consiste en hacer A, B, C y D y termina siendo más de 2 días de trabajo.

Esto es como debería ser. Si su diagrama de burndown se parece a la tabla de modelos, está en problemas. El cuadro ayudará a ver si podrá comprometerse y terminar todas las historias.

Descubrir historias durante el sprint siempre sucederá. Idealmente, sería capaz de diseñar y descubrir las tareas por adelantado, pero si funcionaran, ¿por qué un gran diseño inicial no funcionaría? Para responder su última pregunta, la planificación del sprint debería tomar como máximo cuatro horas .

He tenido problemas similares. Mi equipo anterior (durante más de un año) era grande y mantuvimos una base de código muy grande y cambiante para series de lanzamientos iniciales de productos. Nuestros burndowns eran vergonzosos, pero fue lo mejor que pudimos hacer.

Una cosa que puede ayudar (hacer que su gráfica se vea mejor) es apegarse a la cantidad de horas / puntos comprometidos a constante. Si ha subestimado una tarea y tiene que duplicar horas, saque algo del sprint. Si realiza una nueva tarea, es obviamente de mayor prioridad que algo en lo que su equipo se comprometió, así que saque esa otra cosa.

Intentamos dividir la tarea en muchas tareas antes y en la planificación, y eso nunca pareció ayudar. De hecho, solo nos dio más malditas entradas para hacer un seguimiento durante el sprint. Los requisitos comenzaron a migrar a los tickets y (como era de esperar) se perdieron en todo el shuffle.

En mi nuevo equipo adoptamos un enfoque bastante radical y comenzamos a crear grandes entradas (algunas de más de una semana) que dicen cosas como "implementar las características v1.2 en ProjectX". Los requisitos / listas de características para ProjectX (versión 1.2 incluida) se guardan en una wiki, por lo que el ticket es muy limpio y solo rastrea el trabajo realizado. Esto nos ha ayudado mucho, tenemos menos boletos para realizar un seguimiento y hemos podido terminar todos nuestros sprints, a pesar de que nos siguen sacando de nuestras tareas de sprint para ayudar a otros equipos o apagar incendios.

Continuamos empujando los artículos fuera del sprint si (y solo si) estamos forzados (por el hombre) a traer nuevos artículos.

Otro consejo simple que nos ayudó: agrega "horas totales en carrera corta" a tu burndown. Esta debería ser la suma de todas las estimaciones. Trabajar para mantener esta línea plana puede ayudar, y aumenta la visibilidad de los problemas que su equipo puede enfrentar (suponiendo que eso no lo haga degradar ...)

-ab

Puede integrar el nuevo trabajo en la fecha de inicio del sprint, para tener un excelente gráfico Burndown.

Puedes etiquetar con un marcador específico el trabajo adicional y evaluar al final del sprint por qué no has podido identificar esas tareas antes.

También tuve problemas similares en mi burndown. Lo "arreglé" refinando lo que estaba incluido en el burndown.

SiKeep comentó:

Su progreso contra la cartera de pedidos seleccionada para ese sprint, que puede o no terminar como un lanzamiento.

Ya que seleccionó ciertas cosas para el sprint y eso es lo que está en el burndown, no sé que todo el "nuevo trabajo" debería aparecer en el burndown. Me gustaría ver que vaya a la acumulación (que no afecte a la quema), a menos que sea lo suficientemente importante como para pasar a su sprint actual (que luego se mostraría como una tendencia al alza en el burndown).

Dicho esto, las subidas y bajadas menores son normales , si la línea de tendencia básicamente sigue su velocidad esperada. Me preocuparía la tendencia de la montaña rusa que mencionas. Sin embargo, la idea de aislar el burndown solo agregando elementos de alta prioridad al sprint actual puede ayudar a amortiguar estos altibajos en su burndown.

Como han dicho otros, la planificación antes de que comience el sprint debe ser corta ... ( no más de 4 horas ).

Estamos utilizando una tarea "encerrada en el tiempo" para tareas no planificadas. Cada vez que se acerca un trabajo de alta prioridad o aparecen errores repentinos, podemos usar el tiempo del cuadro de tiempo (pero nunca podemos pasar por debajo de cero). Este método tiene la ventaja adicional de que podemos rastrear fácilmente qué tareas fueron imprevistas y tenerlas en cuenta durante nuestra próxima planificación de sprints.

Ahora estamos usando una tabla de grabación. En lugar de solo registrar la cantidad de trabajo restante, hacemos un gráfico de dos cosas: la cantidad de trabajo completado y la cantidad total de trabajo (es decir, completado + pendiente).

Esto le da dos líneas en el gráfico que debe cumplir cuando todo el trabajo está hecho. También tiene una gran ventaja, ya que muestra claramente cuándo el progreso es lento porque se ha agregado más trabajo.

Si lo desea, el PO ''posee'' una línea (el trabajo total) y los desarrolladores / probadores ''propios'' de la otra línea (trabajo realizado).

La línea del PO subirá y bajará a medida que agregue / elimine el trabajo.

La línea dev / tester solo aumentará a medida que completen el trabajo.

Artículo ¿Es su tabla de reducción de emisiones? explica qué significa un estado dado en el gráfico de quemado. También proporciona sugerencias sobre qué hacer con eso.

Algunos ejemplos descritos en el artículo:

Me alegra saber que el scrum ha sido un gran éxito para usted, es más importante que tener el gráfico sprint burndown como ideal. El sprint burndown es solo una herramienta para que el equipo lo ayude a saber si está en camino a los objetivos de sprint. Si el equipo ha estado cumpliendo los objetivos de sprint, no me preocuparía demasiado que el gráfico se vea como una montaña rusa. Algunas sugerencias

Durante la retrospectiva de sprint, pregúntale al equipo de dónde viene el trabajo adicional
El trabajo adicional puede provenir de no tener buenas pruebas de aceptación al principio del sprint.
El trabajo adicional puede provenir de no tener un retraso acumulado bien preparado. Una buena regla general es pasar al menos el 5% del tiempo del equipo pensando en las historias del próximo sprint antes de tiempo.
Monitorear el trabajo en progreso: ¿está haciendo demasiado el equipo en paralelo?
Durante la planificación de sprints: ¿cómo se siente el equipo sobre el desglose de las tareas que conforman las historias?

Si no has cumplido los objetivos de sprint, usa la velocidad establecida del equipo para asumir menos durante el próximo sprint. Tienes que ser bueno para caminar antes de poder correr.