Estamos trabajando lo más bien en un sprint, y unos días antes de terminarlo descubrimos un problema en una historia importante que le impedirá al equipo poder terminarla. ¿Qué se debería hacer? ¿Volver la historia al backlog para la próxima iteración, o extender la duración del sprint para poder terminarla?
Aquí tenemos dos opciones, que son retornar la historia al backlog o cancelar el sprint. Extender la duración del sprint viola uno de los principios del desarrollo iterativo de software. La idea del desarrollo iterativo es obtener feedback la mayor frecuencia posible. Por lo tanto, nunca debemos retrasar las iteraciones.
Además, la demostración de la iteración es un evento importante incluso aunque haya muy pocas características para mostrar, ya que es una oportunidad para reunirse y revisar el plan de la iteración. Aumentaremos la credibilidad del equipo y la confianza al admitir que no se pudo terminar una historia por defectos que encontramos. Por otro lado, si retrasamos la demo vamos a enviar el mensaje opuesto: que no tenemos el proceso bajo control y que nos retrasaremos todo el tiempo. Debemos agradecer al equipo por encontrar el problema antes que el cliente, y hay que usar la retrospectiva para descubrir lo que ocurrió en la historia.
Durante la retrospectiva debemos preguntarle al equipo cuál piensa que es el problema, y hacer un análisis de causa-raíz a partir de allí. Es probable que así encuentren respuestas.
A su vez, al mantener la demo y la retrospetiva le damos al Dueño del Producto una oportunidad para repriorizar las historias del próximo sprint.
Por otro lado, el Scrum Master podría empezar a analizar si hay problemas en la planificación: ¿por qué no se terminan las historias? ¿son muy grandes? ¿hay un criterio de aceptación claro?. Debemos recordar que las 6 características de una buena historia de usuario: Negociables, Valiosas, Estimables, Pequeñas y Testeables. A veces, nos olvidamos del "Pequeñas" y terminamos en problemas.
Muchas veces se pueden dividir las historias grandes en historias más pequeñas, que siguen cumpliendo las 6 características anteriores. Por ejemplo, consideren la siguinete historia para un sistema de anuncios online: "Como anunciante, quiero detener mi campaña ni bien se agote el presupuesto". Esta historia, que en algún caso podría ser demasiado grande para implementar, se podría dividir: "Como anunciante, quiero poder detener mi campaña en cualquier momento" y "Como anunciante, quiero saber cuánto llevo gastado en cualquier momento".
En todo caso, y más allá de todas las alternativas, hay algunas cosas que claramente debemos hacer:
- alertar al Dueño del Producto ni bien descubrimos un problema,
- hacer la demo con la funcionalidad lograda,
- permitirle al Dueño del Producto repriorizar,
- usar la retrospectiva para hacer un análisis de causa-raíz,
- no extender la duración del sprint.
