¿Está bien cambiar las estimaciones en medio de una iteración?

Comenzamos a usar Agile / Scrum en un equipo de 4 desarrolladores. Hicimos nuestras estimaciones de historias y ordenamos las historias Historias imprimidas en la cartera de productos.

Comenzamos con la estimación basada en puntos en la complejidad de 1 a 5, en lugar de la habitual 1,2,3,5,8,13 ... y así sucesivamente

Después de trabajar en un par de historias, sentimos que algunas de las historias que se estimaron en 4 puntos solo deberían ser 2, mientras que las otras que se estimaron en 2 son mucho más complejas y deberían haberse estimado en 5. Me gustaría saber:

¿Está bien cambiar las estimaciones de nuestra historia en medio de la iteración?
¿Está bien usar los puntos de estimación actuales de 1 a 5, en lugar de los habituales 1,2,3,5,8,13 ... y así sucesivamente?

Aunque personalmente siento que no debería ser para ambos casos, pero necesito respaldarme, ya que mi propia comprensión no está muy clara (¡aunque cualquier buen material de referencia sería bueno!)

project-management agile estimation

— tintin
fuente

Pregúntense: ¿cuál es el beneficio de pasar tiempo volviendo a estimar la mitad del sprint? ¿Cuál es el beneficio de pasar más tiempo 'discutiendo' sobre 3 contra 4 vs. 5 de grano fino en comparación con un 3 contra 5 aproximado?

— Hugo

Respuestas:

¿Está bien cambiar las estimaciones de nuestra historia en medio de la iteración?

Absolutamente no. Esperamos que eso suceda. Y esperamos que los errores se equilibren con el tiempo. Realmente solo ajustamos las estimaciones cuando está claro que una determinada categoría (por ejemplo, nuevas páginas web) siempre será más compleja de lo que pensábamos cuando las calculamos todas.

Como una historia épica se divide en historias más pequeñas (lo que debería suceder mucho antes del sprint), podríamos parecer que ajustamos la estimación original, pero yo lo llamaría refinar en lugar de volver a estimar. Eso es porque tenemos una visión más clara en ese momento.

La estimación y planificación ágiles de Mike Cohn es un buen libro sobre el tema. Yo advertiría en contra de usarlo (o cualquier libro "Ágil") como una biblia, pero es un buen punto de partida para refinar su proceso.

Habla sobre la forma en que las estimaciones erróneas se equilibran como "mágicas", pero subraya que lo ha visto funcionar una y otra vez.

¿Está bien usar los puntos de estimación actuales de 1 a 5, en lugar de los habituales 1,2,3,5,8,13 ... y así sucesivamente?

El uso de la serie de estimación de puntos de la serie Fibonacci es una aceptación de que cuanto más grande es una historia, menos precisa es nuestra estimación (ver mi comentario anterior sobre Epics).

Pero, si no funciona para usted, especialmente si mantiene todos sus trabajos pequeños, entonces no lo use. Es una guía, no una regla.

El tamaño de la camiseta (SML XL XXL) también es popular y esencialmente no es diferente de (1 2 3 4 5).

— pdr
fuente

+1: Discuta esto durante su retrospectiva. Vuelva a estimar cuando vuelva a priorizar al comienzo de la próxima primavera. Por eso tienes sprints. Sin gastos generales de administración durante el sprint, solo crea código.

— S.Lott

Sobre el uso de la serie fabonacci, digamos que saben que una historia llevará casi 3 días y el no. de las tareas para hacer la historia son A, B, C. También siente que no es muy complejo, pero cada una de estas tareas llevará 1 día cada una. ¿Qué estimación le darías a la historia?

— tintin

@tintin: La razón para usar puntos es evitar decir cosas como "sabes que una historia llevará casi 3 días". Los puntos son relativamente arbitrarios, cada trabajo se basa en la complejidad en comparación con otros trabajos (obviamente, debe evitar el uso de trabajos desestimados como líneas de base). Pero, evita los números que faltan, para tener en cuenta la incertidumbre. Entonces, si el trabajo B es dos veces más complejo que el trabajo A y el trabajo A se marcó como 2 puntos, usted marca el trabajo B como 5 puntos.

— pdr

+1 para: cuanto más grande es una historia, menos precisa es nuestra estimación

— kevchadders

¿Está bien cambiar las estimaciones de nuestra historia en medio de la iteración?

Absolutamente sí, si afectará la planificación de primavera actual o futura. El punto ágil es basar sus acciones en información que sea tan actual y correcta como sea posible.

Si una estimación resulta ser tan incorrecta que el sprint actual no se puede finalizar en su timebox, debe actuar sobre la estimación revisada, por lo que probablemente desee cambiarla. Si basa nuevas estimaciones en las antiguas (y en realidad las mira en lugar de confiar en la memoria / experiencia), necesita que sean correctas.

Por otro lado, en realidad no hay ningún valor per se en una estimación que sea correcta. No pierdas el tiempo en mejorar algunas estadísticas sin sentido.

— Michael Borgwardt
fuente

En nuestro caso, la estimación inicial fue grande, y el trabajo para eso resultó ser mucho menor. Entonces, no es que nuestro sprint actual no esté terminado a tiempo, sino que tenemos tiempo extra. Por lo tanto, el gerente sugiere reducir la estimación.

— tintin

@Michael, esta respuesta puede ser cierta para algunos procesos ágiles, pero la pregunta se relaciona con Scrum. En Scrum, no se recomienda cambiar los puntos de la historia después de la planificación del sprint porque la métrica Velocity del equipo podría verse comprometida.

— GuyR

Las estimaciones fallidas conllevan un beneficio, ya que puede usarlas para ajustar las estimaciones futuras en consecuencia. Si calcula demasiado, es un fracaso tan grande como estimar demasiado corto, porque el resultado son recursos subutilizados. El valor en las estimaciones correctas es que sabe que es probable que esté alcanzando sus objetivos de lanzamiento, y que su equipo está totalmente utilizado. Por lo tanto, siempre basa estimaciones futuras en sus experiencias pasadas, ajustándose según lo que aprenda sobre sus estimaciones en el camino.

— S.Robins