Tiempo de lectura: 7 minutos
– ¿Y si te dijera que podrías llevar la capital de Rusia a tu proyecto? – ¡Tú estás loca!

La teoría

Bromas, gifs y juegos de palabras aparte, ¿qué es exactamente el método o la técnica de MoSCoW? En pocas palabras, es una técnica de priorización. En muchas palabras, es una técnica de priorización usada en gerencia, análisis, gestión de proyecto y desarrollo de software para alcanzar un punto común con los stakeholders con respecto a la importancia de cada entrega y requerimiento; se le conoce también como priorización de MoSCoW o análisis de MoSCoW. Pero mejor, empecemos antes por entender el acrónimo:
  • M – MUST (have)
  • S – SHOULD (have)
  • C – COULD (have)
  • W – WON’T (have)
¿Y las ‘o’? Las pobres ‘o’ no significan nada, pero las queremos igualmente, porque sin ellas sería impronunciable nuestra súper técnica.

Cada ‘letra’ en detalle…

Para una comprensión más fácil o más realista, partamos de un ejemplo muy básico: queremos desarrollar una nueva aplicación de TODO, es decir, una aplicación donde poder añadir/ver/listar nuestras tareas.

Must have (o ‘Debe tener’ en español)

Es el nivel de prioridad más alto, se podría decir que “sin lo que tenga esta priorización no puedo continuar“. Si estoy priorizando requisitos, sin este requisito, el ticket (o el sprint, lo que proceda, lo que estemos priorizando) no sale adelante. En nuestro ejemplo, un requisito Must have podría ser la funcionalidad de “listar elementos” y “añadir un nuevo elemento”, si nuestra aplicación de añadir tareas a nuestra lista de tareas no permite añadir una nueva y ver las que tengo, que es la funcionalidad core (la más básica), entonces carece de sentido.

Should have (o ‘Debería tener’ en español)

Este nivel de prioridad aunque es muy importante, no es bloqueante, podríamos salir adelante sin él, aunque, vulgarmente dicho, estaría feo. Por ejemplo, las opciones de “editar elemento” o “borrar elemento”. Puedo sacar la versión base de mi aplicación sólo listando y añadiendo elementos, sin permitir editarlos ni borrarlos, pero estaría un poco feo, editar y borrar son funcionalidades muy importantes que nuestra aplicación debería tener.

Could have (o ‘Podría tener’ en español)

En el tercer nivel podemos meter las que son relativamente importantes pero prescindibles. Volviendo a nuestro ejemplo, aquí podríamos meter “pedir confirmación antes de eliminar elemento”, ¿es vital? ¿mi aplicación no funciona sin eso? No. ¿Es importante? Sí, más o menos.

Won’t have (o ‘No tendría’ en español)

En este caso hay gente que opta por poner Would have en vez de Won’t have. Y aquí entran las que son totalmente prescindibles, las que haremos en un futuro “ya si eso”, si tenemos tiempo, dinero, ganas, etc. Siguiendo con el ejemplo, aquí entran muchas opciones, desde “añadir animación al eliminar elemento” a “reproducir audio ‘hello darkness my old friend‘ cuando la lista se quede sin elementos”, y un largo etc. Aquí van desde chorradas hasta cosas fancy. Soñar es gratis, los proyectos no lo son, pero categorizar cosas como Won’t have sí lo es, así que… ¡por pedir won’t have que no quede!

La práctica

Aunque ya hemos visto un ejemplo con la teoría, priorizando por así decirlo los requisitos de un proyecto nuevo, vamos a exponer un par de casos más en diferentes ámbitos. La técnica fue creada con la finalidad de priorizar los requisitos en un proyecto para que todos los involucrados en el mismo compartiesen una visión y objetivos en el mismo orden: desde el stakeholder hasta el desarrollador pasando por el jefe de proyecto, todos deberían en el mismo punto en cuanto a prioridades se trata. Pero, también es cierto que no deja de ser una técnica de priorización y por ende perfectamente aplicable a todo lo que sea priorizable. Tú como desarrollador, QA o sea cual sea la función que desempeñes, también puedes aplicar esta técnica en tu día a día. A veces un proyecto no cuenta con todos los eslabones de la cadena, pero estoy segura de que sea cual sea tu perfil, en algún momento te va a tocar priorizar. Así pues, veamos un par de ejemplos más en diferentes situaciones. En todos los casos, vamos a seguir con el mismo ejemplo de aplicación de TODO.

> Sprint

En el ejemplo que hemos visto en la teoría, también podría tratarse de un Sprint, el primero en este caso, en el que parece que es más sencillo ver qué es lo prioritario. Pero obviamente se puede aplicar en cualquier Sprint. Si estamos decidiendo qué tickets van a entrar en el siguiente Sprint y no tenemos muy clara la capacidad de nuestro equipo o simplemente como ya sabemos que las estimaciones a veces nos timan, priorizando los tickets nos aseguramos de que lo importante va a entrar y lo prescindible si da tiempo, entra, si no, no.
Tipo Ticket MoSCoW
Defecto Cerrar sesión no funciona MUST
User Story Compartir lista de tareas COULD
User Story Tener más de una lista de tareas SHOULD
User Story Cambiar el color de fondo de la lista de tareas WON’T
Ya tenemos la aplicación en producción y miles de usuarios quejándose de que no puede cerrar sesión y quieren cerrarla porque han iniciado en un PC público o por lo que sea. La cuestión es que en el siguiente Sprint mi prioridad número 1 es arreglar ese defecto, y sin eso mi Sprint no sale adelante. Después, compartir una lista es una funcionalidad que podría tener, pero realmente me es más importante y urgente que un usuario pueda crear más de una lista. Así, además, empieza a tener más sentido el compartirlas, tengo la mía privada y luego creo nuevas que quiero compartir con mis amigos, familia, pareja, etc. Por último, si me da tiempo, quiero que el usuario pueda elegir el color de fondo.

> User Story

Podemos seguir bajando niveles, siempre que tenga sentido. Si nos encontramos con una user story, o historia de usuario, o funcionalidad nueva, relativamente grande, vamos a desarrollarla y no sabemos por dónde empezar, MoSCoW puede ayudarnos mucho a poner las prioridades en orden y empezar por donde debemos y no perdernos en el camino. Aquí es el único caso en el que voy a salir del ejemplo de la aplicación de TODO por ser demasiado sencilla. Pongamos por ejemplo que estamos desarrollando una app que va a permitir una búsqueda por filtros. Por complicarlo un poco, pongamos que tiene 4 filtros, Ciudad, Restaurantes, Bares y Pubs y que en función de lo que se selecciona en el filtro Ciudad, se cargarán los filtros Restaurantes, Bares y Pubs.
Tarea MoSCoW
Cargar la lista de Ciudades MUST
Cargar las listas de Restaurantes, Bares y Pubs MUST
Filtrar búsqueda por filtros seleccionados MUST
Botón limpiar filtros COULD
Deshabilitar Restaurantes, Bares y Pubs si no se ha seleccionado una Ciudad WON’T
Recargar Restaurantes, Bares y Pubs en función de la Ciudad elegida SHOULD
Las tres primeras subtareas son el grueso principal, el objetivo primordial de nuestra tarea, cargar los filtros y un botón ‘Filtrar’ que, cuando le des, filtre por los filtros seleccionados. La siguiente prioridad es que si el usuario cambia el valor del filtro Ciudad, los filtros Restaurantes, Bares y Pubs se vuelvan a cargar. Esto es algo muy importante pero no es vital, podemos salir sin esto y se podría solucionar/mejorar más adelante pero, repito, sigue siendo muy importante. Un botón para borrar todos los filtros estaría fenomenal por el tema de usabilidad, pero no es vital, sólo relativamente importante. Y por último, el hecho de deshabilitar los filtros Restaurantes, Bares y Pubs para que el usuario no pueda verlos hasta que no haya elegido Ciudad hace la aplicación más bonita, práctica, como quieras llamarlo, pero en cuanto a funcionalidad no mejora nada, es esa cosa fancy que quieres pero que sólo harás si te sobra tiempo.

> Testing

Voy a exponer un caso muy general, en el que poder aplicar MoSCoW para crear los diferentes Test Plan para los diferentes niveles de testing (Smoke, Sanity y Regression). Resumiendo muy muy mucho los niveles, se puede decir que:
  • Smoke: cubre la funcionalidad básica sin la cual mi aplicación no funcionaría
  • Sanity: nivel intermedio entre Smoke y Regression
  • Regression: cubre “toda” la funcionalidad para asegurarse de que no hemos roto nada
Pero aquí caben miles de ejemplos diferentes, dependiendo de a qué nivel estemos elaborando el Test Plan, si son Smoke, Sanity y Regression de la aplicación en general, si es de una funcionalidad específica, etc. Así que, por no entrar en detalles de Testing, es simplemente un ejemplo muy generalizado:
Test Case Smoke Sanity Regression
Botón añadir, añade elemento a la lista MUST MUST MUST
Elemento se resalta al ser seleccionado WON’T WON’T COULD
Botón eliminar, borra elemento de la lista COULD SHOULD MUST
Elemento nuevo se añade al final de la lista WON’T COULD SHOULD
Lo principal de mi aplicación es que me añada elementos, así que eso tengo que cubrirlo mínimo con un Smoke y en el resto de niveles, es una funcionalidad que no se me puede romper, tengo que probarla siempre. Que el elemento se resalte al ser seleccionado es totalmente prescindible, si me da lugar lo cubro en Regression. Eliminar es algo que puedo probar de pasada en Smoke y más a fondo en niveles superiores de testeo, y algo parecido pero en menor grado de importancia sucede con la prueba de que elemento se añada al final de la lista.

Conclusiones

MoSCoW no está en Rusia y se puede aplicar a todo lo que sea priorizable. Realmente ya aplicamos MoSCoW muchas veces sin saberlo, inconscientemente, esto no es más que “llevarlo a papel”, pararte a pensarlo un poquito. Pero ese poquito, aunque parezca una tontería, puede ayudarnos mucho, tener las prioridades en la cabeza puede confundirnos, hacer que no prioricemos bien o simplemente que se nos pase y perdamos el foco. Como todo en esta vida, la priorización es relativa, ¿relativa a qué? Pues nuevamente, como todo en esta vida, depende. Obviamente siempre va a ser relativa a la persona que prioriza, pero puede ser relativa al cliente, puede ser relativa al tiempo, al dinero, etc. Por ejemplo, en el caso de uso que hemos visto en el ejemplo del Sprint, elegir el color de fondo en ese Sprint era un WON’T, pero lo mismo 10 Sprints después mi foco está en cambiar el aspecto de la aplicación y que sea 100% personalizable, por lo que en ese Sprint podría ser perfectamente un MUST. Y ya cierro este bloque y este post con un último ejemplo súper importante y vital:
Tarea MoSCoW
Comentar entrada COULD / WON’T
Seguir a Gloin para no perderte futuras entradas del blog MUST
Compartir entrada SHOULD
Compartir es vivir, y vivir es MUY importante, así que ¡vive y comparte! Pero bueno, no es vital, podríamos sobrevivir sin eso. Lo que no podemos es seguir adelante si no nos sigues, es más, fíjate si te cuidamos que ni siquiera te hemos puesto como tarea importante comentar la entrada, aunque nos encantaría leer qué opinas. 🤓

Verónica Ojeda

Software Developer @ Gloin - También intento ver todas las series que me recomiendan, leo millones de artículos (desde tecnología, hasta recetas semisanas, pasando por muchos DIY), y por último, pero no menos importante, viajo más de lo que puedo y menos de lo que debo.