El Sprint Goal u Objetivo del Sprint es una única meta establecida para el Sprint que puede lograrse mediante la implementación del Sprint Backlog, y que justifica por qué el Sprint debe llevarse a cabo y aportará valor a los stakeholders. Es algo así como un «elevator pitch» para estos.
Muchas veces los equipos Scrum no fijan un Sprint Goal, simplemente porque desconocen de su existencia dentro del framework. Tras la actualización de la Guía Scrum en 2020, el Sprint Goal se configura como un compromiso para los desarrolladores, vinculado al artefacto Sprint Backlog.
Sobre el Sprint Goal u Objetivo del Sprint podemos hacer una serie de consideraciones:
– Otorga flexibilidad para negociar el trabajo durante el Sprint, a vistas de alcanzar el Objetivo del Sprint. En Scrum, el alcance del Sprint es negociable: a medida que los desarrolladores trabajan, desarrolladores y Product Owner pueden acordar alterar los elementos del Product Backlog a terminar, siempre que ello no afecte al Sprint Goal. Esto es, dicha negociación ha de tener como finalidad la consecución del Sprint Goal.
– Proporciona guía al Equipo Scrum sobre por qué está construyendo el Incremento de producto, y favorece el foco y la coherencia, de modo que el Equipo Scrum trabaje conjuntamente y no en iniciativas separadas.
– Se crea durante la Sprint Planning mediante la colaboración de todo el Equipo Scrum y se añade al Sprint Backlog. Normalmente, es el Product Owner quien propone un objetivo de negocio a conseguir, que sirve como base, así como los elementos más importantes del Product Backlog.
– El Objetivo del Sprint puede proceder de los elementos que se seleccionen del Backlog, que formen una función coherente, o de cualquier otra meta o métrica que haga que el equipo trabaje como un todo y no individualmente.
– Debe ser el principal foco para los desarrolladores durante la Daily Scrum, en la que se evalúa el progreso hacia la consecución del Sprint Goal y posibles impedimentos.
– Una buena práctica es asegurar que el Sprint Goal sea visible; por ejemplo, escribiéndolo en una pizarra o tablero Scrum.
– Desde el punto de vista de la estrategia de producto, una sucesión de Sprint Goals debe llevarnos a la consecución del Product Goal.
Algunos ejemplos válidos de Sprint Goal pueden ser los siguientes:
– Ejemplo 1 (validación de hipótesis): “Simplificar el proceso de registro para aumentar la conversión de registro a usuario activo”.
– Ejemplo 2 (funcionalidad de valor para el cliente o usuario): “Implementar la funcionalidad de registro de usuario”.
– Ejemplo 3 (reducción de riesgo): “Testear si el motor de búsqueda podría implementarse con Apache Lucene u otra tecnología alternativa”.
Algunos ejemplos de «malos» Sprint Goals (si es que pueden llamarse así):
❌ “Mejorar el rendimiento de la aplicación” (demasiado genérico, puede ser cualquier cosa).
❌ “Terminar todos los tickets seleccionados para el Sprint” (esto no es un objetivo).
❌ “Hacer los tickets de JIRA A, B y C” (lo mismo que el anterior).
En general, los Objetivos del Sprint «compuestos», en los que mencionamos que queremos lograr varias cosas, no son una buena idea: escojamos una única cosa, la más importante, con la que debamos compremeternos. Tengamos el coraje de comprometernos con una sola cosa, sin miedo. Hay que escoger. ¿Qué es lo más importante que debemos conseguir, sí o sí, durante el Sprint? Pues ese es el Sprint Goal.
Como indicábamos antes, el alcance del Sprint es negociable. No nos comprometemos con los elementos del Product Backlog que seleccionamos para el Sprint. Esa selección es solo una proyección de lo que los desarrolladores piensan que pueden entregar, no un contrato. El compromiso en Scrum es para con el Objetivo del Sprint.
Veámos un un ejemplo muy sencillo:
– Supongamos que arrancamos el Sprint 1, y que el Objetivo del Sprint es obtener la funcionalidad de registro de usuario. En ese primer Sprint sabemos que tendremos bastante trabajo relacionado con la arquitectura de la aplicación, pero, como mínimo, queremos permitir que un usuario se pueda registrar, y así tener un Incremento de Producto.
– Supongamos, además, que tenemos los siguientes PBIs (Product Backlog Items): a) registro mediante email, b) registro mediante Facebook, c) recuperar contraseña, y luego varios PBIs relativos a la arquitectura de la aplicación.
– Durante el Sprint el Equipo se ve agobiado y desarrolladores y Product Owner acuerdan dejar fuera b) y c), para así asegurar que a) y la arquitectura mínima sí que se terminan. Con a), el registro mediante email, habremos conseguido el Objetivo del Sprint.
¿Y qué hacemos con los PBIs que no se pudieron entregar? No pasa nada, vuelven al Product Backlog y ya decidiéremos qué hacer con ellos. Igual el registro mediante Facebook no era tan importante y terminamos por no implementarlo nunca. A saber.
En resumen: el Equipo Scrum se compromete a dar lo mejor de sí para alcanzar el Objetivo del Sprint, que nos da foco y flexibilidad para autogestionarnos.
👉 Visión de producto:
– Es algo así como el estado final del producto, “la tierra prometida” a la que queremos llegar.
– Horizonte temporal: puede que años.
👉 Product Goal:
– Objetivo a medio/largo plazo para el equipo Scrum; algo que seguramente no podremos conseguir en un único Sprint, sino en varios.
– Aporta coherencia al Product Backlog, y el equipo solo debe enfocarse a un Product Goal en cada momento. (Si bien el Product Backlog podría contener elementos relacionados con otros Product Goals).
– Se crea durante Sprint Planning, por parte de todo el equipo.
– Horizonte temporal: quizás meses; puede que coincida con OKRs o KPIs trimestrales, por ejemplo.
– El sumatorio de Product Goals debe acercarnos a la visión de producto.
👉 Sprint Goal:
– Objetivo único para el Sprint; meta de carácter táctico. Una sucesión de Sprint Goals deben llevarnos al Product Goal.
– Aporta foco y coherencia al Sprint Backlog.
– El Product Owner es el encargado de crear el Product Goal, en colaboración con el negocio y el equipo.
– Horizonte temporal: un Sprint (por tanto, un mes o menos).
– Una sucesión de Sprint Goals debe llevarnos a la consecución del Product Goal.
Como colorario, cabe subrayar que Sprint Goal y Product Goal se influyen mutuamente:
– El Product Goal guía la creación del Sprint Goal, puesto que, como acabamos de indicar, es la sucesión de Sprint Goals lo que nos llevará a conseguir el Product Goal.
– El equipo Scrum no trabaja directamente en el Product Goal, sino en el Sprint Goal. Pero progresar hacia la consecución del Sprint Goal es también progresar para lograr el Product Goal.
– El trabajo en ejecución del Sprint Goal generará nuevos aprendizajes que lleven a ajustar o, incluso, a abandonar el Product Goal.
No es el fin del mundo. Hablemos sobre ello, en la Sprint Review con los stakeholders, en la Sprint Retrospective como Equipo. Con suerte habremos aprendido algo que nos hará mejores en el siguiente Sprint. Esto va de inspeccionar y adaptar, no de buscar culpables.
En nuestra opinión, depende. Algunos de los ejemplos que hemos mencionado antes son mero output, features. Y eso tampoco está necesariamente mal. Hacemos dos precisiones:
Las plantillas no son ninguna panacea, pero pueden servirle a tu equipo para arrancar.
👉 1) Steve Trapps (Scrum. org):
“Nuestro foco está en <resultado a conseguir>
Creemos que aporta <impacto para el cliente>
Esto será confirmado cuando <evento suceda>.”
👉 2) Roman Pichler’s:
– Objetivo: alude al resultado a lograr, a la razón por la que hacemos el Sprint; por ejemplo, mitigar un riesgo, testar una asunción o entregar una funcionalidad.
– Método: se refiere a cómo el objetivo será conseguido, al artefacto o técnica que usaremos (Incremento de producto, prototipo, A/B test, etc.).
– Métricas: cómo determinaremos si el objetivo se ha cumplido.
👉 3) Strategyzer’s test card (que en muchos casos puede inspirarnos para formular el Sprint Goal como un experimento):
“Creemos que <hipótesis>
Para verificarlo, haremos <descripción del test o actividad>
Y mediremos <métricas>
Estaremos en lo cierto si <criterio de validación>.”
No todos los elementos del Sprint Backlog tienen que estar relacionados con el Sprint Goal. Podemos hacer otras cosas, aunque no sean el foco principal.
Sí querremos que la mayoría de elementos estén relacionados con el Sprint Goal, esto es, que su implementación nos lleve a conseguir el Objetivo. Pero, en teoría, aunque no sea lo normal ni lo recomendable, basta con que un solo elemento de los seleccionados esté vinculado con el Sprint Goal.
A continuación, incluimos una pregunta de ejemplo para preparación de certificaciones Scrum, ya sea como Scrum Master o Product Owner.
The Sprint Goal (please choose the two best answers):
a) It is an optional element within Scrum, since it is up to the Scrum Team to decide whether a Sprint Goal is defined or not.
b) It is collaboratively created by the Scrum Team during the Sprint Planning event.
c) It ensures that developers stay focused and that there is no room to change the work of the Sprint.
d) It is part of the Sprint Backlog.
e) It is part of the Definition of Done.
Las respuestas correctas serían b) y d). Puedes ver más preguntas de ejemplo para el exaamen Scrum Master en este post, o utilizar nuestro simulador de tests para certificaciones Scrum. También puedes consultar nuestra guía de preparación de la certificación PSM I. Si estás preparando el examen PSPO I, puedes utilizar este otro test.