Reestimación Scrum de historias

Todos los días, después del stand-up , mi equipo y yo actualizamos nuestras estimaciones para cada historia. Tengo la sensación de que hay algo mal con la forma en que lo hacemos, por lo que necesito su ayuda.

Así es como lo hacemos:

Estimación de Story A: 24 horas (8 horas por día - usamos "días ideales" como medida)

• Día N: el desarrollador comienza a trabajar en la historia A por la mañana (8 horas de trabajo completadas al final del día)
• Día N + 1: Reestimación de la historia A = 16 horas (un día laborable sacado de la historia A, desde el día N)
• Día N + 2: Reestimación de la historia A = 8 horas (un día de trabajo extraído de la historia A, desde el día N + 1)
• Día N + 3: La historia A ya debería estar hecha. Pero no lo es. El desarrollador considera que tomará otras 3 horas para terminar. Actualizamos la historia en la pizarra y el burndown en consecuencia.
• Día N + 4: ¡La historia A tardó todo el día en terminar en lugar de solo 3 horas! Ahora ya está hecho. La diferencia, 5 horas, no se tiene en cuenta en nuestra planificación.

¿Cómo deberíamos volver a estimar diariamente nuestras historias?

La diferencia, 5h, no se tiene en cuenta en nuestra planificación.

Sí, se contabiliza implícitamente porque las siguientes tareas se retrasan. Si hubiera un gráfico de quemado solo para ese desarrollador, notaría que la curva se ha mantenido "plana" durante un día, mientras que se habría reducido si el desarrollador la hubiera terminado lo suficientemente temprano como para asumir otra tarea.

No hay nada de malo en la forma en que está re-estimando durante la reunión diaria, la reestimación se trata más de descubrir si podemos llegar al final del sprint que de rastrear la tardanza exacta de cada tarea. Todo lo que necesita en Scrum para poder ajustar su plan a diario es algo que indique el progreso de Sprint y qué tan lejos está de cumplir la meta de Sprint (generalmente, un gráfico de reducción).

La pregunta que debe hacerse es: ¿Deberíamos reestimar nuestras historias?

Yo diría que debes permitir que la "magia" ágil equilibre tus subestimaciones y sobreestimaciones en una iteración al calcular tu velocidad para la siguiente (que es la única razón para corregir un valor). Ver Mike Cohn's Estimación y planificación ágiles de para obtener más información.

Sin embargo, hay un caso en el que debe reestimar: algo que ha aprendido sobre una categoría de trabajo ajusta todas las estimaciones en el futuro.

p.ej. Si se estima que agregar una columna a una base de datos toma una hora ideal, pero resulta que toma 3 horas debido a algún factor que nadie consideró y parece que ese factor se aplicará cada vez que agregue un campo a la base de datos entonces todas las estimaciones para el trabajo de esa naturaleza deben ajustarse, incluida la que está trabajando.

Lo que he encontrado que es más efectivo es:

• Historias de tallas por puntos (o tallas de camisetas).
• Vuelva a estimar cualquier historia en la cartera de productos en cualquier momento (pero especialmente justo antes de la planificación del sprint).
• No vuelva a estimar las historias que están programadas para este sprint; siéntase libre de plantear inquietudes en el standup, pero no cambie las estimaciones.
• Usa el clima de ayer para programar sprints

Si las historias están entrando al sprint con estimaciones falsas, las reestimaciones de la planificación previa al sprint le permitirán solucionarlas antes de que se conviertan en un problema. Si las historias tardan más de lo esperado porque el equipo es demasiado optimista, el clima de ayer lo mantendrá encaminado.

Las reestimaciones diarias de lo que queda tienden a ser totalmente falsas, como describiste en tu pregunta. El trabajo completado / restante es un número falso diseñado para que parezca que estás trabajando "lo suficientemente duro". Mucho mejor es preguntar: "¿Cuándo crees que habrás terminado?" Y dejar claro que si hay un problema con una historia, el equipo dará un paso al frente para ayudar.

Creo que esto no es un problema. Más bien, puede ser falta de experiencia. Cuanto más sigas scrum, más se acostumbrarán los desarrolladores a proporcionar estimaciones más precisas. Esta es nuestra experiencia de implementar scrum después de 5 meses.

Al planificar las sesiones de póker , nuestros desarrolladores sugirieron estimaciones muy diversas para cada PBI y cada tarea en el primer sprint. Sin embargo, ahora, somos casi iguales en tiempo y estimación. ¿Cuánto tiempo has estado usando scrum? Si no tanto, dale algo de tiempo. Pero si es mucho tiempo, entonces, como sugirió @pdr, considere agregar un margen adicional para las tareas con mayores riesgos . Por ejemplo, cada vez que nuestro equipo quiere hacer una pieza de navegador de interfaz de usuario, pasamos nuestra estimación. Por lo tanto, siempre multiplicamos la estimación de las tareas entre navegadores por un factor para asegurarnos de que podemos cubrirlo.

Reestimar historias de usuarios comprometidos durante el sprint no tiene sentido. Solo te hace perder el tiempo. Usted ya se comprometió y no importa si realiza una nueva estimación o no.

La situación diferente es con historias de usuarios que no están comprometidas con el sprint actual. De vez en cuando es bueno hacer una nueva estimación (no más de una vez por sprint antes de la planificación). Las situaciones por las que puede ser razonable volver a estimar pueden ser:

• El propietario del producto cambió cualquier historia de usuario
• El propietario del producto divide o fusiona cualquier historia de usuario
• El propietario del producto agregó la historia de usuario
• Tiene algún conocimiento adicional que no estaba disponible durante la última historia de usuario
• Descubriste que algunas historias de usuario están relacionadas y ya hiciste parte de otra que aún no está comprometida
• etc.

No necesita necesariamente volver a estimar cada historia de usuario, pero puede hacerlo. Para una reestimación completa, generalmente necesita algún método rápido. La planificación del póker puede ser muy lenta, ineficiente, aburrida y, a veces, también imprecisa si se calculan más de 10-20 historias. La alternativa puede ser la estimación mágica .