El proceso MoSCoW es una forma sencilla de clasificar las Historias de Usuario que forman el Registro de Producto en un orden de prioridad.
MoSCoW significa:
- Must – Debe tener
- Should – Debería haber
- Could – Podría haber
- Wont – No tendrá que
Must Have – son Historias de Usuario que deben ser incluidas para crear el MVP (Minimum Viable Product). Debe haber formado el núcleo del alcance del trabajo que será necesario entregar.
Should Have – Si tiene historias de usuario que no son críticas para el MVP, pero que se consideran importantes y de alto valor.
Could Have – Historias de usuarios que son “agradables de tener”. Podrían incluirse cuando se disponga de tiempo y recursos. Sin embargo, estas Historias de Usuario serán las primeras en ser eliminadas del alcance si el proyecto corre el riesgo de perder la entrega del MVP.
Wont Have – son historias de usuario o características que el propietario del producto ha solicitado pero no se van a construir. Estas Historias o Características de Usuario pueden ser construidas en el futuro pero no son parte del alcance del trabajo actual.
Siendo realistas, las Historias de Usuario deben ser distribuidas por todas las categorías, para evitar que terminemos con cada Historia de Usuario listada como un Must Have.
Aquí está mi recomendación para los valores de partición:
Must Have – menos del 80% de la capacidad,
Should Have – no más del 20% de la capacidad,
Could Have – no más del 10% de la capacidad,
Wont Have – como no serán construidos, no hay límite necesario.
La técnica de la Hamburguesa
Ante la duda siempre pregúntese que si tengo que hacer una hamburguesa que ingredientes son o no son necesarios.
Si tu Must Have supera el 80% de la capacidad total, no habrá flexibilidad y poca contingencia si algo sale mal. Probablemente habrá algunos Must Haves que decidamos no construir. Al tener un número de Historias de Usuario en las categorías “Deberíamos y Podríamos tener categorías”, creamos flexibilidad ya que podemos optar por subirlas en prioridad.
Agile abraza el cambio y eso significa que no podemos tener cada historia de usuario priorizada como una necesidad.
Pero, ¿qué debe hacer cuando el Product Owner piensa que cada historia de usuario es una necesidad?
Este es un problema al que me he enfrentado varias veces. Lo he manejado haciendo estas preguntas:
1. User Story Mapping – ¿cuál es el camino más básico hacia el éxito?
2. Value Mapping – ¿Qué Historias de Usuario agregan el mayor valor?
3. Viabilidad: ¿cuáles son las historias de usuario más sencillas de construir?
Esto permite al Product Owner identificar que Historias de Usuario que son agradables de tener, piense en Henry Ford cuando decidió producir el modelo negro T Fords sólo en 1914. El mayor valor tanto para Ford como para los clientes fue un coche simple y fácil de construir. Los clientes entendieron que al tener diferentes colores para el Modelo T, haría que fuera más caro construirlo. El color único era barato en costo y muy duradero. También simplificó la línea de producción.
