El método MoSCoW: una Sprint Planning “a lo ruso”

Te voy a pedir que respondas a una pregunta, pero antes déjame darte algo de contexto. Imagina que estás en una Sprint Planning, donde la Product Owner os presenta un Objetivo del Sprint candidato, y una serie de Product Backlog Items (PBIs) candidatos que, en conjunto, permiten alcanzar dicho Objetivo del Sprint. Entonces, y aquí llega la pregunta, en este contexto y como miembro del Scrum Team: ¿te sentirías más cómodo si y sólo si el Objetivo del Sprint se alcanzase si se finalizan (“done done”) todos y cada uno de los PBIs candidatos? ¿o si pudieseis alcanzar el Objetivo del Sprint desarrollando tan solo unos pocos de los PBIs candidatos, y el resto de los PBIs sirviesen para aportar aún más valor al mismo?

Normalmente, la respuesta es que nos sentiríamos más cómodos en el segundo caso (alcanzar el Objetivo del Sprint desarrollando unos pocos PBIs candidatos, y que el resto de los PBIs candidatos aporten aún más valor a dicho objetivo), ya que, en otro caso, nos estaríamos jugando el éxito del Sprint a todo o nada. Pero también muchos Scrum Teams me confiesan que no saben cómo lograr esto que, para ellos, suena a utopía.

Sin embargo, hay una herramienta que puede ayudar mucho para lograrlo, y es el llamado método de priorización MoSCoW. Responde a un acrónimo donde encontramos 4 diferentes categorías para, en nuestro caso, los PBIs de un Sprint Backlog: Must, Should, Could, Wishes (normalmente hace referencia a will not have at this time, pero en el contexto de una Sprint Planning y un Sprint Backlog, prefiero hablar de deseos –wishes– que de cosas que ya de primeras sabemos que no estarán –will not have). 

Para ayudarte a entender cómo aplicar esta técnica, vamos a suponer que estamos desarrollando un nuevo instrumento para pintar en superficies vidriosas (cristal, espejo, azulejo…), y que el Objetivo del Sprint candidato es “Lograr que el nuevo instrumento de escritura escriba”.

• Must: en el contexto en el que hablamos, son aquellos PBIs que no son negociables y sin los que, directamente, el Objetivo del Sprint no se habrá alcanzado. 

En nuestro ejemplo, podría ser un PBI como el siguiente: “La escritura o el dibujo desarrollado con el nuevo instrumento permanece en el soporte en que se ha escrito durante un tiempo mínimo de un año”.

• Should: bajo esta categoría, se encontrarían aquellos PBIs que, si bien no son vitales para la consecución del Objetivo del Sprint, su ausencia hará parecer “pobre” el objetivo alcanzado.

En nuestro ejemplo: “La escritura o el dibujo desarrollado con el nuevo instrumento se puede borrar frotando con un paño con alcohol”.

• Could: los PBIs de la categoría Could serían aquellos que lograrían que los Stakeholders se emocionasen en la revisión del Sprint, pero que si no los ven, seguirán considerando el Objetivo sobradamente alcanzado.

Siguiendo con el ejemplo: “La escritura o el dibujo desarrollado con el nuevo instrumento se puede compartir a dispositivos digitales”.

• Wishes: finalmente, la categoría de los deseos, aquellos PBIs que para nada están priorizados para el presente Sprint, pero que están relacionados con su Objetivo y que, por tanto, en el caso de que sobrase tiempo, los Developers podrían tomar persiguiendo la meta de entregar el máximo valor posible relacionado con el Objetivo del Sprint específico del Sprint presente.

En nuestro ejemplo, imagina algo así como “El nuevo instrumento puede reproducir escritura o dibujos desde dispositivos digitales”.

Como verás, si el Scrum Team es capaz de lograr el primer PBI, ya habrá alcanzado el Objetivo del Sprint. Según vaya avanzando con más PBIs del Sprint Backlog, estará logrando aportar más y más valor en el mismo Sprint. Y aquellos PBIs que se queden sin desarrollar, será cuestión de que la Product Owner los re-priorice en función del feedback obtenido en la Revisión y el roadmap del producto (que habrá sido construido, en el mejor de los casos, en base a Objetivos del Sprint y no a PBIs).

Así que ya sabes, si quieres darle un punto extra de madurez a tus Sprint Plannings y Sprint Backlogs, siempre podrás aplicar el método de priorización MoSCoW a la hora de seleccionar los PBIs que permiten alcanzar dicho Objetivo del Sprint.