¿Qué representan el objetivo y la pila de sprint?

El objetivo o meta del sprint
Cortesía de Pixabay

He vivido varios equipos que no ponen objetivo o meta de sprint (sprint goal) a sus sprints. Cada sprint debe de tener un objetivo y debe de que quedar reflejado en el tablero scrumboard. La conversación alrededor del objetivo focaliza a todos en el valor ya que trata de darle una función coherente a los elementos de la pila de sprint, podemos pensar en el objetivo de sprint como un elevator pitch que habla de los beneficios que va a obtener negocio con lo que se construya en ese sprint. Lo importante es que el equipo se comprometa con el objetivo, no con el paquete de historias de usuario de la pila de sprint. Existen dos términos en inglés que nos dan la pista sobre estos dos conceptos:

• Output: la salida producida
• Outcome: el resultado producido en términos de beneficio o de resolución de problemas para negocio

En la gestión clásica de proyectos ponemos el foco en la construcción de outputs. Lo hacemos en forma de funcionalidades, nos basamos en un input a base de una lista de requisitos que llamamos alcance, y a lo largo del proyecto construimos un paquete grande de funcionalidades que cubra esos requisitos, y lo hacemos de forma optimizada para el paquete completo.

Output vs. Outcome, no hay correlación entre uno y otros
Imagen de las monedas cortesía de Pixabay

En cambio en Agile y Lean el foco está en producir outcomes, en construir soluciones a problemas de negocio para hacer una compañía competitiva y que obtenga beneficios de forma sostenida.

Encontraremos ambos términos en cada uno de los sprints en Scrum, cuando obtenemos la pila de sprint y el objetivo en la planificación de sprint. La pila de sprint es el output y el objetivo el outcome; no importa tanto si las historias de usuario entregadas corresponden a lo que se planificó, lo que importa es que las historias entregadas sean la mejor solución para el negocio. Lo clave es que el objetivo guíe al equipo a lo largo del sprint focalizados en la necesidad o problema a solucionar.

Imaginemos la siguiente pila de sprint:

• Como lector quiero buscar libros por título para encontrar los libros que me gustan
• Como lector quiero buscar libros por autor para ver otros libros de autores que me gustan
• Como lector quiero poder ver los resultados de la búsqueda efectuada para seleccionar el que me interesa
• Como lector quiero una búsqueda avanzada para explorar la librería

cuyo objetivo es:

Permitir la búsqueda de libros a nuestros lectores

Ahora imaginemos que el sprint es a finales de agosto, a las puertas del comienzo de las clases, y a medio sprint nos damos cuenta que lo que necesitan nuestros clientes es otra historia de usuario:

• Como madre quiero buscar libros por ISBN para comparar los libros de texto para mi hijo

Una posible solución sería incluir esa nueva historia dejando fuera la de menor valorhttps://scrum.menzinsky.com/2015/08/como-se-mide-el-valor-de-las-historias.html, la búsqueda avanzada por ejemplo. De esa manera no se rompe el objetivo del sprint y maximizamos los beneficios que obtendrá la tienda.

En gestión clásica podemos construir por ejemplo 45 funcionalidades y en un proyecto con Scrum 22, en la gestión clásica quizá se hayan dado solución a 2 problemas de negocio (outcomes) con esos 45 outputs, en Scrum 10 soluciones con esos 22 outputs... esa es la verdadera esencia de Agile y Lean.

Vyacheslav Moskalenko nos describe en su artículo "7 Sprint Goal Patterns for Building Great Teams, Part One" 7 patrones que nos guiarán en la correcta identificación de un objetivo del sprint:

• El objetivo del sprint debe fomentar una función o funcionalidad coherente.
• El Propietario del Producto debe estar de acuerdo con el equipo de desarrollo y debe de ser capaz de mejorar el alcance de los requisitos para que el equipo vaya más allá de una misión cumplida (objetivo del sprint). El equipo de desarrollo debe de intentar mejorar la tecnología y la forma de trabajar en equipo para hacer tantos puntos de historia como sea posible.
• El objetivo del sprint, o el objetivo de la misión, no se debe de repetir a lo largo de varios sprints. Cada sprint debe tener su propia misión única.
• El objetivo del sprint (misión) puede consistir en varias historias de usuario (quests). No podemos contar los puntos de una historia de usuario si no está completamente terminada de acuerdo con la definición de hecho (DoD).
• Establecer el objetivo del sprint es responsabilidad del Propietario del Producto, pero elaborarlo es una responsabilidad compartida del equipo Scrum, incluido el Propietario del Producto.
• El objetivo del sprint fomenta la iniciativa en múltiples áreas: trabajo en equipo, tecnología, calidad y mentalidad. Sin embargo, mientras mejoran esas áreas, hay que asegurarse de que se está construyendo un incremento potencialmente instalable en producción al final del sprint.
• El objetivo del sprint es el prototipo para futuros resultados de sprint. Hagámoslo hermoso y atractivo.

Veamos que ocurre con Scrum escalado, ¿los objetivos siguen siendo la clave para guiarnos hacia buenas soluciones de negocio?

Si miramos el marco de SAFe podemos observar que a nivel de los equipos se construye con iteraciones guiadas por objetivos (Goals), tal como marca Scrum. Cuando escalamos vemos que tenemos pilas de elementos a diferentes niveles, que priorizadas por valor de negocio (realmente WSJF), llevan las intenciones estratégicas a los equipos. Estos las cocinan y así obtienen los objetivos que escalan al equipo de equipos (Agile Release Train) en forma de objetivos agregados (PI Objectives). Estos son un plan factible de entrega de valor para las mejores soluciones a los problemas de negocio.

Essential SAFe con los elementos que guían hacia los outcomes - cortesía de Scaled Agile

La realidad, los verdaderos outcomes, se producen al final de los PI, en PIs guiados por los objetivos y la Continuous Delivery Pipeline. Recordemos que no todo puede saberse al principio, una buena solución se descubre y redefine a lo largo del camino, mediante exploración continua para despejar incertidumbre, puntos de integración y aprendizaje continuo que mejoran de forma iterativa el producto, así como con despliegue continuo que permite validar asunciones y conseguir la mejor solución posible a problemas reales.

Fijémonos que los objetivos nos alinean con el segundo valor del Manifiesto Ágil:

"El software que funciona, por encima de la documentación exhaustiva"

Si nos focalizamos en objetivos ya no nos interesa el seguimiento del cumplimiento de funcionalidades o historias de usuarios, lo que nos interesa es el avance hacia la entrega de valor que describen. En caso de escalado SAFe medimos este avance hacia los objetivos del sprint y éstos versus los PI Objectives.