El Sprint Goal es uno de esos elementos al que muchos equipos no prestan especial atención. Estuve trabajando con equipos Scrum durante dos años sin nisiquiera saber que existía ese concepto.
El Sprint Goal está muy alineado con uno de los valores de Scrum, “el foco”. Precisamente, venimos de trabajar, de manera disparatada, en equipos que han acabado como pollos sin cabeza cambiando continuamente de tarea. El “foco” es un valor que nos ayuda a entender que estamos centrados en sacar adelante el trabajo que, ahora mismo, es lo más importante. El Sprint Goal es una herramienta que nos ayuda a ganar foco.
Recordemos que el concepto Sprint Goal aparece veintisiete veces en la Scrum Guide. Desde hace tiempo se ha convertido en una pieza clave de Scrum.
¿Para qué sirve el Sprint Goal?
El Sprint Goal responde a una pregunta básica en Scrum ¿Para qué hacemos este Sprint? Si no somos capaces de responder esa pregunta es que realmente quizás no debamos hacer este Sprint. El Sprint Goal nos proporciona un filtro para evitar que cualquier “unplanned” entre en el Sprint, como bien indicaba Esther, no es apropiado porque matamos a los gatitos, digo el foco.
Realmente, los cambios durante el Sprint se pueden aceptar si están alineados con el Sprint Goal, sobre todo si ayudan a conseguirlo. Todo lo demás debe estar fuera.
¿Qué consecuencias tiene el no disponer de un Sprint Goal?
Si no disponemos de un Sprint Goal o tenemos más de uno, nos costará más trabajar en equipo, porque no tendremos una meta común. Un equipo es aquel que trabaja de manera compartida luchando unos con otros por alcanzar ese objetivo. El Sprint Goal, nos ayudará si aparecen duda sobre si debemos o no abordar una funcionalidad no planificada ¿Por qué la nueva funcionalidad es más importante que la planificamos?
Otro importante motivo es que, con un Sprint Goal compartido, favorece el debate en torno a cómo nos organizaremos. Sin Sprint Goal, puede ocurrir que cada uno se dedique a sus tareas y cueste más que haya colaboración.
Y por último, el Sprint Goal puede ayudar a responder a la pregunta: ¿Para qué hacemos Sprints? Para muchos equipos sirve de titular principal que explica lo que aportará a nuestro producto este Sprint.
¿Que nos aporta tener un Sprint Goal?
Otro valor que fomenta es el “coraje”. El coraje sobre los retos que tenemos que abordar, puede aparecer si disponemos del Sprint Goal.
Además, aparece otro valor como es el “compromiso”. El “compromiso” no es solo con cumplir el Sprint Goal, el “compromiso” de los miembros del Development Team para luchar juntos para tratar de alcanzar los retos que se marque el equipo (y el Sprint Goal puede ser uno de esos retos). Es decir, queremos colaborar, para lo que cada miembro debe priorizar el trabajo del grupo sobre el individual.
¿Quién crea el Sprint Goal?
El Sprint Goal es el resultado de una Sprint Planning, decimos esto porque no viene impuesto por el Product Owner sino que emerge durante el evento. Es un acuerdo entre el Development Team y el Product Owner. El Scrum Master podrá ayudar a dicha definición.
Si tenemos varios Sprint Goal, podemos perder parte de los beneficios que hemos mencionado.
Evita que el Sprint Goal sea un listado de deseos “queremos esto… y esto… y esto…” o que el Sprint Goal sea un PBI concreto y que esté ubicado en mitad del Product Backlog. ¿Si este es el objetivo, no debería ser lo primero que hiciéramos?
Hay equipos que primero generan el Sprint Goal y después seleccionan los elementos del Product Backlog que nos ayudarían a alcanzarlo. Otros deciden hacerlo en sentido inverso, es decir, primero seleccionan los PBIs y, tras eso, buscan el Sprint Goal que abarca todo lo que quieren hacer.
Por tanto… Sprint Goal ¿Huevo o gallina?
No hay una respuesta clara, en la guía Scrum se habla de que el Product Owner puede traer una idea de lo que le gustaría, después se habla de los PBIs en donde se lanzan preguntas y finalmente se fija el Sprint Goal.
Ambas estrategias de definición son válidas y, como decía mi compañera María, dependerá de en qué punto se encuentre el equipo. A veces, tendrá el objetivo muy claro y se debatirá sobre los PBIs y, otras veces, tendrán los PBIs más claros y habrá que definir un goal.
En mi experiencia, que los equipos que definen el Sprint Goal después de los PBIs parece que lo hacen por cumplir un trámite, por hacer algo que dice la guía pero sin creer en ello. Aún así, no hay una prescripción y, como me comentaba Jerónimo Palacios, “que cada equipo decida cómo quiere jugar”.
¿Cómo es el Sprint Goal en tus equipos?
Nosotros trabajamos seleccionando primero los PBIs del backlog y luego definiendo el Sprint Goal sin embargo a veces resulta difícil abarcar los PBIs escogidos dentro de una frase que refleje a todos. Ahí tendría dudas, ¿Siempre hay que intentar que una frase defina nuestro sprint goal incluso aunque en un sprint ataquemos funcionalidadaes que no teinen nada que ver o podemos hacer que ese Sprint Goal refleje varias cosas aunque no tengan el mismo objetivo?
Buenas Manuel. Creo que esa es la duda. Normalmente el Goal debe ser algo que tiene prioridad máxima y que debemos acometer ahora en nuestro producto. Si hacemos otras cosas no pasa nada, pero con foto en el Goal y que, por culpa de abordar otras cosas, no nos quedemos fuera. A partir de ahí, cuidado si el concepto «hacer más cosas» supone que estamos tratando de llegar a una fecha con una cosa concreta y no centrarnos en entregar valor constantemente. Pero eso da para un debate más profundo :). Gracias!
Me ha pasado que el PO traiga el Sprint Goal y al final se priorizarón los PBis para que encajen en el Goal, y tambien tener los PBis y luego definir el Goal.
Pero creo que la primera termina siendo más efectiva.
Es recomendable que el PO traiga el Goal o que el equipo la defina inicialmente junto con el PO?
Buenas!si siempre lo trae y lo impone entonces es mejor hacerlo conjunto. Ahora bien, traer una propuesta y que se debata suele funcionar