En ocasiones en nuestro día a día nos encontramos con auténticas discusiones sobre cómo establecer el Sprint Goal y lo más importante, qué establecer como Sprint Goal. Es por ello que en este artículo intentaré arrojar algo de luz sobre algo tan importante para el equipo Scrum.
Qué dice la guía Scrum sobre el Sprint Goal
Siempre que tengo que abordar alguna cuestión sobre el framework el primer sitio donde me gusta mirar es en la guía Scrum, y citando lo que indica la misma de manera literal, la definición del Sprint Goal es la siguiente, y cito textualmente:
El Sprint Goal es una meta establecida para el Sprint que puede lograrse mediante la implementación del Product Backlog. Proporciona una guía al Development Team acerca de por qué está construyendo el incremento. Se crea durante el Sprint Planning. El Sprint Goal proporciona al Development Team cierta flexibilidad con respecto de la funcionalidad implementada en el Sprint. Los elementos del Product Backlog seleccionados ofrecen una funcionalidad coherente, que puede ser el Sprint Goal. El Sprint Goal puede representar otro nexo de unión que haga que el Development Team trabaje en conjunto y no en iniciativas separadas.
A medida que el Development Team trabaja mantiene el Sprint Goal en mente. Con el fin de alcanzar el Sprint Goal se implementa la funcionalidad y la tecnología. Si el trabajo resulta ser diferente de lo que el Development Team espera, ellos colaboran con el Product Owner para negociar el alcance del Sprint Backlog.
Creo que en esta definición hay un matiz, que seguro que no ha pasado desapercibido y que tiene una fuerza importantísima, es el de: «A medida que el Development Team trabaja mantiene el Sprint Goal en mente.» Está hablando del foco, de que el equipo pueda estar enfocado en un objetivo que además lo cohesione.
La cuestión, y uno de los motivos principales por el que escribo este artículo, es porque en muchas ocasiones se da la discusión dentro del Scrum Team de qué establecer como Sprint Goal. Vamos a ver un ejemplo práctico sobre esto:
El caso de la aseguradora
Imaginemos que trabajamos desarrollando una app para una gran compañía aseguradora, dicha compañía ofrece a sus clientes 3 productos claramente diferenciados:
- Hogar (cotizador, contratación, partes, consulta de pólizas, recibos…)
- Salud (cotizador, contratación, coberturas, consulta de pólizas, recibos…)
- Vida (cotizador, contratación, consulta de pólizas, recibos…)
A continuación tenemos un planteamiento de necesidades de cada uno de esos productos, que viene dado por los stakeholders de cada una de esas áreas, y conjuntamente con nuestro PO elaboramos un Roadmap.
Contexto
Contamos con un equipo Scrum encargado de transformar todo ese Roadmap en producto, no vamos a añadir condicionantes a dicho equipo, sobra decir que somos un equipo Scrum con todas las skills necesarias para poder llevar a cabo dicha labor, y además tenemos la velocidad del equipo ya que llevan tiempo trabajando juntos.
Llevamos tiempo desarrollando producto para dicha empresa por lo que no acabamos de arrancar, sino que tenemos una cadencia y que arrancamos este «nuevo» como la continuación de uno anterior.
Trabajando nuestro Roadmap
La cuestión es que en el planteamiento del Roadmap, algunos de los productos «solapan» sus funcionalidades, como podéis ver en la simulación que hay en la cabecera de este párrafo.
Como podéis ver existen funcionalidades del «cotizador de hogar» que se llevarán acabo conjuntamente con el «cotizador de vida» ¿Qué Sprint Goal fijamos aquí?
Pues bien, teniendo en cuenta el Roadmap muchas/os dirían que el Sprint Goal debiera ser algo del tipo:
Posibilitar las cotizaciones del seguro de hogar y comenzar con el cotizador de vida.
Las dudas sobre nuestro Sprint Goal
Los más rebuscados dirían que es un objetivo único (está en una frase), pero no cuela, esa conjunción «y» está introduciendo un segundo Sprint Goal. Pero… ¿Entonces? ¿No trabajamos en el «cotizador de vida» y fijamos el Sprint Goal en el «cotizador de hogar»? ¿Fijamos el Sprint Goal en el «cotizador de vida» porque esta funcionalidad es más grande? ¿Le preguntamos al PO que es más prioritario?
Resolviendo el dilema
Nadie dijo que esto fuera fácil y definir el Sprint Goal en la Planning no es tarea sencilla en ocasiones pero teniendo en cuenta el caso del ejemplo, la solución al Sprint Goal sería establecer algo que permita al equipo poner foco en un único objetivo, nada de ambigüedades, múltiples objetivos o cosas abiertas, estaríamos introduciendo un anti-patrón.
En este caso tenemos una funcionalidad que finaliza y otra que se inicia, establecer un Sprint Goal concreto no implica que no podamos añadir ítems de otra funcionalidad.
Por ello la propuesta del Sprint Goal sería:
Posibilitar las cotizaciones del seguro de hogar.
De esta manera el equipo tiene una orientación clara del incremento que se pretende producir al final del Sprint, y además podrá añadir ítems en su previsión de alcance que sean referentes a la otra funcionalidad.
¿Para que nos sirve esto? Para que el equipo tenga el foco y en el caso de que exista algún «problema» tenga claro en que debe centrarse. Si el Sprint Goal queda obsoleto entonces será el Product Owner el que decida cancelarlo.
Todos sabemos que lo ideal para este caso sería plantear equipos orientados a producto pero… en ocasiones no jugamos en el escenario perfecto y tenemos que buscarlo.
¿Tu que opinas?
Algunos artículos relacionados
A continuación os dejo algunos artículos que he leído mientras me planteaba la escritura de este post:
- Creating Effective Sprint Goals de Roman Pichler.
- 7 Sprint Goal Patterns for Building Great Team Part 1 de Vyacheslav Moskalenko
- 7 Sprint Goal Patterns for Building Great Team Part 2 de Vyacheslav Moskalenko
- Sprint Goals in Practice de Ian Mitchell
2 comments On La importancia del Sprint Goal.
Excelente!!
Muchas gracias!!!