MoSCoW: Difference between revisions

Latest revision as of 11:50, 20 May 2026

⏱ 4 min de lectura · 📅 Actualizado en 2026

MoSCoW es un método de priorización de requisitos, épicas o historias de usuario en cuatro niveles de prioridad: Must have (imprescindible), Should have (recomendable), Could have (deseable) y Won't have (no en esta versión). Las letras en mayúscula del acrónimo corresponden a los cuatro niveles; las "o" minúsculas son vocales añadidas para hacer pronunciable la palabra.

Origen

El método fue desarrollado por Dai Clegg en Oracle en los años noventa en el contexto de DSDM, la metodología dinámica de desarrollo de sistemas. Hoy se usa de forma independiente de DSDM en todo tipo de proyectos ágiles.

Los cuatro niveles

Must have — imprescindible

Requisito crítico que debe implementarse para que el sistema tenga valor. Sin él, el proyecto no puede considerarse un éxito. Se usa la prueba de "¿qué pasa si no está?": si la respuesta es "el sistema es inútil o ilegal", es un Must have.

Should have — recomendable

Requisito importante pero no crítico. El sistema puede funcionar sin él, pero su ausencia reduce significativamente el valor. Suele ser el candidato natural para la siguiente versión si no entra en la actual.

Could have — deseable

Requisito que aportaría valor pero cuyo impacto es menor. Se incluye si hay tiempo y capacidad; se descarta si hay presión. Son los primeros en salir cuando el alcance hay que reducirlo.

Won't have — fuera del alcance actual

Requisito que no se implementará en esta versión, pero que podría considerarse en el futuro. Explicitar este nivel evita malentendidos: el cliente sabe qué no va a recibir y cuándo podría recibirlo.

Método de aplicación

Se lista todas las funcionalidades, épicas o historias a priorizar.
En equipo, se debate y acuerda la categoría de cada elemento. Conviene empezar por los Must have: si todo es Must have, el proyecto no es viable tal como está planteado.
Se verifica que los Must have no superen el 60% de la capacidad disponible: el resto debe ser flexible para absorber imprevistos.
Se usa el resultado para planificar la versión o el sprint.

Error frecuente

Que todo sea Must have. Cuando el equipo o el cliente marca todo como imprescindible, MoSCoW deja de ser un método de priorización y se convierte en una lista de deseos sin discriminación. La prueba de "¿qué pasa si no está?" aplicada con rigor suele revelar que muchos "Must have" son en realidad "Should have". El facilitador debe ayudar al equipo a hacer esa distinción de forma honesta.

Recursos

🔧 MoSCoWHerramienta · Scrum Manager

Véase también

Pila del producto ICE Score WSJF Kano Priorización de compromisos DSDM Historia de usuario

¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.

Buscar convocatorias

Club Agile

@@ Line 1: / Line 1: @@
-MoSCoW es un enfoque empleado para determinar la prioridad de los requisitos (funcionalidades, [[epic|epics]] o [[historia de usuario|historias de usuario]]).
+{{Meta-bok|min=4}}
-==Origen y evolución==
+'''MoSCoW''' es un método de priorización de requisitos, [[Epic|épicas]] o [[Historia de usuario|historias de usuario]] en cuatro niveles de prioridad: ''Must have'' (imprescindible), ''Should have'' (recomendable), ''Could have'' (deseable) y ''Won't have'' (no en esta versión). Las letras en mayúscula del acrónimo corresponden a los cuatro niveles; las "o" minúsculas son vocales añadidas para hacer pronunciable la palabra.
-El enfoque MoSCoW se originó en el contexto de la metodología DSDM (Desarrollo de Sistemas Dinámicos y Adaptativos). DSDM es un enfoque ágil que promueve la entrega rápida y flexible de proyectos, y MoSCoW se convirtió en una herramienta esencial para la priorización de requisitos en esta metodología.
-A lo largo del tiempo, MoSCoW se ha popularizado y ha sido adoptado en diversos marcos de trabajo y metodologías de desarrollo de software.
+== Origen ==
-==Descripción==
+El método fue desarrollado por Dai Clegg en Oracle en los años noventa en el contexto de [[DSDM]], la metodología dinámica de desarrollo de sistemas. Hoy se usa de forma independiente de DSDM en todo tipo de proyectos ágiles.
-Proporciona una estructura clara para clasificar los requisitos en cuatro categorías según su importancia y necesidad, lo que ayuda a los equipos de desarrollo y a los interesados a tomar decisiones informadas sobre qué funcionalidades o características implementar primero y cuáles pueden posponerse o incluso descartarse.
-El nombre "MoSCoW" es un acrónimo que representa cuatro niveles de prioridad:
+== Los cuatro niveles ==
-#''Must have'' (es necesario).
-#''Should have'' (es recomendable).
+=== Must have — imprescindible ===
-#''Could have'' (podría implementares).
-#''Won't have'' (no lo queremos... quizá en un futuro).
+Requisito crítico que debe implementarse para que el sistema tenga valor. Sin él, el proyecto no puede considerarse un éxito. Se usa la prueba de "¿qué pasa si no está?": si la respuesta es "el sistema es inútil o ilegal", es un Must have.
+=== Should have — recomendable ===
+Requisito importante pero no crítico. El sistema puede funcionar sin él, pero su ausencia reduce significativamente el valor. Suele ser el candidato natural para la siguiente versión si no entra en la actual.
+=== Could have — deseable ===
+Requisito que aportaría valor pero cuyo impacto es menor. Se incluye si hay tiempo y capacidad; se descarta si hay presión. Son los primeros en salir cuando el alcance hay que reducirlo.
+=== Won't have — fuera del alcance actual ===
+Requisito que no se implementará en esta versión, pero que podría considerarse en el futuro. Explicitar este nivel evita malentendidos: el cliente sabe qué no va a recibir y cuándo podría recibirlo.
+== Método de aplicación ==
+# Se lista todas las funcionalidades, épicas o historias a priorizar.
+# En equipo, se debate y acuerda la categoría de cada elemento. Conviene empezar por los Must have: si todo es Must have, el proyecto no es viable tal como está planteado.
+# Se verifica que los Must have no superen el 60% de la capacidad disponible: el resto debe ser flexible para absorber imprevistos.
+# Se usa el resultado para planificar la versión o el sprint.
+== Error frecuente ==
+<div class="bok-aviso">
+'''Que todo sea Must have.''' Cuando el equipo o el cliente marca todo como imprescindible, MoSCoW deja de ser un método de priorización y se convierte en una lista de deseos sin discriminación. La prueba de "¿qué pasa si no está?" aplicada con rigor suele revelar que muchos "Must have" son en realidad "Should have". El facilitador debe ayudar al equipo a hacer esa distinción de forma honesta.
+</div>
+== Recursos ==
+<div class="bok-recurso">
+🔧 [https://scrummanager.com/resources/moscow.html '''MoSCoW''']<span class="detalle">Herramienta · Scrum Manager</span>
+</div>
+== Véase también ==
+<div class="bok-tags">
+[[Pila del producto]] [[ICE Score]] [[WSJF]] [[Kano]] [[Priorización de compromisos]] [[DSDM]] [[Historia de usuario]]
+</div>
+<div class="bok-ecosistema">
+<div class="texto">
+<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
+<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
+</div>
+<div class="botones">
+<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
+<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
+</div>
+</div>
-==Objetivos==
-*Priorizar de manera efectiva los requisitos de un proyecto para garantizar que los elementos más críticos se aborden primero.
-*Ayudar a los equipos de desarrollo y a los interesados a tomar decisiones informadas sobre la asignación de recursos y el cronograma del proyecto.
-*Mejorar la satisfacción del cliente al enfocarse en la entrega de funcionalidades esenciales y valiosas de manera temprana.
-*Facilitar la gestión de cambios al permitir una comprensión clara de las implicaciones de agregar o modificar requisitos en diferentes etapas del proyecto.
-==Cuatro niveles de prioridad==
-===''Must have'' (es necesario)===
-Son aquellos que son esenciales para el éxito del proyecto. Son funcionalidades, características o elementos que deben implementarse en la primera fase del desarrollo, y su ausencia podría comprometer la utilidad del producto o servicio. Son requisitos no negociables y deben abordarse con la máxima prioridad.
-===''Should have'' (es recomendable)===
-Son requisitos importantes, pero no críticos para el funcionamiento básico del producto. Se espera que estos requisitos se implementen después de los "Must have". Su incorporación mejora la calidad o la usabilidad del producto, pero el proyecto podría avanzar sin ellos si es necesario.
-===''Could have'' (podría implementarse)===
-Son requisitos opcionales y se consideran deseables, pero no son esenciales para la entrega inicial. Estos requisitos se abordan si hay tiempo y recursos disponibles después de satisfacer los requisitos "Must have" y "Should have". Su inclusión puede aumentar la satisfacción del usuario o brindar funcionalidades adicionales.
-===''Won't have'' (no lo queremos... quizá en un futuro)===
-Son aquellos que se han decidido deliberadamente no incluir en la versión actual del producto. Esto puede deberse a limitaciones de tiempo, recursos o a la falta de relevancia en el contexto actual del proyecto. Estos requisitos se pueden reconsiderar en futuras iteraciones o versiones, pero no son parte de la entrega actual.
-==Método de aplicación==
-#'''Identificación de requisitos:''' enumerar todos los requisitos, funcionalidades o características que se consideran para el proyecto.
-#'''Clasificación de requisitos:''' cada requisito se clasifica en una de las cuatro categorías: ''Must have, Should have, Could have'' o ''Won't have''.
-#'''Discusión y consenso:''' el equipo de proyecto y los interesados discuten y acuerdan la clasificación de cada requisito. Es fundamental obtener un consenso para evitar malentendidos posteriores.
-#'''Priorización de actividades:''' basándose en la clasificación MoSCoW, se planifican las actividades del proyecto, dando prioridad a los requisitos ''Must have'' y ''Should have'' en las etapas iniciales.
-#'''Seguimiento y ajuste:''' a medida que avanza el proyecto, se monitorea la implementación de los requisitos según su prioridad. Se pueden realizar ajustes a medida que se obtiene más información o surgen cambios en las necesidades del cliente.
-==Véase también==
-*[[Requisitos ágiles]].
-*[[Historia de usuario]].
-*[[Epic]].
 [[Category:Glosario de términos]]
+[[Category:Product Management]]
+[[Category:Prácticas ágiles]]