“¿Es un Fortissio Lungo? Porque huele de maravilla”, me preguntó Gonzalo, Product Owner del Equipo Telcom, justo antes de comenzar el Sprint Review #4. Yo me había incorporado un par de días antes al equipo como Scrum Master y, en medio de la calma y el olor a café, no pude prever la tormenta que se avecinaba.

Habían transcurrido menos de 20 minutos cuando Alonso de Benavides, principal stakeholder y sponsor del proyecto, lanzó la pregunta que retumbó como un trueno en la sala: “Entonces, ¿se puede saber qué demonios habéis hecho en este Sprint?”.

A lo que Gonzalo respondió con voz trémula, no sin antes tragar saliva: “El equipo ha terminado los jiras TL-34 y TL-35, relativos al área de usuario, y también del TL-40 al TL-44, que han mejorado el tiempo de carga de las páginas del catálogo de productos”.

La cara de Alonso se volvía azul por momentos. En la sala todos le miraban, mientras contenían la respiración, sin llegar a entender por qué reaccionaba de esa manera.

Alonso, sometido a una gran presión desde hacía meses, se puso en pie, como si quisiera reforzar su mensaje, y añadió: “Os dije que era vital para la compañía poder vender el nuevo producto de TV-Streaming al final de este Sprint, ya que nuestra competencia nos está machacando desde que lo sacó al mercado hace dos meses”**.

Gonzalo, que recordó vagamente haberlo mencionado al equipo durante el Sprint Planning, contestó, casi con la voz rota: “Me temo que al equipo no le dio tiempo de terminar los jiras para esa funcionalidad, se atascaron y decidieron continuar con otras cosas para completar más ítems del Backlog y no bajar la velocidad”.

Tras escuchar su respuesta, Alonso mostró una leve sonrisa, de esas en las que la boca hace una mueca rígida y el resto de la cara permanece inmóvil.

Después de unos segundos de silencio sepulcral, aseveró: “Me temo que no habéis entendido nada y es muy decepcionante. No habéis comprendido las prioridades del negocio, lo que aporta valor y nos hace sostener esta compañía. No sabéis distinguir lo importante de lo accesorio. Es una situación muy preocupante que espero resolváis en el próximo Sprint o tendré que tomar medidas”, al tiempo que abandonó la sala.

No pude evitar pensar que nada de esto habría ocurrido si el equipo Scrum hubiera aprendido el poder del Sprint Goal. La buena noticia, pensé por sacar algo positivo de la situación, es que teníamos una oportunidad para Inspeccionar-nos y Adaptar-nos en la próxima Retrospectiva. ¡A por ello!

¿Qué es un Sprint Goal?

El Sprint Goal es el objetivo más importante que tiene que cumplir el equipo Scrum durante el sprint. Debe ser alcanzable mediante la realización de un conjunto “coherente” de ítems del Product Backlog.

Este conjunto puede representar, bien una funcionalidad, bien cualquier otra cosa que sirva para que el equipo trabaje en una causa común, en lugar de en iniciativas separadas.

El Sprint Goal sirve de guía al Development Team para saber por qué están construyendo “este” Incremento. Si durante el sprint se descubre que el trabajo a realizar es diferente, el Development Team y el Product Owner pueden renegociar el alcance del Sprint Backlog durante el sprint.

Por otro lado, el Sprint Goal también sirve para que los stakeholders, el Product Owner y el Development Team estén alineados respecto a qué es lo más importante, lo más prioritario. Es decir, guía el trabajo del equipo y determina, en gran medida, las expectativas de los stakeholders.

Generalmente, los stakeholders y/o el sponsor estarán satisfechos si el equipo alcanza el Sprint Goal. No olvidemos que el Sprint Backlog es una predicción del trabajo que realizará el equipo, mientras que el Sprint Goal es un compromiso.

El Product Owner es responsable de gestionar, por un lado, las expectativas de los stakeholders y, por otro, la definición del trabajo a realizar, mediante la colaboración con el Development Team.

Además, es una herramienta que honra los valores de Scrum:

• Foco: el Sprint Goal sirve de faro que guía al equipo a desarrollar la prioridad número uno.
• Compromiso: el equipo se responsabiliza para cumplir su misión, el Sprint Goal.
• Coraje: hay que ser valiente para cumplir el objetivo, resolver los impedimentos que surgen durante el camino, vencer los “ladrones del tiempo”, reconducir a un compañero que, sin darse cuenta, se desvía de la meta.
• Franqueza: el seguimiento del Sprint Goal durante la Daily obliga a la transparencia sobre su grado de consecución, en los impedimentos que puedan aparecer y que hay que hacer visibles, en la re-planificación de las tareas que puedan emerger.
• Respeto: el equipo Scrum respecta a los stakeholders y al sponsor asumiendo el Sprint Goal como el objetivo fundamental, aquel con el que se comprometen.

¿Quieres saber cuáles son los 10 poderes del Sprint Goal?

• Sirve de guía al Development Team y le ayuda a poner foco en aquello que es más importante en el sprint.
• Si las cosas se ponen difíciles, facilita la toma de decisiones basada en prioridades.
• Proporciona un propósito, da sentido y motiva al Development Team.
• Promueve la cohesión de los ítems del Product Backlog hacia un objetivo común.
• Es polimórfico: puede servir para entregar funcionalidades, probar ideas, reducir riesgos, etc.
• Permite al Product Owner gestionar las expectativas de los stakeholders y alinearlas con el trabajo que realiza el Development Team.
• Flexibiliza el trabajo del Development Team en dos sentidos: su alcance es negociable y, normalmente, representa sólo una parte del trabajo del Sprint Backlog.
• Con precaución, sirve al Product Owner para crear Roadmaps.
• Sirve para reducir el riesgo del Producto; cada sprint puede considerarse como un mini-proyecto con un objetivo definido.
• En el Sprint Planning, sirve para poner foco en el objetivo común y en la Daily Scrum**,** permite guiar el evento.

¿Cómo se relaciona el Sprint Goal con la entrega de valor?

Aunque pueda parecer una pregunta inocente, en realidad, no lo es. En Paradigma repetimos, casi como un mantra, que el Product Owner es un maximizador del Valor entregado.

Por tanto, si el Sprint Goal es lo más importante que tiene que hacer el equipo durante el sprint, ¿podemos inferir que el Sprint Goal debe representar lo más valioso que puede realizar el equipo? Para mí la respuesta es “no necesariamente”.

Por una razón fundamental:

Según la guía Scrum, “...the Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives”.

Es decir, el Sprint Goal puede ser cualquier cosa que proporcione coherencia al trabajo que realiza el Development Team. Un Sprint Goal puede estar relacionado con el tratamiento de un riesgo de alta probabilidad de ocurrencia y elevado impacto.

Quizás, durante el Sprint Planning, en la parte alta del Product Backlog existía una funcionalidad que aportaría gran valor, pero el Product Owner y el Development Team pueden acordar que tratar el riesgo es más importante que entregar dicha funcionalidad.

Llegados a este punto, francamente, la imaginación es el límite. Hay autores que afirman que un Sprint Goal incluso puede ser el nombre de un grupo de música, de un videojuego... con tal de que represente un objetivo común para el trabajo del equipo.

Personalmente, prefiero Sprint Goals más concretos, directamente relacionados con la entrega de valor, pero ambas aproximaciones serían válidas de acuerdo al framework.

Cuando el Sprint Goal se convierte en obsoleto

Por último, es importante destacar que el Sprint Goal también sirve como criterio para cancelar el sprint en curso. Si el Sprint Goal deja de tener sentido, se convierte en obsoleto, bien por cambios en el mercado, en la tecnología, etc., el Product Owner puede decidir cancelar el Sprint y comenzar uno nuevo. Sin embargo, dada la brevedad de los sprints, rara vez sucede.

Conclusiones

Nuestro amigo Gonzalo, Product Owner en la historia que conté al comienzo, podría haberse ahorrado el bochorno durante el Sprint Review si hubiese conocido el poder de un Sprint Goal. Sin un objetivo claro, es muy fácil perder el foco y no cumplir las expectativas de los stakeholders y el sponsor.

Los Sprint Goals sirven de guía al Development Team, promueven el foco del equipo, facilitan la toma de decisiones basada en prioridades, permiten alinear las expectativas de los stakeholders con el trabajo del equipo Scrum y son tan flexibles que pueden usarse para entregar funcionalidades, tratar riesgos, realizar pruebas, etc.

En el próximo post “Cómo crear un Sprint Goal” daré ideas para definir y modelar Sprint Goals en la práctica.

Stay tuned!