El elemento de Sprint tarda más de lo esperado para completarse. ¿Qué debemos hacer?

¿Qué debemos hacer si un elemento en scrum tarda más de lo esperado? Pregunto esto porque he notado elementos que los desarrolladores están luchando por completar, ya que es mucho más difícil de lo que inicialmente pensé.

En tal situación deberíamos

• eliminar el artículo del sprint de vuelta al catálogo de productos para que podamos cumplir con la línea de tiempo del sprint?
• pasar a un elemento de sprint más fácil y dejar un sprint problemático hasta el final de la línea de tiempo
• justificar en la revisión del sprint por qué el artículo no puede completarse en el sprint actual para las partes interesadas?

¿Cómo podemos evitar tal situación en el futuro? ¿Se debe a la falta de planificación inicial o no hicimos un esfuerzo para dividir el ítem sprint en un ítem más pequeño?

Con "elemento", supongo que te refieres a "tarea".

La planificación del optimismo en el software es tan antigua como el software en sí. Lo bueno de scrum es que lo enfrentará pronto y le dará visibilidad: es por eso que la velocidad de los equipos se basa en datos pasados ​​y no en estimaciones futuras.

Para completar una historia, también debe completar las tareas que resultan mucho más difíciles de lo anticipado. No hay excusa para posponerlos. (Es por eso que la definición de Done es tan importante). Si eso significa que el equipo está fallando una historia, entonces, lástima, tendrá algo de qué hablar en su próxima retrospectiva. La velocidad disminuirá (se volverá más realista) y el equipo aprenderá a hacer mejores estimaciones o dejará más margen de seguridad para tareas imprevistas. El propietario del producto obtendrá una visión más realista de su planificación de lanzamiento.

¿Qué debemos hacer si un elemento en scrum tarda más de lo esperado?

Suponiendo que por elemento te refieres a la historia, al final del sprint normalmente lo vuelves a colocar en la cartera de pedidos del producto (y probablemente lo planifiques para la próxima iteración). El equipo obtiene cero puntos por ello en la iteración actual.

Otra alternativa, si la historia es lo suficientemente grande, es cortarla verticalmente . Por ejemplo, la historia "búsqueda en el catálogo de productos", posiblemente se puede dividir en "buscar por categoría" y "búsqueda de texto completo", pero no en "formulario de búsqueda" y "resultados de búsqueda".

¿Cómo podemos evitar tal situación en el futuro?

No hay una respuesta directa fácil a esto. En scrum, haces retrospectivas de sprint en cada iteración, donde generalmente discutes este tipo de cosas con el equipo. Hay muchas posibilidades diferentes:

• El equipo, o algunos miembros del equipo, tienen una mala semana.
• Su equipo canaliza los elementos de trabajo horizontalmente (por ejemplo, backend-> frontend-> QA)
• Las historias son demasiado grandes por error.
• El equipo "chapa de oro" las historias agregando trabajo adicional que no es estrictamente necesario para completar la historia.
• Las historias son muy grandes por naturaleza, necesitas sprints más largos (poco probable)
• El equipo estima las historias de manera imprecisa (incoherentemente)
• El proyecto tiene mucha base tecnológica de deuda / código podrido y su velocidad es demasiado baja
• No estás midiendo y estimando tu capacidad de sprint correctamente (o en absoluto).

etcétera etcétera.

Dices que no lo terminarás, pero eso no está mal, solo son datos.

"Conocer la línea de tiempo del sprint" no es un objetivo. Su objetivo es completar historias de usuarios. La línea de tiempo es solo una herramienta para ayudarlo a medir y aprender cuánto trabajo puede hacer en un sprint.

Si está seguro de que no puede terminar el trabajo en el sprint, una solución es moverlo al final de la lista de prioridades y trabajar primero en las otras historias del sprint. Luego, con el tiempo restante, puede comenzar a trabajar en ello. Vuelva a estimar el trabajo para el próximo sprint y termínelo en ese momento.

Asegúrese en su retrospectiva de discutir lo que salió mal para que pueda mejorar sus estimaciones en el futuro.

Si una tarea lleva más tiempo de lo esperado, esto debe plantearse en retrospectiva y discutirse. ¿Se perdió alguna pieza en el análisis inicial? ¿Era algo que el equipo no había hecho ya a menudo? Hay muchas razones posibles por las que algo puede llevar más tiempo de lo estimado inicialmente.

El equipo debe tratar de hacer la tarea lo mejor posible y luego, en retrospectiva, discutir estrategias sobre esto en el futuro. Si el equipo es bastante nuevo en el uso de Scrum, entonces puede ser parte de calcular la velocidad inicial del equipo. Algunos equipos pueden pensar que pueden hacer 20 puntos y algunos equipos pueden hacer 60 puntos, el punto es qué tan consistentemente se puede hacer el mismo número de puntos en cada sprint.

Esto sucederá en el futuro, ya que cada vez que el equipo tenga nuevas tareas que no haya hecho antes, se tomará un tiempo para resolver los problemas de hacer estimaciones. Esto es parte del proceso de aprendizaje que realmente no debería ser tan sorprendente.

Lo que generalmente hacemos en nuestra empresa cuando una tarea comienza a tomar más tiempo de lo esperado es dividirla en tareas más pequeñas.

De esa manera, no culpamos al desarrollador por ser demasiado lento, pero también reconocemos que la tarea se diseñó incorrectamente.

Otra cosa podría ser asignar la tarea a otro miembro de su Equipo de Desarrollo para evitar que su desarrollador tardío se hunda en un hoyo. Y si la tarea es realmente crítica, algunos XP podrían ser la solución.