¿Está bien volver a señalar la historia al comienzo del nuevo sprint para reflejar el tamaño que ahora hemos descubierto que tiene para que nuestra velocidad sea más precisa?
En raras ocasiones, nuestro equipo trabajará en una historia que pensamos que habíamos dividido en una historia pequeña y granular, pero termina tomando todo el sprint y transfiriéndola (puede o no tener un impedimento). ¿Podemos asignarle un valor de punto de historia diferente para reflejar el esfuerzo que realmente tomó completarlo?
Como alternativa, ¿podemos actualizar la definición de hecho para que la historia se pueda cerrar en el sprint actual? Entiendo que esto no es ideal y podría abusarse para que todo se cierre al final de un sprint, pero estoy hablando de las historias en las que sabes que has superado MUCHO la estimación original de puntos y no quieres tu predictor de velocidad. estar sesgado.
@Péter Török te dio una gran respuesta. Sin embargo, me gustaría estar en desacuerdo con un aspecto de lo que dijo: "Aceptó una historia en el sprint que aún no se entendía lo suficientemente bien como para estar lista para el desarrollo. No pudo identificar a tiempo una parte importante del trabajo para ser completado..." Parece esperar que pueda predecir completamente el trabajo durante la planificación del sprint y que no debería haber sorpresas. ¡No realmente!
El desarrollo de software, por su propia naturaleza, es parte de I+D y es impredecible. Esta es la razón por la que practicamos Scrum, con su transparencia y ciclos de inspección/adaptación.
Aquí está el extracto relevante de la Guía Scrum :
El Equipo de Desarrollo modifica el Sprint Backlog a lo largo del Sprint, y el Sprint Backlog emerge durante el Sprint. Este surgimiento ocurre a medida que el Equipo de Desarrollo trabaja en el plan y aprende más sobre el trabajo necesario para lograr el Sprint Goal.
A medida que se requiere trabajo nuevo, el Equipo de Desarrollo lo agrega al Sprint Backlog. A medida que se realiza o completa el trabajo, se actualiza el trabajo restante estimado. Cuando los elementos del plan se consideran innecesarios, se eliminan.
Entonces, en mi opinión:
Si ocurre con frecuencia, haz todo lo que te sugiera Péter.
Ejercer la debida diligencia adecuada para evitar tales sorpresas. Dos de las prácticas valiosas que puedo recomendar encarecidamente son: hacer una historia de investigación para dimensionar el trabajo desconocido y construir una prueba de concepto para minimizar el riesgo en un trabajo impredecible. Si, después de hacer todo lo que haces, te encuentras con un problema, como dijiste en raras ocasiones, puedes volver a estimar el trabajo restante al comienzo del próximo sprint, vuelve a priorizar y sigue adelante.
En mi humilde opinión, debatir si reestimar o no la historia y cómo esto afecta su velocidad es tratar el síntoma en lugar de la causa raíz. En la próxima retrospectiva (o incluso antes, en una reunión dedicada, si este es realmente un problema tan recurrente), debe centrarse en por qué ocurre esto y cómo evitarlo en el futuro.
Esto indica un problema en el proceso de planificación del trabajo pendiente y de planificación de sprints (como dices, esto sucede solo en raras ocasiones, lo que me hace suponer que, sin embargo, practicas la preparación del trabajo pendiente en general). Aceptaste una historia en el sprint que aún no se entendía lo suficientemente bien como para estar lista para el desarrollo. No pudo identificar a tiempo una parte importante del trabajo a completar y ahora tiene una gran historia que es demasiado grande para el sprint.
¿Está bien volver a señalar la historia al comienzo del nuevo sprint, [...] o actualizar la definición de hecho para que la historia pueda cerrarse en el sprint actual?
Las historias nunca deberían ocupar un sprint completo. Pero si descubre este sprint medio, en mi opinión, ninguna de estas opciones es realmente buena. Creo que lo mejor es dividir la historia de gran tamaño en nuevas historias más pequeñas en función de la comprensión recién adquirida, en lugar de mantenerla en una sola pieza. Luego, puede volver a estimar cada nueva historia, priorizarlas y decidir cuánto puede manejar en el sprint actual. Esto todavía es complicado en el mejor de los casos, por lo que en este punto es posible que desee cancelar el sprint de acuerdo con el PO y comenzar a planificar el sprint nuevamente. Es una medida drástica, sin duda. Pero su sprint está seriamente desordenado, por lo que puede ser mejor y más acorde con el espíritu de Scrum sacar el problema a la superficie y tratarlo desde el principio.
Esta respuesta se centra menos en qué hacer con las estimaciones incorrectas y más en por qué no debe alterar las estimaciones históricas. Usted pregunta:
¿Está bien volver a señalar la historia al comienzo del nuevo sprint para reflejar el tamaño que ahora hemos descubierto que tiene para que nuestra velocidad sea más precisa?
La respuesta corta es no." Esto es un malentendido de lo que es la velocidad y para qué sirve.
Ret-conning sus métricas de velocidad es un olor a proyecto que indica que la velocidad se está utilizando indebidamente para establecer objetivos de gestión o para justificar de alguna manera al equipo, en lugar de como una herramienta de planificación que mide la capacidad del equipo.
La velocidad no es un solo número. Idealmente, la velocidad es un rango estadístico durante un período posterior. La velocidad es útil para estimar la capacidad general del equipo , pero no pretende ser una métrica para realizar un seguimiento de los elementos de trabajo completados o los niveles históricos de esfuerzo.
Además, la velocidad mide implícitamente la madurez de su proceso de estimación y, por lo tanto, no debe manipularse retroactivamente. Por ejemplo:
Por supuesto, si una historia permanece sin terminar al final de un Sprint, se puede volver a estimar, con suerte de una manera más precisa, durante una futura sesión de Planificación de Sprint. Eso no cambia los puntos de la historia que se le asignaron en un Sprint anterior (irrelevante), o los puntos de la historia que restó de la quema de su proyecto (cero). En cambio, cuando se desprenda de la parte superior de la Lista de Producto en algún momento en el futuro, será simplemente una nueva estimación para el Sprint actual basada en lo que el equipo sabe en ese momento.
Ocurren cálculos erróneos. Se deben esperar pequeñas variaciones en la precisión de sus estimaciones, y su proceso puede absorberlas si no se compromete en exceso. Sin embargo, las grandes variaciones en la precisión o las estimaciones extremadamente inexactas son un problema de proceso que debe abordar todo el equipo Scrum, incluido el propietario del producto.
Además, es posible que no tengas un Sprint Goal bien articulado. Gestionar las estimaciones y los elementos del backlog en ausencia de un Sprint Goal definido para cada Sprint es un ejercicio inútil. No hagas eso.
Un solo elemento de Sprint Backlog nunca debe tener un tamaño superior a 2 o 3 días hábiles. La regla general es que cada tarea en el trabajo pendiente debe estar "terminada" o "no terminada" en 1/2 día a 2 días, por lo que debe tener una buena idea dentro de un par de días si una historia está en camino o no. no.
Durante el stand-up diario, se deben identificar las historias que se deslizan. Además, su Sprint Backlog o tablero Kanban debe identificar claramente las historias en progreso que están atascadas para que el equipo pueda abordar cualquier impedimento.
Scrum, al igual que otras metodologías, espera una cierta cantidad de holgura en su proceso para mantener el flujo fluido. Una historia ligeramente mal estimada generalmente se puede absorber sin problemas, pero los errores de cálculo salvajes requieren técnicas más disruptivas para manejarlos.
Como regla general informal, si su Sprint burn-down está fuera de control en más del 30%, o si tiene una sola historia de ruta crítica que está más del 50% por encima de lo estimado, entonces probablemente valga la pena escalar el asunto. Incluso si el equipo se recupera de los errores de cálculo durante el Sprint actual, debería ser agua para el molino en su próxima Retrospectiva del Sprint.
Una historia incorrectamente estimada debe identificarse dentro de 2 a 6 días hábiles. Permitir que una tarea se resbale un 200 % sin desencadenar alguna acción o conciencia dentro del equipo sería simplemente una tontería.
En ese momento, usted debe:
Determine si la historia es esencial para el Sprint Goal.
Si no es así, discuta sacarlo del Sprint actual con el propietario del producto. Pueden hacer esto juntos siempre que no comprometa el Sprint Goal.
Vuelva a estimar la tarea.
Si la historia es esencial para el Sprint Goal, debe tomar de 10 a 15 minutos con el equipo para volver a estimar la historia y determinar si la historia puede encajar dentro del Sprint actual, con o sin cambios en el Sprint Backlog.
Agregue capacidad recortando otro alcance.
Si su historia es esencial, pero tiene otras historias que no lo son, el propietario del producto puede expulsar las historias no esenciales para recortar el alcance. Además, puede recortar el alcance de una variedad de elementos del Sprint Backlog sin comprometer el Sprint Goal.
Solicitar una terminación anticipada del Sprint actual.
Si la historia es esencial para el objetivo del Sprint y no se puede recortar el alcance suficiente para terminar la historia dentro del Sprint actual, debe solicitar que el Dueño del producto llame a una Terminación anticipada del Sprint, seguida de una Retrospectiva del Sprint y una volver a Planificación de Sprint.
Cualquier historia que no esté terminada al final de un Sprint se devuelve al Product Backlog para que el Product Owner la disponga. El Propietario del producto puede eliminar la prioridad o volver a definir el alcance de la historia, eliminarla del Backlog o puede optar por volver a colocarla en la parte superior del Product Backlog para incluirla en el próximo Sprint.
Si la historia permanece dentro del alcance de su próximo Sprint, debe volver a estimarse y descomponerse nuevamente durante el proceso de planificación de primavera, como cualquier otra historia. Con suerte, el Equipo Scrum lo manejará mejor la segunda vez, y las estimaciones y las tareas descompuestas deberían ser más confiables.
Si una historia aparece por tercera vez, entonces tiene un problema de proceso más grande que una sola historia mal estimada. Arregla eso.
Péter Török