Antecedentes: Estamos a la mitad de un desarrollo que se estimó para un cliente en un contrato de precio fijo. Para llegar a la estimación, construimos un backlog tratando de enumerar todas las historias de los usuarios y luego les dimos estimaciones puntuales de la historia.
También tratamos de llegar a una estimación de tiempo general tomando ciertas historias, dividiéndolas en tareas de días/horas y luego escalando la proporción de tiempo a punto de la historia a todo el trabajo pendiente. Debido a que la tecnología y el marco que se usaba no eran familiares para el equipo de desarrollo (lo sé, lo sé...) las estimaciones terminaron siendo más una intuición. Ejecutamos picos, pero no fueron del todo útiles.
De todos modos, ahora que estamos a mitad de camino, el equipo tiene una comprensión mucho mejor de las tecnologías y los marcos en uso. Estamos considerando volver a estimar (en puntos de historia) los elementos restantes en la cartera de pedidos.
Hay algunas opiniones contradictorias en el equipo y algunas personas sienten que perderemos el rastro del plan original y que 'ganas algo, pierdes algo' y todo se equilibrará. Pero al mismo tiempo sería bueno tener una imagen más precisa de nuestro progreso actual.
Mi pregunta: ¿deberíamos cambiar los puntos de la historia para los elementos pendientes una vez que el desarrollo esté en marcha?
Consideraciones:
Independientemente de su metodología, su plan de proyecto debe refactorizarse de forma rutinaria. En la gestión de proyectos tradicional, esto a menudo significa ajustar las fechas de inicio y finalización de las tareas y los hitos. En las metodologías ágiles, esto generalmente implica volver a estimar las historias de los usuarios, las tasas de rendimiento y las fechas de entrega.
De todos modos, ahora que estamos a mitad de camino, el equipo tiene una comprensión mucho mejor de las tecnologías y los marcos en uso. Estamos considerando volver a estimar (en puntos de historia) los elementos restantes en la cartera de pedidos.
¡Felicidades! Acaba de descubrir el valor de la estimación iterativa en metodologías ágiles.
A medida que avanzan los proyectos, el cono de incertidumbre generalmente se estrecha y, en general, mejora la precisión de su equipo al estimar el trabajo. Wikipedia dice:
En la gestión de proyectos, el Cono de Incertidumbre describe la evolución de la cantidad de incertidumbre durante un proyecto. Al comienzo de un proyecto, se sabe comparativamente poco sobre el producto o los resultados del trabajo, por lo que las estimaciones están sujetas a una gran incertidumbre. A medida que se realiza más investigación y desarrollo, se aprende más información sobre el proyecto, y la incertidumbre tiende a disminuir, llegando al 0% cuando todo el riesgo residual ha sido cancelado o transferido.
En Scrum, las historias individuales se vuelven a estimar en cada Sprint a medida que se eliminan del Product Backlog. También se realiza cierto nivel de reestimación durante la preparación de la cartera de pedidos, incluida la estimación de nuevas épicas o historias a medida que se agregan a la cartera de productos con el tiempo. Sin embargo, la propuesta de valor de volver a estimar la totalidad del Product Backlog restante es ligeramente diferente.
Estamos a la mitad de un desarrollo que se estimó para un cliente en un contrato de precio fijo.
En primer lugar, una estimación no es un compromiso. Si bien es posible que haya acordado entregar una cantidad fija de trabajo por un precio fijo, a menos que su contrato establezca lo contrario, la fecha de entrega de un contrato de precio fijo suele ser flexible en al menos una de las siguientes dimensiones:
El valor de volver a estimar el Product Backlog restante en este escenario es que ahora tendrá estimaciones más precisas de:
Esto proporciona transparencia al proyecto y brinda a las partes interesadas palancas para ajustar el proyecto según sea necesario. Por ejemplo, una estimación de proyecto más precisa puede permitirles hacer nuevas comparaciones de costo-beneficio sobre características específicas o ahorrar dinero al terminar un proyecto que ya ha proporcionado valor comercial suficiente para enviarlo tal como está.
Si tiene la mala suerte de estar administrando un proyecto que está limitado simultáneamente en las tres dimensiones (por ejemplo, costo, alcance y velocidad), entonces el único valor real de volver a estimar el proyecto es determinar si fallará, cómo puede fallar, o lo que necesita ser renegociado para salvar el valor ganado para el proyecto.
Si esta es su situación, entonces el objetivo de reestimar es mejorar la transparencia y las comunicaciones con las partes interesadas. Como tal, hacer la reestimación claramente tiene valor tanto para el equipo como para el cliente.
Enfrenté el mismo problema con mi equipo. Lo que aprendí es que, si no te sientes cómodo con las estimaciones actuales, hazlo, pero no pierdas el tiempo reestimando historias pasadas o del sprint. Concéntrese en hacer cumplir las reglas básicas de usar puntos para los nuevos:
Además, considere usar reuniones periódicas de refinamiento de la cartera de pedidos , no hay problema en volver a estimar las historias, incluso sugeriría hacerlo muy a menudo para mantener su cartera de pedidos al día con la realidad.
¿Deberíamos cambiar los puntos de la historia para los elementos pendientes una vez que el desarrollo esté en marcha?
si esto ayudará al equipo y a la gente de negocios a comprender mejor la situación, ¡absolutamente!
también puede considerar abortar este sprint y comenzar uno nuevo (si el cambio es lo suficientemente grande)