¿Cuál es el impacto de no finalizar un Sprint?

Modelo, Método y Gestión: ¿Cuál es el impacto de no finalizar un Sprint?

¿Se debe preocupar el Equipo de Desarrollo por no haber finalizado su compromiso?. ¿Se debe encolerizar el Product Owner por no tener el nuevo incremento pactado?. ¿Cómo debe actuar el Scrum Master?. ¿Qué está haciendo mal?

En primer lugar y para que quede bien claro, si no se ha cumplido el compromiso del Sprint, es el Equipo Scrum, al completo, quien se ha quedado corto, y todos deben hacer retrospectiva para tratar de mejorar. Veremos después unas ideas.

Y digo todos porque el propietario, el equipo de desarrollo y el ScrumMaster son un equipo a la vista de la organización y a la de todos y cada de uno de los interesados (stakeholders).
Romper esta regla es introducir tensión y desunión en el equipo Scrum. En un equipo Scrum empujan ‘todos a una’.

Analicemos el escenario planteado. Nunca he vivido un Sprint en el que no se haya finalizado ninguna de las historias de usuario comprometidas. Lo normal, ante un Sprint inconcluso, es que hayamos finalizado con éxito la mayoría de las historias y hayamos incumplido únicamente parte del compromiso. De aquí la necesidad de la correcta definición de las historias de usuario: pequeñas, independientes, que representen por sí mismas una unidad de valor para el producto, que no sobrepasen los 13/20 puntos de historia, dependiendo del número de miembs del equipo, etc.

Por favor, no pongamos el grito en el cielo antes de tiempo, la gravedad del incumplimiento del compromiso del Sprint está marcada por el valor de negocio de la historia no finalizada y la prioridad de su puesta en marcha. En el peor de los casos estaremos frente a una historia de alto valor y máxima prioridad. El propio proceso Scrum se protege de estas situaciones haciendo uso de la entrega continua. Si tenemos Sprints de una semana o dos, es bastante improbable que retrasar una o dos semanas una historia de usuario suponga un retraso significativo en la estrategia de negocio del producto.

Si la historia no finalizada no es significativa, no haberla entregado no es una situación de alarma, simplemente se entregará en el siguiente sprint en una o dos semanas.

Si por el contrario, la historia no finalizada es crucial para el negocio y se requiere su implantación inmediata, estoy seguro que en un día, o a lo sumo dos, podremos finalizarla y entregarla. ¿Esto es grave?. Grave es que después de 10 meses de desarrollo tengamos que esperar otro mes para entregar, que tengamos que hacer correcciones que impacten en el negocio y por consiguiente en el tiempo de desarrollo, y peor aún que el negocio se vea condicionado por las cuestiones técnicas. Pero esperar un día que nos permita finalizar una historia y generar una nueva versión… eso no es grave, es parte de la potencia de Scrum.

No obstante, si como os he dicho, en alguna ocasión se me ha dado el caso deno finalizar un Sprint, jamás he tenido un caso en el que la historia inconclusa no haya podido esperar al siguiente Sprint. Como Propietario siempre he podido espetar una semana o dos, no estamos hablando de un mes o dos, un trimestre o dos…

Y qué hacemos con la reunión de revisión del incremento, ¿hay demo?. La demo no se cancela, el Product Owner presenta aquellas historias de usuario que han sido finalizadas, mostrando así la evolución en el trabajo del equipo. Si los asistentes (stakeholders) requieren información sobre la historia no entregada, el Product Owner puede explicar en detalle la situación sin buscar nunca causantes, sólo causas, alternativas, problemas encontrados, soluciones propuestas, previsión de finalización, impacto en el producto, etc. En definitiva, cuestiones de interés público. En privado, durante la retrospectiva, se analizarán los temas organizativos internos, se analizarán las causas y se aprenderán todas lecciones posibles del período finalizado, o mejor dicho, no finalizado.

El Product Owner debe revisar el impacto en la planificación de las siguientesiteraciones, reorganizando el backlog de forma que se ajuste a las nuevas prioridades.
image
Gracias por vuestra atención, no os olvidéis twitter la entrada si habéis encontrado algo interesante en ella y dejad comentarios para que todos crezcamos en conocimiento.

Hasta pronto.

Óscar R. Onrubia
@OscaRonrubia

Anuncios
Esta entrada fue publicada en Metodologías Ágiles, Scrum y etiquetada , , , , . Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s