¿Deberíamos agregar más elementos a la acumulación de sprint si hay elementos que no se completaron?

Pregunta :

¿Deberíamos agregar más elementos en un sprint si hay elementos que no están completos pero un desarrollador está abierto?

Escenario :

Digamos que el equipo de desarrollo está compuesto por 5 miembros y tenemos el siguiente sprint backlog con una velocidad promedio de 29SP y actualmente estamos a la mitad de un sprint de 2 semanas:

Sprint Backlog
 - Login         8SP     State: In Development
 - Add User      12SP    State: Code Review
 - Update User   3SP     State: Done
 - Remove User   5SP     State: In Development

Product Backlog
 - Save User     2SP     State: Ready
 - ...More Stories...

La historia 3 acaba de completarse y el equipo todavía está ocupado con el resto de las historias, deberíamos preferir:

  1. Programa Swarm/Buddy para terminar el sprint ( prefiero ) o
  2. ¿Podemos agregar otra historia (pequeña historia, por ejemplo, 2SP) para el desarrollador abierto porque todos los demás miembros del equipo están ocupados con un elemento?

Como se indica en esta pregunta, sé que puede agregar elementos a un sprint "Sí, puede agregar historias a un sprint en ejecución..." si no afecta la publicación del objetivo del sprint (scrum.org)

Mi opinión es usar métodos como XP, Buddy Programming o Swarming para terminar el compromiso de sprint (si han terminado todos los elementos en su plato, ciertamente pueden realizar más trabajo si el equipo lo considera correcto) y si queda tiempo, pueden agregar otro elemento a la acumulación de sprint.

¿Cuál es tu opinión y cómo lidiaste con esto?

(Sé que lo que debo hacer también es mencionar esto en retro para entender por qué "se comprometió por debajo" o por qué las historias son demasiado grandes, etc.)

Hola inzefinite! La forma en que está estructurada su pregunta es propensa a las opiniones, e idealmente en la comunidad SE buscamos respuestas más generales... así que sugiero repensar (o al menos reformular) un poco. ¡Espero que esto ayude!

Respuestas (2)

He trabajado con equipos donde esta es la norma. Dicho esto, tendemos a recurrir a la Guía Scrum para saber cómo manejar esto. El equipo es responsable en última instancia de organizar y administrar su propio trabajo con un Scrum Master allí para guiarlos en la elección del mejor camino a seguir. Si bien el trabajo del Scrum Master es descubrir las opciones disponibles para el equipo, el empoderamiento de la elección tiende a involucrar la creatividad dentro del equipo y de los individuos.

Tiendo a evitar usar siempre y nunca , pero en casos como este siempre dejo que el equipo decida su mejor camino a seguir, siempre que se hayan considerado suficientes opciones antes de tomar una decisión. Ya sea que se cumpla o no el pronóstico, ayuda mucho a la psicología del equipo responsable de su propio trabajo.

Experimento.

Agile tiene que ver con la experimentación y la mejora continua: hable con el equipo, pruebe ambos, compare los resultados. Enjuague y repita.

Dicho esto, puede apegarse a técnicas ágiles que han demostrado ser efectivas a largo plazo, como la programación en pares (como sugirió), la programación en masa o el refinamiento de la acumulación.

Si su equipo es menos maduro o todavía se está esforzando por entrar en ágil, el equipo puede decidir agregar un elemento al sprint y seguir trabajando, lo cual está bien. Sin embargo, como Scrum Master, debes plantear estos escenarios como oportunidades de mejora y descubrir nuevas técnicas.