 |
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:
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:
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.
