¿Cómo crear un Sprint Goal?

Si has trabajado con Scrum es muy probable que, en más de una ocasión, hayas tenido problemas para definir un Sprint Goal.

Quizás te hayas preguntado si el elemento más alto en el Product Backlog es teóricamente el más valioso, ¿debe ser la base para definir el Sprint Goal? o ¿qué hacemos cuando tenemos varios ítems en la parte alta pero no tienen correlación? ¿Formamos un Sprint Goal con “A”, “B” y “C”? ¿Puedo tener más de un Goal por Sprint?

En el anterior post El Poder del Sprint Goal, vimos la importancia de trabajar con Sprint Goals en Scrum. En este post veremos cuándo se crean las principales técnicas que podemos usar para definirlos y distinguiremos algunas tipologías de Sprint Goals.

¿Cuándo se crea?

Mi recomendación es que, durante el sprint en curso, el Product Owner hable con los stakeholders y pre-acuerde un Sprint Goal flexible, llevando a esta reunión inputs del Development Team si fuera necesario. Con tiempo suficiente, el Product Owner, junto al equipo, puede refinar los ítems del Product Backlog que permitirían alcanzar ese objetivo.

Los plazos dependen del nivel de incertidumbre del Producto. En un entorno muy cambiante, si la pre-definición y el refinamiento ocurren muy pronto, se corre el riesgo de tirar el trabajo a la basura, por lo que habría que dejarlo para la última semana del sprint, o incluso los últimos días.

Por el contrario, en un entorno con baja incertidumbre, podrían definirse y refinarse sin plazos tan estrictos. Pero siempre hay que tener cuidado con las fechas, especialmente con roadmaps a varios meses vista, pues las expectativas de los stakeholders podrían chocar con la realidad.

Sin embargo, no es hasta el Sprint Planning cuando el Product Owner y el Development Team “formalizan” el Sprint Goal y el alcance del mismo. Ese es el momento en el que “nace” el Sprint Goal, tras una conversación basada en la confianza y la transparencia.

Como Scrum Master, he vivido situaciones donde el Sprint Goal ha cambiado durante el Sprint Planning por una llamada telefónica de un stakeholder clave.

Evidentemente, estas situaciones extremas deben evitarse pero, si ocurren, el equipo debe estar preparado para analizar la viabilidad y, en su caso, crear un plan que permita alcanzar el objetivo, negociando el alcance del mismo y alineando las expectativas de los stakeholders y el sponsor.

Más tarde corresponderá al Product Owner y al Scrum Master transmitir a los stakeholders el impacto que tiene sobre el Scrum Team los cambios de timón bruscos y de última hora.

Técnicas para definir el Sprint Goal

Top-Down

En esta técnica, el Product Owner plantea el estado futuro deseado del Producto y el Development Team revisa los ítems del Product Backlog que permitirán alcanzarlo. Personalmente, es la técnica que más me gusta, pues permite alinear por adelantado las expectativas de los stakeholders con el desarrollo que acometerá el equipo.

Con este modelo, es importante que el Product Owner vaya introduciendo al equipo cuál será el siguiente Sprint Goal, de manera que el equipo tenga tiempo de refinar los ítems que permitirán alcanzar el objetivo, e incluso ir matizando el alcance del mismo.

Dicho esto, hay que tener cuidado de no abusar de esta técnica**.** El Product Owner debe dejar espacio para que el Development Team pueda proponer también Sprint Goals. Por ejemplo, el Development Team puede identificar en el Product Backlog un grupo de ítems de alto valor y bajo coste de desarrollo, por lo que podría ser interesante acometerlos en el siguiente sprint. Otro ejemplo sería la proposición de un Sprint Goal relacionado con la mitigación o eliminación de algún riesgo para el Producto.

Es decir, aunque se utilice la técnica Top Down, hay que entender que es bidireccional. No solo los stakeholders pueden influir al Product Owner, sino que el propio equipo también tiene plena capacidad para plantear objetivos.

Bottom-Up

Con esta técnica es el Development Team quien, a partir de la revisión de los elementos del Product Backlog, decide cómo agruparlos y re-ordenarlos para construir un Sprint Goal, en cooperación con el Product Owner.

En este caso, el Product Owner no llega con un Sprint Goal deseado al Sprint Planning, sino con un Product Backlog priorizado, y es el Development Team quien lo analiza para buscar una agrupación lógica de los elementos que permita maximizar el valor a la vez que determina un trabajo cohesionado.

Esta técnica, además de perfectamente válida, es muy útil cuando se llega al Sprint Planning sin un objetivo claro. Pero precisamente por ello, hay que tener cuidado con las expectativas de los stakeholders, pues si aparecen problemas durante el sprint y el alcance del trabajo realizado no coincide con lo esperado por los stakeholders, pueden surgir conflictos.

Forced-fit approach (lo que no debemos hacer)

He de reconocer que cuando comencé a usar el Sprint Goal como herramienta cometí muchos errores. Uno de ellos consistía en el siguiente razonamiento: si el Product Owner ha priorizado los ítems A, B y C en la cima del Product Backlog porque son, con diferencia, los que aportan más valor, entonces, aunque no tengan correlación, deben formar parte del Sprint Goal.

Este razonamiento da lugar a Sprint Goals muy forzados donde ni siquiera está clara la prioridad, porque varias cosas son muy importantes. Un Sprint Goal debe ser inspirador, motivador, debe crear un propósito para el equipo. Sin embargo, una amalgama incoherente difícilmente puede tener esas características.

Además, recordemos que una de las utilidades de un Sprint Goal es que evita que miembros del equipo trabajen en iniciativas separadas. Si el Sprint Goal, y los ítems que permiten alcanzarlo, no son un todo cohesionado difícilmente estaremos cumpliendo con el propósito de esta herramienta.

Tipos de Sprint Goal

Definición plana y directa

Consiste en formular un objetivo y expresarlo a través de N elementos del Sprint Backlog.

Por ejemplo: “Personalizar las Tarifas que ofrecemos al Usuario”, que se expresa a través de los ítems X, Y y Z. En este caso, el Sprint Goal está relacionado con una nueva funcionalidad y su alcance viene definido por dichos ítems del Sprint Backlog.

Si es necesario, el Product Owner y el Development Team pueden acordar una fecha de puesta en Producción e incluirla como parte del objetivo: “Personalizar las Tarifas que ofrecemos al Usuario desde el 1 de Junio”.

De este modo, si los ítems X, Y y Z cumplen el Definition of Done y el Incremento es puesto en Producción, previa confirmación del Product Owner, en dicha fecha, el equipo habrá alcanzado el objetivo.

Plantilla

Sobre el modelo anterior, es posible ir un paso más allá y utilizar plantillas para crear Sprint Goals Awesómicos y explotar así todo su potencial.

Una de las plantillas más populares fue creada por Roman Pichler, experto en Product Management. Podéis encontrarla en el artículo de su blog “A Template for Formulating Great Sprint Goals”.

Roman distingue, además de la definición del propio objetivo, dos características adicionales:

• El Método: que responde a la pregunta sobre cómo se cumplirá el objetivo. Puede ser mediante un incremento desplegable o un prototipo en formato digital, o un test de usabilidad, o una solución spike, etc.
• La Métrica: que responde a la pregunta sobre cómo se determinará si el objetivo se ha alcanzado. Siguiendo con el ejemplo anterior, una métrica podría ser: “Tres usuarios elegidos aleatoriamente ven precios de productos personalizados cuyo valor coincide con el de aplicar nuestra fórmula de cálculo de precios manualmente y pueden, además, completar una compra con dichos precios.”

Metáforas

Por último, pueden usarse metáforas como Sprint Goals para imprimir energía en el equipo y servir de inspiración y, por qué no, haciendo uso de un poco de humor.

Aquí el único límite es la imaginación. Por ejemplo, si el equipo va a trabajar en un rediseño gráfico de la web, el Sprint Goal podría basarse en el título de la película “¡Este cuerpo no es mío!”.

Otro ejemplo: si el equipo va a mejorar la difusión de contenidos en redes sociales, el Sprint Goal podría ser el famoso slogan publicitario de Movistar: “Compartida, la vida es más”.

Si buscas inspiración, las metáforas pueden basarse en:

• Títulos de películas.
• Slogans publicitarios.
• Títulos de canciones.
• Colores.
• Equipos deportivos.
• Modelos de coches.
• Animales.
• Etc.

Conclusiones

La creación de Sprint Goals tiene parte de ciencia y parte de arte. Puedes usar las técnicas Top-Down o Bottom-Up para definir Sprint Goals, pero evita construir objetivos que sean una amalgama de cosas incorreladas.

El Sprint Goal nace durante el Sprint Planning, mediante mutuo acuerdo entre el Product Owner y el Development Team. En ocasiones, es recomendable llevar una idea del Sprint Goal antes del evento, especialmente para mantener alineadas las expectativas de los stakeholders.

Puedes usar plantillas para liberar toda la potencia del Sprint Goal, especialmente para clarificar cómo se cumplirá/alcanzará el objetivo y qué métricas se utilizarán para evaluarlo.

Si buscas algo de diversión, utiliza metáforas para encontrar un Sprint Goal con gancho y que represente el objetivo por el que el equipo va a pelear durante el sprint.