Scrum sobreestimación y replanificación

Estamos en el medio de nuestro primer Sprint y algo nos afecta: ¡lo sobreestimamos!

Habíamos planeado 114 horas ideales para esta iteración de 2 semanas y al final de la primera semana terminamos todo el Sprint. ¿Que hacemos ahora? El "libro" dice que deberíamos, y lo haremos, obtener los siguientes elementos de alta prioridad de la cartera de pedidos. Sin embargo, ¿cómo los agregamos al cuadro de quemado? ¿Lo reescribimos para explicar esas historias como si estuvieran allí desde el principio? ¿O simplemente agrega sus estimaciones al eje y el día que comenzamos a trabajar en ellas (mostrando un salto de ángulo de 90o)?

Cualquier comentario es bienvenido!

Uno de los propósitos de tener un gráfico de consumo es mostrar cómo, con el tiempo y de manera transparente, se ofrece valor.

Las historias de los nuevos usuarios no estaban en el sprint al principio, por lo que parece un poco difícil fingir que sí. Al agregarlos al gráfico de consumo en este momento, está mostrando con precisión que el nivel actual de estimación todavía está en sus fases evolutivas preliminares.

Esto es bueno para usted y para el propietario de su producto. Muestra y mostrará cómo usar este sistema de gestión de proyectos le permitirá convertirse en un mejor estimador.

Podrá ver desde el principio que estaba sobreestimando, luego subestimando, luego sobreestimando un poco más pero un poco menos ... y eventualmente verá las mejoras en la estimación a medida que avanza.

Creo que estimar las historias de los usuarios es una de las partes más difíciles de un sprint y solo una vez que su equipo aprenda a evolucionar juntos se volverá cada vez más eficiente en el proceso. Es bueno que esto se demuestre a través de las herramientas que está utilizando, como el gráfico de burndown.

No dolerá si cancela el sprint , y planifique el próximo sprint teniendo en cuenta su velocidad actual.

De la Guía oficial de Scrum :

Los sprints se pueden cancelar antes de que termine el cuadro de tiempo de Sprint. Solo el propietario del producto tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de las partes interesadas, el equipo o el ScrumMaster.

Dado que la planificación del sprint debe realizarse dentro de una discusión con el propietario del producto, el scrum master y el equipo, sería contraproducente simplemente elegir las siguientes historias de usuarios.

En el caso de que estuviera un poco adelantado, podría haber elegido la siguiente historia con la mayor prioridad, pero aquí su situación es muy diferente.

Puede agregar un gráfico de quemado . Muestran, sin ambigüedad, cuándo y cuánto trabajo nuevo ha agregado:

Este gráfico muestra que el equipo agregó 20 puntos más de trabajo en la iteración 5. Esta imagen muestra iteraciones, pero funciona igual de bien con los días.

Hay varias técnicas diferentes para visualizar esto.

Una de ellas es introducir un desplazamiento en el eje y (el eje horizontal) el día en que se agregaron las nuevas historias, con el gráfico de quemado real y luego ir por debajo del nivel original "0".

Otra es fingir que estuvieron allí desde el principio (lo cual es mucho más fácil si utiliza gráficos de carga basados ​​en CGI).

Y podrías inventar el tuyo.

Lo más importante es discutir esto entre el equipo, el scrum master y el propietario del producto para llegar a un acuerdo sobre lo que quiere hacer en esta situación. No hay una forma absolutamente fija de hacer nada en scrum que no sean las reglas básicas. Scrum está destinado a evolucionar con el tiempo para adaptarse mejor a las necesidades de su entorno.

Me gustaría dividir el problema del OP en tres preguntas distintas:

1. ¿Continuar o cancelar el sprint?
2. ¿Qué hacer en la semana restante si el sprint continúa?
3. ¿Cómo planificar el próximo sprint?

Los cuadros de quemado y quemado mencionados en otras preguntas, si bien son útiles, son secundarios al OP "¿qué hacemos ahora?"

Continuar o cancelar : estoy con Pierre aquí, es apropiado cancelar este sprint y comenzar a planificar el próximo inmediatamente. La cancelación del sprint no es una opción si hay otros equipos y los sprints necesitan sincronizarse (la mayoría de los gurús de Scrum aconsejan que deberían sincronizarse).

Si el sprint continúa: Limite el trabajo en progreso . Trabaje solo en una historia a la vez, concéntrese en terminar, para lo cual tiene menos de una semana. Asegúrese de que no haya historias en un estado parcialmente terminado al final del sprint.

Cómo planificar el siguiente : las opciones aquí son probar la estimación del tamaño relativo o usar la equivalencia de punto de persona-día y el factor de enfoque como una aproximación como se describe en el libro "Scrum and XP from the Trenches" de Henrik Kniberg. Ya lo hemos discutido en un hilo diferente.

Completar en la mitad del tiempo es una gran variación de las estimaciones. Para mí, eso indicaría un riesgo significativo de que lo que su equipo realmente hizo se desvía de lo que los usuarios esperaban al comienzo del Sprint. Además, también se supone que un Sprint ofrece suficiente funcionalidad que ahora es el momento de recibir nuevos comentarios de la OP.

Por lo tanto, el riesgo de solo tomar cosas de la parte superior del PB y continuar es que esos elementos en la parte superior del PB están desactualizados (tanto en contenido como en prioridad), y que su Equipo ha tenido algo mal en el último Sprint y se basará en esos errores sin recibir comentarios de la OP.

Yo diría que el curso de acción más razonable es llamar al Sprint terminado, realizar su revisión habitual al final del Sprint, planificar una reunión y retrospectiva y comenzar el próximo Sprint.

En cuanto a las cosas del cuadro de burndown, la pregunta original parece perder el sentido de para qué sirve. Realmente es solo una herramienta para determinar si tienes un problema con el progreso durante tu Sprint. Con lo que se describió, la tabla de consumo debería haber entrado en juego en esta situación aproximadamente el día 2 o 3 del Sprint, cuando habría demostrado que el Equipo estaba muy por delante de lo previsto en las tareas de Sprint. Luego, hace la pregunta "¿Por qué?", ​​Y determina si sus estimaciones estaban muy lejos o si los programadores están interpretando mal las tareas, o si algo está saliendo de los rieles de alguna manera.

Pero cuando ignoras la tabla de consumo y navegas como si no hubiera nada extraño, entonces parece que solo lo estás tratando como un artefacto sin sentido que estás produciendo porque el "libro" te dice que lo hagas. En mi opinión, si decide simplemente sacar algunas cosas más de la parte superior del PB y continuar durante la segunda semana, entonces simplemente comience un nuevo burndown para la segunda semana (y luego puede ignorar como lo hizo para La primera semana).

Consultaría con el propietario del producto sobre qué trabajo hacer y lo agregaría al sprint actual en la fecha en que se trajo el trabajo. Se puede rastrear el trabajo agregado en la tabla de quemado. No tengo ningún problema con un gráfico de quemado que se parece un poco a una montaña rusa. Esto sucederá de todos modos ya que los miembros de scrum estiman el tiempo restante en las tareas.