Los creadores de Scrum han decidido perfeccionarlo en este 2020. Desde el año 2016, Scrum incluye los valores del marco: apertura, coraje, foco, respeto y compromiso. En la nueva versión de la guía, se ha reescrito el significado de los mismos para ser más claros. Además, el valor “compromiso” ha sufrido un gran cambio, ya que se ha reforzado su importancia al incluirlo en cada uno de los artefactos… ¡Lo analizamos!
Valores de Scrum
Scrum incorporó a su guía cinco valores en el año 2016. A pesar de que se puede “jugar” a Scrum de muchas maneras, es esencial dominar estos cinco valores de manera experta, ya que potencian la capacidad de entregar valor de un Scrum Team.
El valor “compromiso” es uno de los que más debate ha suscitado. Inicialmente, se hablaba de que, en la Sprint Planning, el Development Team se comprometía a una cantidad de trabajo a entregar al finalizar el Sprint. Este compromiso trataba de garantizar que el equipo se esforzaba. Sin embargo, en el año 2011 se eliminó de Scrum, dado que, en entornos complejos, como el software, aparecen cambios imprevistos durante el Sprint y necesitamos flexibilidad. Debido a ello, se sustituyó el compromiso del Sprint por una previsión (forecast en inglés). Esta previsión transmitía el siguiente mensaje: “esta es la cantidad de trabajo que creemos que seremos capaces de completar”. Aún así, muchos equipos Scrum han heredado el concepto de “puntos comprometidos” o “alcance comprometido”.
Sin embargo, faltaba motivación en los Sprints y foco (otro de los valores). Así que, se introdujo el Sprint Goal (2013). Con el Sprint Goal definimos un objetivo que nos guiará en la toma de decisiones durante el Sprint. Podían aparecer cambios pero, si no iban a favor del Sprint Goal, podíamos rechazarlos.
Durante mucho tiempo, he defendido que el compromiso se limitaba a “hacer las cosas bien”, lo que supone un conjunto de acciones: calidad en nuestro producto, trabajar en equipo, centrarnos en lo importante, colaborar… Hacer lo correcto suena etéreo, pero nos permite, cuando tengamos dudas, hacer la pregunta: ¿estamos haciendo lo correcto?
Hay equipos que consideraban que el Sprint Goal era un compromiso, dejando los items del backlog para alcanzarlos como previsión. Hemos tenido muchos debates sobre este asunto durante estos años y, por fin, en 2020 lo han clarificado.
Product Goal, el nuevo invitado
Antes de hablar del compromiso, tenemos que explicar el nuevo artefacto introducido en Scrum: product goal. Siempre se ha hablado de que los equipos Scrum deberían tener una visión de producto, un objetivo a largo plazo que les guiara. Oyendo esta idea, se ha decidido que era un buen momento el hacerlo explícito en forma de objetivo. A diferencia de la visión, el Product Goal debería ser alcanzable, más realista.
El Product Goal debe representar un estado futuro de nuestro producto y proporcionar al Scrum Team un foco sobre el lugar hacia el que debe dirigirse. Si se alcanza, o se abandona, se puede crear un nuevo Product Goal. Este nuevo objetivo estará incluido dentro del Product Backlog.
Los nuevos compromisos
En la revisión de Scrum 2020, le han dado una vuelta al papel del compromiso. Cada uno de los artefactos recibe uno:
- El nuevo Product Goal es el compromiso del Product Backlog
- El Sprint Goal es el compromiso del Sprint Backlog
- El cumplimiento del Definition of Done es el compromiso del Incremento
El Product Goal es el objetivo por el cual existe el equipo, y que buscamos alcanzar. El Product Backlog contiene la lista de “qué” vamos a hacer, y debe ir alineado hacia la consecución del Product Goal. El Product Backlog debe ser transparente para que, al inspeccionarlo, sepamos si vamos por el camino correcto hacia el Product Goal.
El Sprint Backlog debe contener al Sprint Goal, además del plan de trabajo y la previsión del Sprint. El plan de trabajo nace de los developers, son ellos los que lo construyen en la Sprint Planning con la finalidad de alcanzar el Sprint Goal. Éste debe ser abierto y poderse abordar de múltiples maneras, evitando que sea un PBI concreto o una determinada cantidad de alcance.
Por último, el Incremento recibe el compromiso de la Definition of Done. No es cuestión de entregar producto, debe estar terminado, y eso significa cumplir su DOD. La DOD, por tanto, debe ser un compromiso a la hora de construir producto, ya que nos hace visible (transparencia) en qué punto está el producto.
Sprint Goal o Definition of Done, ¿quién gana?
Esta aclaración de la guía nos genera una duda: si un equipo llega justo al Sprint Goal y, por ello, deciden reducir la calidad (no cumpliendo la Definition of Done), ¿estamos actuando bien?, ¿qué es más importante? La respuesta es compleja, cuando definimos el Sprint Goal, debemos tener presente la DOD, es un elemento de entrada en la Sprint Planning. Por tanto, debemos tratar de definir un Sprint Goal viable con la Definition of Done. Durante el Sprint, si el Sprint Goal se pone en riesgo, podemos negociar con el alcance, con los PBIs, pero nunca con la calidad, lo que hagamos debe estar bien, porque si no, no inspeccionamos correctamente el estado de nuestro producto.
Y a ti , ¿qué te parecen los compromisos de los artefactos?
