El análisis MoSCoW y similares no funcionan. O no funcionan mucho a efectos prácticos. Quizás, a lo sumo, nos sirvan a la hora de definir un producto mínimo viable inicial o, incluso, un producto mínimo viable para cada Sprint.

Me explico.

El análisis MoSCoW es una técnica de priorización popularizada por el DSDM (Dynamic Systems Development Method, que se encuadra dentro de las metodologías ágiles). Su principal ventaja es su carácter intuitivo, al establecer cuatro categorías o niveles de prioridad que se expresan de una forma sencilla de entender: “Must have”, “Should have”, “Could have” y “Won’t have”.

Must have. Son aquellos requerimientos obligatorios, que tienen que estar en el producto sí o sí, en todo caso. Si nos falta algún must have, el producto no está listo en la fecha de entrega que hayamos previsto.

Should have. Importantes pero no imprescindibles en este justo momento. Pueden esperar algo más que los must have. Si no los incluimos en el lanzamiento será doloroso, aunque no el fin del mundo. El producto aún será considerado viable.

Could have. O, para que se entienda mejor, nice to have. Son requerimientos deseables, que mejorarían la experiencia de usuario, pero que solo incorporaremos al producto si el tiempo y el presupuesto lo permiten.

Won’t have. Alude a aquellas características que no son adecuadas para el producto en el momento de que se trate y que explícitamente hemos acordado no incluir en el producto.

Aunque el análisis MoSCoW sea, en principio, más completo o enriquecedor que el análisis basado en los típicos niveles de prioridad alta, media y baja, al final adolece del mismo inconveniente. Si le preguntas al cliente que qué es lo más importante, acabaremos con un 80% de historias de usuario de prioridad alta, Must have o Should have. El clásico “todo es importante”. Este planteamiento nos lleva, cuando la funcionalidad obligatoria es extensa, a hacer waterfall; esto es, entregaremos todo eso que es tan importante de golpe, al final de un largo viaje.

Lo que de verdad hay que considerar no es el nivel o categoría de prioridad, sino el orden: dime qué quieres hacer primero, qué quieres hacer en segundo lugar, en tercero, y así. Cuanto más arriba en el Product Backlog, más importante es el elemento. La categoría de prioridad es irrelevante. En la actualización de 2011, de hecho, la Guía Scrum modificó el término y, en vez de indicar que el Product Backlog es “priorizado”, pasó a decir que el Product Backlog es “ordenado” por parte del Product Owner.   El orden de los elementos del Product Backlog refleja las decisiones que toma el Product Owner. Si la estrategia de producto está bien trazada, tal ordenación nos permitirá poner en producción una sucesión de versiones o productos mínimos viables, de manera incremental.