Si tengo una historia que se estimó en 10 puntos de historia y no logramos completarla en un sprint, ¿cómo manejan las estimaciones para el sprint en el que se incluirá a continuación (suponiendo que se seleccione para desarrollo)? Suponiendo que el 80% del desarrollo se completó en la historia, ¿debería volver a estimarse (por el bien del argumento) en 2 puntos de la historia? ¿O debería mantenerse la estimación original y quemarse los 10 puntos de la historia cuando finalmente se complete? El enfoque anterior parece incorrecto porque una tarea 'grande' ahora parece pequeña. Esto último parece incorrecto porque seguramente representa mal la velocidad real en un sprint.
Si escribo una nueva historia para el trabajo restante, eso también parece una tergiversación porque el 80 % original del trabajo no se tiene en cuenta a menos que lo vuelva a estimar en 0 puntos y lo incluya junto con la nueva historia para el resto. trabajar y resolverlo al mismo tiempo que se completa la nueva historia de 2 puntos.
Nota
Para aquellos que estén interesados en los antecedentes de esta pregunta, surge del comportamiento ágil predeterminado de la junta directiva de JIRA, que consiste en devolver las historias incompletas a la parte superior de la cartera de pedidos. En general, los hemos estado reescribiendo y/o dividiendo en nuevas historias antes de hacer una nueva estimación en su contra, pero nunca estuve seguro de si esta era realmente la forma "correcta" de hacerlo.
Velocity es simplemente un proxy para medir la capacidad del equipo a lo largo del tiempo y no debe usarse para la contabilidad histórica del tiempo. Estime siempre en función del nivel actual de esfuerzo y complejidad, y esto naturalmente dará como resultado que las historias incompletas se reflejen en la velocidad como frenos a la capacidad.
No trate las historias como artefactos históricos. Las historias de usuario incompletas de iteraciones pasadas no deben incluir historial. En cambio, deben descomponerse, editarse y refinarse como si fueran un trabajo nuevo, y este nuevo trabajo debe estimarse sin tener en cuenta las estimaciones históricas o el progreso pasado.
Hay muchas razones para hacer esto. Una de las principales razones es asegurarse de que está rastreando la capacidad del equipo para completar nuevos objetivos , no el volumen de trabajo realizado anteriormente, a través de sus métricas de velocidad. Velocity simplemente no es la herramienta adecuada para la contabilidad histórica del tiempo.
Cada Sprint es una caja de tiempo efímera. Cuando planificas un Sprint, el progreso histórico es irrelevante. Lo que realmente está tratando de responder con su estimación es:
Según lo que sabemos y dónde estamos hoy , ¿cuánto esfuerzo se requiere para ofrecer esta característica ahora ?
Los cambios en el nivel de esfuerzo o la complejidad ocurren mucho en Scrum a medida que se reduce el cono de incertidumbre o se descubren nuevas eficiencias. Además, la naturaleza iterativa del desarrollo ágil significa que el contexto de una historia de usuario puede cambiar con el tiempo.
Por ejemplo, es posible que haya tenido una historia sobre la entrega de un widget de GUI que se estimó en 8 puntos hace varios sprints. Sin embargo, cuando se vuelve a estimar la historia, resulta que el equipo ahora conoce un complemento de terceros que simplemente se puede colocar en el código para proporcionar la función.
El esfuerzo para fusionar este complemento en su base de código actual se estima en 2 puntos. Ese es el nivel de esfuerzo requerido para implementar la característica hoy ; el hecho de que el equipo esté desechando 16.000 líneas de código (ya sea ese código bueno, malo o feo) de hace seis meses es irrelevante para medir la capacidad de la historia para encajar en el marco de tiempo actual .
A continuación se muestra mi respuesta a la pregunta ¿Qué hacer con la estimación de la historia incompleta? en el intercambio de pila de ingeniería de software. Aunque la pregunta está redactada de forma ligeramente diferente, básicamente pregunta lo mismo.
En primer lugar, ¿qué sucede con esas historias de usuario? ¿Simplemente los trasladas al siguiente sprint?
Eso depende. Si ninguna otra historia tiene una prioridad más alta, entonces sí, se mueven al siguiente sprint. Si otras historias tienen una prioridad más alta, entonces podrían volver a colocarse en la cartera de productos si no hay suficiente espacio en el sprint para acomodarlas. Todo esto sucede en la planificación del sprint, en función de las prioridades asignadas a cada historia por tu Product Owner. Dado que uno de los propósitos de los métodos ágiles como Scrum es maximizar el valor entregado y reducir el tiempo, todo se reduce a cuánto valor se agrega al terminar esas historias.
Independientemente de lo que suceda, aún debe esforzarse por obtener un producto potencialmente entregable al final del sprint. Esto podría significar retroceder para garantizar que el producto final del sprint pase todas las pruebas y que el usuario pueda utilizar todas las funciones completas sin ningún problema significativo.
Si es así, ¿deberían volver a estimarse? En mi opinión, ¿el trabajo restante en estas historias de usuario puede ser mínimo o mucho? ¿Si no, porque no?
No volvería a estimar porque, en Scrum, estimas una historia cuando la aceptas, comienzas a trabajar y no tienes un concepto de parcialmente completo . Una historia está 100% completa, probada y aceptada (terminada) o no está terminada. Si no existe el concepto de parcialmente completado, no hay forma de determinar cuánto trabajo queda en la historia. Parece que tampoco estoy solo en este pensamiento . Estimaste el trabajo que creías que podías hacer, así que deja este punto de datos y asegúrate de discutir por qué la estimación no fue correcta en tu sprint post mortem e intenta evitar cometer ese error en futuros sprints.
A lo que realmente quiere llegar es por qué no se hizo y por qué el equipo se comprometió a hacer algo que no pudo cumplir (especialmente si tiene este problema con frecuencia). La estimación es una herramienta para empoderar a un equipo para que asuman y comprendan sus compromisos, usarla con fines de planificación es una ocurrencia tardía.
La velocidad es una cantidad promedio de trabajo que se puede completar en una iteración, por lo tanto, ya sea que divida un 10 en un 8 y un 2, o que transfiera todo, la velocidad promedio a largo plazo del equipo no cambia.
Ahora, algunos miembros del equipo se sienten castigados si no reciben algún "crédito" por el trabajo que hicieron. Los puntos de la historia no equivalen a crédito o productividad para un miembro del equipo o cualquier parte interesada externa. Si hay conceptos erróneos externos o internos sobre qué puntos de la historia o la velocidad representan o para qué se usan, es un problema aparte que abordar.
Entonces, para responder a su pregunta de si dividir, transferir o volver a estimar... Vaya a la práctica que haga que su equipo se sienta capacitado para solucionar el problema real subyacente de por qué no se hizo la historia.
La velocidad mide la capacidad del equipo para "terminar" el trabajo en un sprint. No mide la capacidad del equipo para hacer que el trabajo avance.
Mi enfoque preferido sería volver a estimar la historia, teniendo en cuenta el trabajo que se había completado hasta el momento. Trataría esto como una nueva historia que debe priorizarse junto con todos los demás elementos en la cartera de productos. En su ejemplo, la historia de 10 puntos se convertiría en una historia de 2 puntos.
Al principio, esto puede parecer una representación errónea de la verdadera velocidad. Pero creo que es una medida eficaz de la capacidad del equipo para "terminar" el trabajo.
Recuerde que la razón más importante para medir la velocidad es permitir que el equipo apunte a una cantidad realista de trabajo en futuros sprints. No se trata ni nunca se ha tratado de medir el rendimiento del equipo.
La guía de scrum no dice nada sobre esto, lo que deja a las personas dibujar sus propias interpretaciones y utilizar diferentes enfoques.
Pasamos la historia completa al backlog y luego al siguiente sprint (invariablemente, ya que las prioridades de las funciones no cambian con tanta frecuencia). Sí, proyecta una velocidad incorrecta para ese sprint, pero se supone que Velocity se usa para la tasa de entrega en un lanzamiento. No significa mucho cuando lo ves solo.
Siempre que su objetivo sea predecir el futuro, debe volver a estimar los efectos indirectos antes del próximo Sprint o antes de volver a incluirlos en el Backlog. La razón de esto es muy clara: describe lo que realmente queda por hacer. No se le paga por los puntos de historia que entregó.
Todd A. Jacobs