Tenemos una historia de bajo punto que fue completa en desarrollo pero, durante las pruebas, reveló un problema. Al investigar el problema, se descubrió que se requerirá una parte externa para entregar una solución. La parte externa no entregará esa corrección antes del final del Sprint. Por lo tanto, nuestra historia está bloqueada hasta que la parte externa entregue su solución.
Con la solución de terceros requerida, ahora tiene efectivamente una condición previa para su historia (que supuso que estaría presente desde el principio, pero resultó que no lo estaba).
Debe volver a colocar la historia en la cartera de pedidos al final del sprint. No está hecho. Si lo coloca en un próximo sprint depende de las reglas de su equipo, pero no lo haría a menos que la condición previa se verifique y valide antes del inicio del sprint .
Un sprint debe llenarse con elementos para que el equipo piense que puede entregar esa cantidad al final del sprint. Si no está claro si una condición previa se puede cumplir durante el sprint, ni siquiera debería ser un tema en la reunión de planificación, aparte de decir "¿las condiciones previas no están disponibles? Bien, SIGUIENTE". Un sprint solo debe llenarse con elementos que el equipo pueda entregar.
Como siempre, pueden aplicarse excepciones. Un nuevo elemento de trabajo pendiente para el próximo sprint podría ser "comprobar si el error aún no se solucionó en su versión 1.2.3 que sale el martes". Eso se puede hacer, aunque el resultado "terminado" de la historia podría ser "todavía tiene errores, no podemos continuar con la historia original en el próximo sprint".
¡Esta es una gran pregunta y una oportunidad para aprender! Sí, coloque la historia bloqueada en la cartera de productos si tiene un reemplazo de tamaño similar y en la próxima retrospectiva discuta:
¿Qué dice esto sobre nuestra estimación y definición de listo ?
Si esta historia se desbloquea antes del final del Sprint, ¿puede y/o debe completarse antes que la historia de reemplazo?
Además, con Kanban, puede insertar un "cuadro bloqueado" en cada columna WIP (el elemento bloqueado no debe contar para sus números WIP) y esta historia sería automáticamente el elemento de mayor prioridad cuando se desbloquee.
También diría que este tipo de cosas deberían ser rastreadas de alguna manera por el equipo como "retrasadas externamente". (Independientemente del "nombre de scrum" para esta noción.) Todas y cada una de las (!) veces que el equipo se desplaza para planificar su próximo "sprint", debe revisar explícitamente el estado de todos estos elementos, para llamar la atención de la gerencia sobre el asunto (y a las implicaciones de todo el proyecto). No se limite a darle una "mención pasajera" en el informe de su proyecto: para alguien [más], este es un elemento de acción .
La gerencia necesita saber, y saber a tiempo , que este tipo de cosas están sucediendo, y especialmente si suceden repetidamente. Considere el deber de su equipo notificarles y mantenerlos informados.
"Este es el por qué."
En mi opinión, estos representan dependencias funcionales que existen entre "el proyecto en el que está trabajando su equipo" y "otros proyectos con los que no tiene nada que ver". Estos son los que determinan "la ruta crítica" en una organización o incluso a nivel empresarial . Podrían representar fácilmente problemas de implementación y/u operativos cuando su proyecto "se ponga en marcha". Si bien estos no son per se "su preocupación", deben ser reconocidos explícitamente y rastreados tanto dentro de su proyecto como [¿muy lejos?] Por encima de él.
Todd A. Jacobs