Stories incompletas al final de Sprint, ¿Que hacemos?

Por Gerardo Morales, Registered Scrum Trainer™

Tu Scrum team trabajó muy duro y logró terminar 5 stories, y también trabajó en una sexta story y está casi terminada.  Lo normal es pasar esa user story al siguiente Sprint y comenzar con esa... ¿No?

Bueno, la respuesta corta es: No

Elaboremos un poco más mi escueta respuesta. Nosotros los ingenieros tendemos mucho a enfocarnos en producir y tenemos la falsa sensación de que el hecho de construir lo que habíamos planeado originalmente es equivalente a tener éxito.

1. No la pases automáticamente al siguiente Sprint

Una de las bellezas de Scrum es que te permite ir re-adaptando el plan de construcción de tu producto basado 100% en las necesidades de negocio.  Explotando esta bondad del marco de trabajo Scrum, las preguntas que debes de hacerte como equipo son: Esta parte del producto que no logramos terminar durante el sprint; ¿Sigue siendo relevante para nuestros usuarios? ¿Sigue dando valor? ¿Sigue teniendo prioridad por sobre todos los otros items del Product Backlog.

Obviamente quién debe de liderar el hecho de que estas preguntas sean contestadas es el Product Owner, y también quién debe decidir si la user story "casi terminada" debe de ser terminada en el próximo Sprint o debe de ser substituida por otros nuevos elementos del Product Backlog que tengan mayor prioridad para el negocio.

Así que contestando a tu pregunta de una forma más elaborada, debes permitir que sea el Product Owner quién decida cuáles son los elementos prioritarios para el próximo Sprint, y no debes de forzarlo a que acepte a que los developers le dediquen tiempo a otros elementos solo por que ya "casi" estaban terminados. Si esa story pasó a un plano menos prioritario porque los resultados del sprint o o circunstancias del mercado detonaron otras tareas más importantes, el que el equipo la trabaje no agilizará el proyecto.  

 2. No agregues los puntos extras a tu velocidad

Es necesario que permitamos a Scrum sonar sus alarmas cuando sea necesario; una baja en la velocidad de un equipo no significa que el equipo esté haciendo un mal trabajo. Solo es una alarma que significa que algo sucedió y debemos de reaccionar inspeccionando el problema que causó que no lográramos cumplir con nuestro compromiso y hagamos las adaptaciones necesarias para evitar que esto suceda de nuevo. 

Es decir, para mí, agregar puntos que equivalen a lo que sí logramos hacer de la story incompleta para que la velocidad del equipo no caiga, es como desactivar las alarmas de humo de para que en caso de incendios no se haga mucho escándalo.

3. Discute con tu Product Owner para ver cómo proceder.

¿Qué hay que hacer para terminar la user story?  ¿Es necesario re-estimar o volver a escribir la user story? Todo esto deben de discutirlo todos los miembros del Scrum Team. 

Al terminar un Sprint, todos los items no terminados del Sprint deben de ser devueltos al Product Owner para que los regrese al Product Backlog, el PO entonces puede reorganizar prioridades y tener un PB revisado listo para el próximo Sprint. Es importante en este momento que ayudes a tu Product Owner a tener visibilidad total de hasta donde llegaron en el avance de la story y cómo proceder a hacerle cambios necesarios al product backlog item (o user story) antes de meter este elemento a un nuevo Sprint.

Tener items no terminados al final del Sprint es algo que suele suceder y no debe de ser demonizado. Lo importante es lograr proseguir con el desarrollo de las stories que necesiten el negocio y también entender porqué no logramos cumplir con el compromiso que hicimos al iniciar el Sprint y ver cómo no volver a cometer ese mismo exacto error en futuros Sprints.