Recientemente me he encontrado con esta situación:
Sin embargo, el equipo quiere que se incremente el valor de puntos de historia estimado original, digamos de 5 a 13 para reflejar cuánto esfuerzo está involucrado ahora.
Mi propia sensación es que los puntos de la historia se han estimado como la mejor suposición para ayudar con la planificación. Ahora que la caja de tiempo está en marcha, creo que el equipo se pregunta si la historia aún se puede completar por completo dentro de la caja de tiempo. No debemos reestimarlo. Sin embargo, puede ser útil guardar una nota para futuras sesiones de estimación o planificación para artículos similares.
La cultura es que los puntos de la historia se usan como justificación de lo que los miembros del equipo contribuyen a la caja de tiempo y, por lo tanto, siempre se asignan a días:
Personalmente, no estoy de acuerdo con este enfoque y reestimar la historia parece otro síntoma de este problema.
Normalmente, si el equipo se ha comprometido a entregar 100 puntos en función de la velocidad anterior y el cliente solicita agregar 8 puntos durante el período de tiempo, diríamos que no, ya que la velocidad es 100, el período de tiempo es fijo y posiblemente no podríamos agregar más.
Del mismo modo, no debería estar bien que el equipo aumente efectivamente la velocidad para 'arreglar' un problema de estimación percibido.
Supongo que mi pregunta es: ¿Cuál sería la práctica recomendada para volver a estimar una historia a mitad de tiempo y cuáles son los pros y los contras del enfoque que mi equipo quiere adoptar?
Tenga en cuenta que no soy el gerente de proyecto en este equipo.
Las estimaciones de historias son estimaciones , no garantías. Contribuyen a un rango de velocidad promedio general que es útil para la planificación de la capacidad. No son objetivos de gestión, y cambiar los puntos de la historia dentro de un Sprint tiende a barrer los problemas del proceso debajo de la alfombra e inflar/desinflar artificialmente la velocidad de un equipo.
Un axioma aceptado de la planificación ágil es que los puntos de la historia son una medida de tamaño relativo (no de tiempo). Las estimaciones a menudo son incorrectas en lo específico, pero en el agregado estadístico se acercan a un número "suficientemente bueno" para fines de planificación y control de programación.
No debemos reestimarlo. Sin embargo, puede ser útil guardar una nota para futuras sesiones de estimación o planificación para artículos similares.
Esto es correcto. La estimación desarrollada en Sprint Planning es la estimación; no debe cambiar dentro del Sprint.
Habiendo dicho eso, si una historia ha sido mal estimada, tienes varias opciones:
Independientemente de cómo aborde el problema, la estimación errónea (incluidas las suposiciones, los problemas de proceso inesperados, los obstáculos, etc.) debería ser agua para el molino en la próxima Retrospectiva de Sprint. El punto no es echar la culpa por la estimación incorrecta, sino comprender la causa raíz y mejorar continuamente el proceso de estimación y planificación.