¿Está bien corregir una estimación de una historia durante la ejecución?

Durante la ejecución

Eso no es ideal, pero en el mundo real esto sucede. ¿Y cuál es la alternativa? ¿No comunicar que podría llevar más tiempo? Esa no es una opción. Entonces, sí, la estimación de una historia puede cambiar durante la ejecución. Si eso sucede a menudo, una retrospectiva de por qué sucede podría estar en orden.

Cuando se termina una historia

Eso es bastante inútil. Una estimación es para cuando la historia no está terminada. Tiene algún valor volver a todas sus historias terminadas y verificar si sus estimaciones fueron buenas o dónde necesita mejorar, pero cambiar la estimación en sí... no tiene ningún valor en ese punto.

Reestimar en ausencia del propietario del producto (PO)

no _ El objetivo de una historia de usuario es la comunicación entre el PO y el equipo de desarrollo. Hacer esta comunicación en ausencia de una parte es simplemente incorrecto.

Una vez que un Sprint está bloqueado, las estimaciones están bloqueadas, por lo que no está bien cambiar una estimación después de que se haya realizado la planificación del Sprint y el Sprint esté bloqueado. Hay un par de propósitos de las estimaciones:

1. Basado en tendencias históricas: permita que Sprint Planning alcance la cantidad deseada de puntos/horas
2. Hacer un seguimiento de la precisión de los estimadores y proporcionar constantemente comentarios sobre sus estimaciones para mejorar las estimaciones.

Básicamente, haga el trabajo por adelantado en las estimaciones y responsabilice a los estimadores para que mejoren con el tiempo. O despedirlos de la estimación.

Todo trabajo de desarrollo incluye un elemento de descubrimiento. Un buen equipo de Scrum permitirá algo de capacidad adicional para esto, en lugar de llenar un sprint tan completo que no haya contingencias.

¿Necesita volver a estimar? Bueno, eso depende de las circunstancias y del impacto que pueda tener el cambio.

Si el equipo descubre que algún trabajo está tardando más (o menos) de lo esperado, normalmente hay dos formas de reaccionar:

• Si el impacto es pequeño, entonces el equipo puede continuar como de costumbre.
• Si el impacto es significativo, es posible que el equipo deba volver a planificar y, en una situación extrema, es posible que deba abortar el sprint.

De cualquier manera, puede ser útil que el equipo considere lo que sucedió con la estimación en su próxima retrospectiva. Si hay un problema constante con las estimaciones (por ejemplo, subestimar el tiempo que tardan las dependencias), entonces el equipo puede querer pensar en formas de abordar este problema.

Si es durante su sprint, es posible que desee cambiarlo si surge nueva información. Sin embargo, lo ideal es que lo supere y vuelva a planificarlo, si es posible, y obtenga una historia con la que se sienta más cómodo con la estimación. Si no es posible: entonces sí, hazlo en vivo. Agile se trata de lo que funciona para su equipo y su cliente. Si desea volver a estimar en medio del sprint y usar la nueva estimación: entonces hágalo. Por lo general, a los clientes les preocupa el trabajo que realmente se realiza, no la estimación. Si toma más tiempo de lo que esperaba: bueno, así es la vida, pero cambiar la estimación para reflejar eso realmente no sirve de mucho.

Probablemente no quieras cambiarlo después de que se haya completado la historia . Es como decir "Bueno, supongo que esta tarea llevará 100 horas". Luego, si resulta que la tarea lleva 200 horas, no regresas y dices "Oh, mira, supusimos que la tarea tomó 200 horas... ¡y tomó 200 horas! ¡Somos perfectos!". No, supuso que tomaría 100 horas y, de hecho, tomó el doble de esa cantidad de tiempo. Aprende de ese error, no finjas que nunca sucedió. Sus estimaciones nunca pueden mejorar si siempre las manipula para que sean estimaciones "perfectas".

Respuestas Rápidas:

1. Si la historia está en curso, pero no completa, sería innecesario volver a señalar. Comunique los posibles retrasos de inmediato, pero los puntos no ayudan allí. Los puntos se utilizan para medir la capacidad, y ese cálculo ya se habrá realizado cuando comience el sprint.

2. Diría que sí, si se aplica el escenario que describo a continuación. De lo contrario, no tiene sentido.

3. No sé si entiendo completamente lo que se propone aquí, pero no cambie los puntos sin el conocimiento de su PO. La capacidad es algo muy importante para ese rol, y cambiar los puntos de forma inesperada causará una confusión innecesaria.

Escenario de reorientación válido

En nuestros equipos de ingeniería, usamos la aplicación Agile Poker Jira. Es una solución fantástica para las sesiones de señalización sincrónicas o asincrónicas.

Lo menciono porque una de las excelentes características que ofrece es mostrarle algunos ejemplos de historias a las que se les han asignado valores de puntos específicos. Entonces, si cree que una historia va a ser de 5 puntos, le mostrará algunas historias completas de 5 puntos para comparar.

Dejar los puntos de la historia sin corregir después de un sprint en este caso en realidad contribuye a señalar de manera inexacta el avance. Impide la capacidad de su equipo para medir adecuadamente su velocidad.

Como ejemplo simple, si le das a una historia 2 puntos, pero terminó siendo 5, si alguna vez tienes una historia similar en tu próximo sprint y no corrigiste los puntos, sobreestimarás tu capacidad.

En mis equipos, si alguien siente que la historia en la que está trabajando se estimó incorrectamente, lleva su sugerencia de punto revisada a su equipo para su aprobación. Es bastante raro que suceda, y se vuelve cada vez más raro a medida que los equipos aprenden.

Si no compara historias al señalar, entonces realmente no importa. Solo tendrá un margen de error más amplio en su planificación de sprint, lo que significa que debe dejar un búfer ligeramente más grande en su capacidad estimada.

En mi opinión, el proceso de señalar por su naturaleza ya tiene un amplio margen de error y, aunque está bien, sigo pensando que vale la pena considerar cualquier paso simple que podamos tomar para mejorar nuestra consistencia.

Sí, siempre es importante comunicarle a la parte relevante del equipo que una tarea llevará más tiempo.

Le sugiero que tenga algunas acciones cuando una estimación ha cambiado. Por ejemplo:

• ¿Todavía es alcanzable el objetivo del sprint?
• ¿Debería el equipo centrarse en otras tareas dado que el flujo de trabajo actual dependía de esta?
• Informe a todos los afectados por esto (no solo al equipo interno, por ejemplo, si fue parte de un entregable para las partes interesadas, también debería haber una manera de comunicarles estos cambios).
• Si tiene sentido hacerlo: registre los detalles de por qué necesitaba cambiar la estimación para que pueda usarse para hacer mejores estimaciones en el futuro

La estimación en Agile es una medida de complejidad e incertidumbre (un 5 está entre 3 y 8). Cambiar la estimación sobre la marcha es perjudicial: sus estimaciones históricas deben tener el mismo factor de incertidumbre y error que las estimaciones actuales. Comparar el tamaño estimado de la cartera de pedidos con la velocidad basada en "precisiones" es manzanas con naranjas.

Cuando tome más tiempo, solo diga: "Toma más tiempo, necesito desglosarlo" o algo así. Es por eso que tienes standups. Entonces la próxima vez no seas demasiado optimista.

Al final del sprint, debe verificar la precisión de la estimación en el nivel Sprint y aprender. Y subestimar es tan malo como sobreestimar.