Digamos que un proyecto tiene 2 o más Sprints y para cada Sprint está utilizando un gráfico de quemado para seguir el progreso del Sprint. Si al final del primer sprint hay tareas que se iniciaron pero no se completaron y, por lo tanto, pasarán al siguiente sprint para trabajar en cómo se manejarían esas tareas en el gráfico de quemado del próximo sprint, ¿ajusta el estimado? tiempo para que las tareas reflejen el hecho de que se ha trabajado en ellas o utilizar el tiempo estimado original? Gracias.
He probado ambos con mi equipo. El que encontramos que tiene más sentido es ajustar la estimación. La idea de Agile es actualizar su plan en función de nueva información. Actualizar sus estimaciones para reflejar el trabajo restante para sus Historias hará que la estimación sea mucho más fácil y reflejará mejor lo que realmente está sucediendo en Sprint 2.
Lo único que realmente 'perdió' es el esfuerzo general que se requirió para esa Historia, pero se decidió (en nuestro caso) que realmente ni siquiera necesitábamos eso.
TL: DR: use la estimación original. Mantiene sus datos consistentes, responsabiliza al equipo y refleja la naturaleza real del trabajo en una configuración de Scrum.
Esta respuesta se basa en ganarse la vida como entrenador ágil a tiempo completo y haber experimentado las formas saludables y no saludables de lidiar con el trabajo sin terminar.
Por qué : una de las mejores cosas de Agile es su naturaleza binaria para el seguimiento del trabajo. El trabajo es Terminado o No terminado. No hay ambigüedad en esto. Al final del sprint, la historia es "potencialmente entregable" o efectivamente "ni siquiera ha comenzado". Nunca hay un área gris de "Oh, hemos terminado en un 90%" y luego estar terminado en un 90% durante tres sprints.
Advertencia : voy a hablar sobre Scrum de nivel Shu, o "scrum inicial". A medida que un equipo obtiene un rendimiento demasiado alto (o nivel de Ri), pueden comenzar a experimentar con los conceptos básicos. Hasta que lo hagan, siempre recomiendo comenzar con lo básico. La razón es que hay más de 30 años detrás de por qué esos conceptos básicos funcionan. Si tiene problemas con esta premisa, le recomiendo el blog de Ron Jefferies " Probamos el béisbol, no funcionó ".
En primer lugar, cuando llega al final del sprint, todo se mueve desde la acumulación del sprint a la acumulación del producto. La planificación comienza de nuevo. Han pasado dos semanas y el propietario del producto debe priorizar el trabajo pendiente en función de la realidad actual. Aunque el equipo dedicó dos semanas a algo, es posible que ya no sea una prioridad y que el propietario del producto decida abandonarlo. Esto está 100% bien, no es un costo irrecuperable. En cambio, se da cuenta de que algo ya no es valioso y decide no enviarlo y, por lo tanto, incurre en el costo de mantenerlo. Una empresa para la que trabajé una vez terminó en un aprieto con eBay porque habían implementado esta característica "bonita", que realmente no funcionó, en la que eBay terminó confiando para negocios de misión crítica. Terminaron teniendo que soportar esta pobre función durante más de una década.
A continuación, no vuelve a estimar el trabajo en curso. Hay un número de razones. La parte superior de la lista es que el resto del mundo no se quedó quieto durante las últimas dos semanas. Incluso si la historia está "terminada en un 90%" (ver arriba), no se ha implementado y conozco muy pocos sistemas que no cambien en el transcurso de dos semanas. Es probable que ese código esté desactualizado para el sistema actual. Necesitas repasar toda la historia y asegurarte de que funcione con el entorno actual.
La reestimación también destruirá por completo sus métricas de velocidad. Esto reducirá la capacidad del equipo para planificar el trabajo de manera predecible.
Al final del día, si no está terminando las historias en un sprint, debe preguntarse por qué no poner una curita en el problema y seguir adelante. Haga sus historias más pequeñas, planifique menos trabajo, arregle su proceso de lanzamiento, lo que sea. Simplemente no vuelva a estimar.
Ah, y no divida la historia en trabajo hecho y no hecho. Ese es otro antipatrón ágil.
Un gráfico de trabajo pendiente de Sprint rastrea el trabajo restante, no el trabajo completado. Si desea realizar un seguimiento del trabajo completado, utilice un gráfico de quemado en su lugar.
El cuarto valor del Manifiesto Ágil es responder al cambio siguiendo un plan. Llevar adelante el trabajo de forma automática no solo viola el principio del límite de tiempo que sustenta el marco Scrum, sino que también reduce la capacidad de un equipo para adaptarse a los requisitos cambiantes.
Cuando se implementa correctamente, el trabajo en Scrum nunca se transfiere automáticamente de Sprint a Sprint. Los incrementos de trabajo, ya sea que se realicen o no, siempre deben inspeccionarse y adaptarse en los límites de la caja de tiempo. Cualquier trabajo que esté incompleto al final de un Sprint se vuelve a colocar en el Product Backlog, donde el Product Owner puede volver a priorizarlo (o incluso descartarlo por completo) según las necesidades cambiantes del negocio o el Sprint Goal actual.
La próxima vez que el trabajo esté dentro del alcance de Sprint Planning, el equipo vuelve a planificar y estimar el trabajo en función de la nueva información, el contexto actual y el nivel de esfuerzo restante para completar el trabajo. Si bien las lecciones aprendidas sobre el trabajo de Sprints anteriores pueden informar el proceso de estimación, las estimaciones históricas se descartan como irrelevantes para el cuadro de tiempo actual.
Las siguientes respuestas están relacionadas, aunque las preguntas que abordan no son necesariamente duplicados exactos de la que está preguntando actualmente. Ofrecen explicaciones y orientación adicionales sobre la importancia de la reestimación y la replanificación.
Todd A. Jacobs
nathan cooper