¿Cuándo se considera completado un Sprint?

Es bastante común que un equipo tenga trabajo sin terminar al final de un Sprint ágil o una iteración. Idealmente, un equipo siempre completaría cada item del Sprint Backlog durante el Sprint. Por diversas razones, sin embargo, esto no siempre es el caso. Esto nos lleva a algunas preguntas que abordaré a continuación:

• ¿Qué debe pasar con el Product Backlog Item en cuestión?

• ¿Debe dividirse o trasladarse al siguiente Sprint? ¿Debe el equipo contabilizar los puntos de las partes terminadas de la Story en la Velocity?

¿Sigue siendo relevante el item?

Cuando un Product Backlog Item no se ha completado al final de un Sprint, debería volver al Product Backlog. Los trabajos nunca se trasladan automáticamente de un Sprint al siguiente.

Quizás estoy siendo un poco quisquilloso con este tema, pero lo que me importa es que cada Sprint comience con que el Product Owner tome una decisión consciente sobre en qué debe trabajar el equipo. Naturalmente, es muy probable que el Product Owner quiera que el equipo termine en el nuevo Sprint los trabajos incompletos del Sprint anterior. Sin embargo, esto siempre debe ser una decisión consciente del Product Owner.

(Solo como nota: no estoy diciendo que debas crear trabajo extra si usas una herramienta con la que esto sería demasiado complicado. Solo digo que el trabajo no se traslada automáticamente al siguiente Sprint. El Product Owner siempre debe decidir si el trabajo sigue siendo relevante.)

¿Dividir o trasladar al siguiente Sprint?

Cuando un Product Backlog no pudo completarse del todo, los miembros del equipo a menudo se preguntan si deben dejar el Product Backlog Item tal cual (aunque parte de la funcionalidad ya esté lista) o si deben reescribirlo para que solo describa la parte que falta.

Ejemplo: Tomemos como ejemplo un equipo que trabaja en una función típica de vista previa de impresión para una aplicación de escritorio. Si el equipo ha completado todo excepto la función de retroceder páginas, los miembros del equipo pueden llevar la User Story original al siguiente Sprint o escribir una Story más pequeña: "Como usuario, quiero poder retroceder cuando se muestra la vista previa de impresión."

Si la Story se completará en el siguiente Sprint, yo sugeriría dejarla tal cual y no reescribirla. Todos conocen la Story tal como está escrita. Así que si el Product Owner aún la considera importante, pasa sin cambios al siguiente Sprint.

Sin embargo, si el trabajo restante se pospone para un Sprint posterior, debería escribirse una nueva Story que describa solo la parte incompleta de la funcionalidad.

Recuerda: Si el trabajo se completará en el siguiente Sprint, la Story no se reescribe.

¿Recibe el equipo puntos para la Velocity?

Me gusta adoptar una postura algo conservadora respecto a la Velocity. Esto significa que un equipo solo debería recibir puntos por el trabajo que realmente esté completamente terminado. Esto significa:

1. Si un Product Backlog Item incompleto se traslada al siguiente Sprint y se completa allí, el equipo no debería recibir puntos en el Sprint original. En su lugar, el equipo recibe todos los puntos de la Story en el Sprint en el que el trabajo realmente se termina. Como de todos modos estoy a favor de trabajar con una Velocity promedio, esto se equilibra y no existe riesgo de que la Velocity sea sobreestimada.

2. Es diferente, sin embargo, cuando el equipo divide la Story y devuelve el trabajo restante al Product Backlog para trabajar en él más adelante. En este caso, los puntos por el trabajo realizado se acreditan al equipo. Los miembros del equipo deben estimar lo mejor posible cuántos puntos vale el trabajo realizado. Aunque la Story completa aún no esté terminada, es posible que el equipo reciba todos los puntos originales de la Story, ya que es posible que la Story haya sido más grande de lo previsto. Esto no debería pasar constantemente, pero de vez en cuando está bien.

Conclusión: Siempre buscar la causa

Cuando hay trabajo sin terminar al final del Sprint, el equipo siempre debe tomarse tiempo en la Retrospectiva para averiguar si la causa habría sido evitable. A veces es simplemente mala suerte o mal timing; por ejemplo, cuando un miembro del equipo se enferma o surge un problema que no se podía prever al inicio del Sprint. Pero siempre es aconsejable reflexionar sobre cuál fue la causa y cómo se puede prevenir en el futuro.

Este texto proviene del blog de Mike Cohn y fue traducido al español.

User Stories, Epics, Themes

Explicamos la diferencia entre estos items.
=>User Stories, Epics, Themes

Desarrollar un producto

De la idea al producto terminado con el Product Vision Board.
=>Product Vision Board

¿Qué son los Story Points?

Descubre dónde puedes mejorar la estimación de tu equipo.
=>¿Qué son los Story Points?