Problemas de Scrum Burndown [cerrado]

Question

Hemos estado usando Scrum durante aproximadamente 9 meses y en gran medida ha sido un éxito.Sin embargo, nuestros gráficos de evolución rara vez se parecen a los gráficos "modelo", sino que se parecen más a una aterradora montaña rusa con algunas subidas y bajadas que provocan vómito.

Para intentar combatir esto, dedicamos más tiempo antes del sprint a crear prototipos y diseñar, pero todavía parecemos descubrir mucho más trabajo durante el sprint de lo que se pensaba inicialmente.Nota:Con esto quiero decir que el trabajo requerido para cumplir con el trabajo atrasado es más complicado de lo que se pensaba en un principio, en lugar de que hayamos identificado nuevos elementos para el trabajo atrasado.

¿Es este un problema común con Scrum? ¿Alguien tiene algún consejo para ayudar a facilitar el proceso?

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

¿Cuánto tiempo deberíamos dedicar antes de que el sprint comience a resolver los detalles del desarrollo?

ACTUALIZAR:Ahora estamos teniendo más éxito y un camino más tranquilo.Esto se debe en gran medida a que hemos adoptado una visión más pesimista al estimar lo que nos da más espacio para afrontar las cosas cuando no salen según lo planeado.Se podría decir que nos permite ser más "ágiles".También estamos tratando de cambiar la percepción de que el gráfico de quemado es una especie de cronograma en lugar de una indicación del alcance frente a los recursos.

Answer 1

Algunos consejos para suavizar las cosas.

1) Como han dicho otros, intente dividir las tareas en partes más pequeñas.La forma más obvia de hacerlo es intentar desglosar las tareas técnicas con mayor detalle.Siempre que sea posible, le recomiendo que hable con el propietario del producto y vea si puede reducir el alcance o "adelgazar" la historia.Este último me parece más efectivo.Hacer malabares con las prioridades y las estimaciones es más fácil si tanto el equipo como el propietario del producto entienden lo que se está discutiendo.

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

2) Intenta hacer sprints más cortos.Si estás haciendo sprints de un mes, prueba con dos semanas.Si vas a hacer dos semanas, prueba una.

• Actúa como limitador del tamaño de la historia, animando al propietario del producto y al equipo a trabajar en historias más pequeñas que sean más fáciles de estimar con precisión.
• Recibe comentarios con más frecuencia sobre sus estimaciones y es más fácil ver las conexiones entre las decisiones que tomó al comienzo del sprint y lo que realmente sucedió.
• Todo mejora con la práctica :-)

3) Utilice los stand-ups y las retrospectivas para observar un poco más las razones de los altibajos.¿Es cuando pasas tiempo con áreas particulares del código base?¿Se debe a que la gente no entiende al propietario del producto?¿Emergencias aleatorias que le quitan tiempo de desarrollo al equipo?Una vez que comprenda mejor de dónde provienen los altibajos, a menudo podrá abordar esos problemas específicamente.Nuevamente, los sprints más cortos pueden ayudar a que esto sea más obvio.

4) Cree en tu historia.Probablemente conozcas este...pero lo diré de todos modos :-) Si jugar con ese espantoso paquete heredado de Foo tomó 3 veces más de lo que pensaba que duraría el sprint, entonces también tomará 3 veces más de lo que cree que duraría el siguiente sprint.No importa cuánto más efectivo creas que serás esta vez ;-) Confía en el historial y utiliza elementos como el tiempo de ayer para guiar tus estimaciones en la próxima primavera.

¡Espero que esto ayude!

Answer 2

Me alegra saber que scrum ha sido un gran éxito para usted; eso es más importante que que el gráfico de evolución del sprint se vea ideal.El burndown del sprint es solo una herramienta para que el equipo le ayude a saber si está encaminado hacia los objetivos del sprint.Si el equipo ha cumplido los objetivos del sprint, no me preocuparía demasiado que el gráfico parezca una montaña rusa.Algunas sugerencias

• Durante la retrospectiva del sprint, pregunte al equipo de dónde proviene el trabajo adicional.
• Puede surgir trabajo adicional por no tener buenas pruebas de aceptación al principio del sprint.
• El trabajo extra puede provenir de no tener un trabajo pendiente bien arreglado.Una buena regla general es dedicar al menos el 5% del tiempo del equipo a pensar con anticipación en las historias del próximo sprint.
• Monitorear el trabajo en progreso: ¿el equipo está haciendo demasiado en paralelo?
• Durante la planificación del sprint, ¿cómo se siente el equipo acerca del desglose de las tareas que componen las historias?

Si no has cumplido los objetivos del sprint, utiliza la velocidad establecida del equipo para asumir menos durante el siguiente sprint.Tienes que aprender a caminar antes de poder correr.

Answer 3

En mi experiencia, Scrum definitivamente está más orientado hacia nuevos desarrollos que hacia el mantenimiento.Los nuevos desarrollos son mucho más predecibles que mantener una base de código grande y antigua.

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

Answer 4

Como han dicho otros, esperaría que la quema fuera de altibajos.¡Estas cosas pasan!Deberías utilizar las partes de "arriba y abajo" como material para tus retrospectivas.

Asegúrese de que todos tengan claro lo que significa "estar hecho" y utilice ese entendimiento conjunto para ayudar a impulsar sus sesiones de planificación.A menudo, tener disponible una lista de lo que se hace (a) le ayudará a recordar cosas que podría olvidar y (b) probablemente generará más ideas para tareas que, de otro modo, surgirían más adelante.

Otro punto en el que pensar: si trabaja mes a mes con una base de código impredecible, todavía esperaría que su velocidad se normalice a un ritmo razonablemente estable.Simplemente haga un seguimiento de su éxito en comparación con el trabajo planificado y utilice únicamente los elementos completados como máximo al planificar.Luego, concéntrese en sus tareas no planificadas y vea si hay algún patrón que sugiera que hay cosas que puede hacer de manera diferente para incluirlas en el trabajo planificado.

Answer 5

He tenido problemas similares.Mi equipo anterior (en él durante más de un año) era grande y manteníamos una base de código muy grande y que cambiaba rápidamente para una serie de lanzamientos iniciales de productos.Nuestras quemaduras tuvieron un aspecto vergonzoso, pero fue lo mejor que pudimos hacer.

Una cosa que puede ayudar (hacer que su gráfico se vea mejor) es mantener constante el número de horas/puntos comprometidos.Si has subestimado una tarea y tienes que duplicar las horas, saca algo del sprint.Si realiza una nueva tarea, obviamente tiene mayor prioridad que algo a lo que su equipo se comprometió, así que elimine esa otra cosa.

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

En mi nuevo equipo adoptamos un enfoque bastante radical y comenzamos a crear grandes boletos (algunos de más de una semana) que dicen cosas como "Implementar funciones V1.2 en ProjectX". Los requisitos/listas de características para ProjectX (versión 1.2 incluida) se mantienen en un wiki, por lo que el boleto está muy limpio y solo rastrea el trabajo realizado.Esto nos ha ayudado mucho: hemos forma menos tickets 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 sacando elementos del sprint si (y solo si) el hombre nos obliga a traer nuevos elementos.

Otro consejo sencillo que nos ayudó:agregue "horas totales de sprint" a su consumo.Esta debería ser la suma de todas las estimaciones.Trabajar para mantener esta línea plana puede ayudar y aumentar la visibilidad de los problemas que su equipo puede estar enfrentando (suponiendo que eso no lo degrade...)

-ab

Answer 6

También tuve problemas similares en mi agotamiento.Lo "arreglé" refinando lo que se incluyó en la quema.

SiKeep comentó:

Su progreso contra la acumulación seleccionada para ese sprint, que puede o no terminar como una liberación.

Dado que seleccionó ciertas cosas para el sprint y eso es lo que está en el burndown, no sé si todo el "trabajo nuevo" debería aparecer en el burnburn.Lo vería en el trabajo pendiente (sin afectar el trabajo pendiente), a menos que sea lo suficientemente importante como para pasar a su sprint actual (que luego se mostraría como una tendencia ascendente en el trabajo pendiente).

Dicho eso, Los altibajos menores son normales., si la línea de tendencia básicamente sigue la velocidad esperada.Me preocuparía la tendencia de montaña rusa que estás mencionando.Sin embargo, la idea de aislar el burndown agregando únicamente elementos de alta prioridad al sprint actual puede ayudar a amortiguar estos altibajos en el burndown.

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

Answer 7

Estamos utilizando una tarea de "tiempo limitado" para tareas no planificadas.Cada vez que llega un trabajo de alta prioridad o aparecen errores repentinos, podemos usar el tiempo del cuadro de tiempo (pero nunca podemos bajar 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 sprint.

Answer 8

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

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.

Answer 9

Ahora estamos usando un gráfico de quemado.En lugar de simplemente registrar la cantidad de trabajo restante, registramos 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 deberían unirse cuando se haya realizado todo el trabajo.También tiene una gran ventaja porque 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 'poseen' la otra línea (trabajo realizado).

La línea del PO subirá y bajará a medida que agreguen o eliminen trabajo.

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

Answer 10

Artículo ¿Es tu gráfico de quemado? explica lo que significa el estado dado en el gráfico de quemado.También proporciona sugerencias sobre qué hacer con eso.

Algunos ejemplos descritos en el artículo:

Answer 11

Esto es como debería ser.Si su gráfico de evolución se parece al gráfico modelo, está en problemas.El cuadro te ayudará a ver si podrás comprometerte y terminar todas las historias.

Siempre se descubrirán historias durante el sprint.Lo ideal sería poder diseñar y descubrir las tareas desde el principio, pero si funcionaran, ¿por qué no funcionaría un gran diseño inicial?Para responder a su última pregunta, la planificación del sprint debe tomar como mucho cuatro horas.