Priorización MoSCoW: Must Have, Should Have, Could Have y Won’t Have
Explicita las renuncias que hay detrás de las etiquetas.
En esta página
La priorización MoSCoW clasifica los requisitos en cuatro grupos: Must Have, Should Have, Could Have y Won’t Have esta vez. Distingue de forma práctica lo imprescindible para que una entrega funcione de lo que puede posponerse.
Su valor no está en las cuatro etiquetas, sino en el acuerdo que expresan: qué protegerá el equipo, a qué puede renunciar y quién puede cambiar esa decisión.
¿Qué es la priorización MoSCoW?
MoSCoW es una técnica de priorización del alcance utilizada en DSDM y otros entornos de proyectos. Aplica sus categorías a un resultado y plazo concretos. Un «Must Have» del proyecto completo no tiene por qué serlo de su primera versión.
Entiende el resultado como un acuerdo condicionado sobre el alcance, no como una lista pendiente ordenada ni como prueba de que el plazo es viable.
Referencia visual. Valora las categorías según el propósito de esta entrega. Compara esfuerzo estimado, no recuentos; excluye lo que no se incluirá del esfuerzo incluido. Un imprescindible no debe depender de trabajo opcional. Las etiquetas no determinan capacidad, calendario ni preparación para publicar.
Versión en texto
Para un resultado y plazo definidos / las categorías delimitan el alcance, no ordenan prioridades ni garantizan la entrega
- Imprescindible
- Prueba de decisión: Detener la entrega si falta; Registrar la consecuencia: Evidencia mínima de aceptación
- Debería incluirse
- Prueba de decisión: Importante; existe una alternativa viable; Registrar la consecuencia: Alternativa, responsable y coste
- Podría incluirse
- Prueba de decisión: Útil; aplazarlo tiene menor impacto; Registrar la consecuencia: Beneficio e impacto del aplazamiento
- No se incluirá esta vez
- Prueba de decisión: Fuera del alcance actual de forma explícita; Registrar la consecuencia: Límite y motivo para revisarlo
¿Por qué importa?
«Alta prioridad» oculta una pregunta importante: ¿por qué detendríamos realmente el lanzamiento? Un servicio de reservas que no evita la sobreventa de plazas y otro que no ofrece accesos rápidos a clases favoritas tienen problemas diferentes, aunque ambas peticiones tengan defensores entusiastas.
Una priorización útil convierte esas diferencias en decisiones antes de que peligre una fecha. También revela cuándo el mínimo propuesto supera los recursos disponibles. Cambiar etiquetas no crea capacidad.
Las cuatro categorías y sus pruebas de decisión
| Categoría | Prueba de decisión para este plazo | Qué registrar |
|---|---|---|
| Must Have | Sin él, la entrega no es viable o aceptable; detenerse en lugar de lanzar. | El fallo que impide lanzar y un mínimo comprobable. |
| Should Have | Importante, pero existe una alternativa temporal operativa. | La alternativa, su responsable y su coste o inconveniente. |
| Could Have | Útil, con menores consecuencias si se omite. | El beneficio y qué sucede si se aplaza. |
| Won’t Have esta vez | Deliberadamente fuera del alcance actual. | El límite y cuándo o por qué reconsiderarlo. |
Son categorías de compromiso, no de satisfacción del cliente. Una función «básica» del modelo Kano no se convierte automáticamente en Must Have para cada versión. Comprueba usuarios previstos, propósito y plazo de la entrega.
Para un Should Have, «lo haremos manualmente» no basta. Indica quién lo hará, si dispone de tiempo y cómo se gestionarán los errores. Una alternativa que no puede operarse realmente no es un respaldo creíble.
Empieza por un resultado, no por una lista de deseos
Escribe una breve declaración del alcance antes de etiquetar requisitos:
En seis semanas, los socios actuales del gimnasio podrán reservar por sí mismos una plaza en una clase programada y el personal podrá confiar en el límite de capacidad de la clase.
Este ejemplo excluye deliberadamente cobros, captación de socios y recompensas de fidelidad. Pueden importar al negocio, pero no todos son necesarios para el propósito de esta versión. Una hoja de ruta de producto aporta la dirección general; MoSCoW explicita el límite de una entrega.
Define por separado las condiciones de calidad y funcionamiento. La hoja siguiente no evalúa seguridad, accesibilidad, legalidad ni preparación para lanzar. Los especialistas pertinentes deben identificar los requisitos aplicables. Recortar alcance opcional no autoriza a rebajar la calidad esencial.
Ejemplo desarrollado: la versión del gimnasio en seis semanas
Ejemplo hipotético. El gimnasio y el equipo disponen de 30 jornadas-persona para esta versión, tras descontar otros compromisos conocidos. Estiman el siguiente trabajo con la misma unidad de esfuerzo. Cada estimación incluye implantación, pruebas y traspaso necesarios para esa fila; el trabajo compartido se asigna una vez, sin duplicarse en otras.
Escena ilustrativa de planificación en un gimnasio de barrio para el ejemplo hipotético de una versión de reservas; no es un negocio real, un equipo de proyecto ni una demostración de software.
| Requisito | Prioridad | Esfuerzo | Prueba o alternativa |
|---|---|---|---|
| Ver el horario y reservar una plaza | Must Have | 8 días | Un socio puede reservar una clase disponible y ver la confirmación. |
| Evitar reservas por encima de la capacidad | Must Have | 6 días | Dos solicitudes simultáneas de la última plaza no pueden completarse ambas. |
| El personal gestiona horarios y capacidad | Must Have | 4 días | El personal puede crear las clases que necesita el servicio. |
| Enviar un recordatorio antes de la clase | Should Have | 6 días | Recepción envía manualmente una lista diaria temporal de recordatorios. |
| Guardar clases favoritas | Could Have | 6 días | Los socios pueden encontrar la misma clase en el horario sin acceso rápido. |
| Obtener insignias de fidelidad | Won’t Have esta vez | No incluido | Reconsiderar tras observar la primera versión; no forma parte del esfuerzo total. |
Los tres Must Have suman 18 jornadas-persona. El alcance candidato incluido es 18 + 6 + 6 = 30 jornadas-persona. Los Must Have representan, por tanto, 18 ÷ 30 = 60% del esfuerzo estimado incluido, no el 60% del número de requisitos. Los Won’t Have quedan fuera del denominador.
Las 12 jornadas estimadas restantes son alcance opcional valioso, no 12 días de inactividad. Si la incertidumbre consume esfuerzo, el equipo ya ha acordado qué puede eliminar. No se promete completar todos los elementos.
La orientación habitual de DSDM para proyectos o incrementos sugiere limitar los Must Have aproximadamente al 60% del esfuerzo y conservar alrededor del 20% como Could Have. Es una pauta de planificación, no una cuota universal ni garantía de entrega. El equilibrio adecuado depende del riesgo y la confianza del plan concreto.
Treinta jornadas-persona no son treinta días transcurridos. Especialidades, dependencias, ausencias y aprobaciones externas también condicionan si el trabajo cabe en seis semanas. Igualar totales no demuestra un calendario viable.
¿Qué cambia cuando el plan se complica?
Supón que controlar la capacidad requiere 10 días en lugar de 6. El alcance candidato total pasa a 34 días frente a 30 disponibles. El esfuerzo Must aumenta a 22 días, alrededor del 64.7% de 34.
Eliminar la función de favoritos de 6 días deja 28 días estimados, incluidos los recordatorios. Hay 2 días estimados de margen, pero los Must Have son 22 ÷ 28 = 78.6% del esfuerzo incluido restante. La carga encaja aritméticamente, pero el plan es menos flexible. Es un motivo para revisar el riesgo, no para celebrar una puntuación verde.
Si el mínimo ya no cabe, las opciones son sustantivas: acotar el resultado, dividir un requisito en una parte menor realmente utilizable, cambiar la fecha o reevaluar recursos. No renombres trabajo necesario como «Should Have» solo para mejorar un porcentaje.
Cuestiona las dependencias ocultas
En el ejemplo, la reserva del socio necesita un horario que proporciona el personal. Hacer opcional la gestión de horarios dejaría un Must Have dependiente de trabajo que quizá no se entregue.
Remonta cada requisito esencial hasta sus prerrequisitos. Protégelos o rediseña la solución con una alternativa creíble. Comprueba también proveedores, aprobaciones, datos y preparación operativa, no solo funciones de software.
Por ejemplo, los recordatorios por correo pueden depender de la aprobación de un proveedor externo. Si es incierta, regístrala como riesgo de entrega. Una etiqueta no adelanta esa aprobación.
La hoja registra una dependencia crítica por elemento para mantener reducido el ejercicio. Señala conflictos evidentes entre Must y opcionales y ciclos en los vínculos registrados. No es un modelo completo de dependencias ni un motor de planificación.
Resuelve desacuerdos mediante consecuencias
Imagina que el propietario considera los recordatorios un Must Have porque importa la asistencia. La persona de recepción dice que puede gestionar una lista manual las dos primeras semanas. En lugar de votar la etiqueta, pregunta:
- ¿Qué resultado concreto falla sin recordatorios automáticos?
- ¿Puede recepción operar de forma fiable la alternativa con el volumen de esta versión?
- ¿Qué tiempo extra o errores harían inaceptable la alternativa?
- ¿Quién tiene autoridad para aceptar el coste temporal?
Si la alternativa es aceptable, los recordatorios pueden seguir siendo Should Have, con responsable y fecha de revisión. Si no, actualiza conjuntamente alcance, esfuerzo y decisión de entrega. Registra el desacuerdo pendiente en lugar de fingir que el taller generó consenso.
Controla nuevas peticiones sin congelar el aprendizaje
Una nueva petición no se rechaza automáticamente ni se añade gratis. Registra su motivo, estimación, efectos sobre dependencias y renuncia propuesta. La persona responsable debe poder decir:
Añadimos X por estas pruebas. Aplazamos Y, o cambiamos fecha o recursos, y aceptamos estas consecuencias.
Conserva la decisión anterior en el registro del proyecto y comunica el límite nuevo. «Won’t Have esta vez» debe tener un desencadenante de reconsideración, no convertirse en una promesa olvidada de entrega segura en la siguiente versión.
MoSCoW, RICE y una hoja de ruta responden a preguntas distintas
| Enfoque | Pregunta principal | Qué no establece |
|---|---|---|
| MoSCoW | ¿Qué es esencial, opcional o está excluido en este plazo? | Un orden exacto dentro de una categoría o un calendario viable. |
| Priorización RICE | ¿Cómo se comparan las opciones en alcance, impacto, confianza y esfuerzo? | Qué condiciones operativas o de lanzamiento son innegociables. |
| Hoja de ruta de producto | ¿Qué resultados y direcciones importan en distintos horizontes? | Una promesa fija de entregar todas las funciones enumeradas. |
Utiliza pruebas para comparar alternativas y explicita después el compromiso de la entrega actual. Evita asignar puntuaciones aparentemente precisas a obligaciones solo para hacerlas competir con mejoras opcionales.
Errores habituales y limitaciones
- Contar elementos en lugar de esfuerzo. Tres Could Have pequeños no compensan un Must Have enorme.
- Agrupar lo esencial con extras. «Sistema de reservas» puede esconder un flujo básico, análisis avanzados y decoración con prioridades distintas.
- Llamar Must Have a todo. Si todo es esencial, reconoce el alcance fijo y gestiona fecha, recursos y riesgo en consecuencia.
- Dejar la alternativa sin responsable. Un proceso manual necesita tiempo de personal, acceso y una forma de detectar errores.
- Confundir «cabe» con «se terminará». Las estimaciones aproximadas no demuestran dotación, secuencia ni fechas de aprobación.
- Confundir exclusiones con compromisos posteriores. Reconsiderar no garantiza una entrega futura.
MoSCoW estructura el criterio; no elimina la política, valida demanda ni calcula valor empresarial. Dos equipos pueden clasificar de forma diferente una misma función por tener objetivos y restricciones distintos. Haz esas suposiciones suficientemente visibles para cuestionarlas.
Ponlo en práctica: acuerda el límite de una entrega
Utiliza 25 minutos para una primera revisión, no para un plan completo. Elige un resultado, una fecha y la persona autorizada para resolver renuncias. Enumera hasta 12 requisitos concretos. Registra categoría, consecuencia de omitirlo, pruebas de aceptación, responsable y una dependencia crítica si procede.
Añade estimaciones comparables de esfuerzo y capacidad disponible en jornadas-persona. Indica la fuente e incertidumbre en las notas de decisión; no sustituyas las pruebas ausentes por precisión inventada. Cuestiona los Must Have, prueba un retraso o sobrecoste y termina con una decisión o acción de recogida de pruebas y un momento de revisión.
Imprescindible (0)
Debería incluirse (0)
Podría incluirse (1)
- Requisito sin título
No se incluirá esta vez (0)
Añade estimaciones de esfuerzo positivas y comparables para todos los requisitos incluidos. El esfuerzo desconocido no es cero.
Antes de descargar (13 checks)
- Resultado: add the missing context.
- Plazo: add the missing context.
- Responsable de la decisión: add the missing context.
- Pruebas, incertidumbre y siguiente decisión: add the missing context.
- Momento de revisión: add the missing context.
- Capacidad: introduce jornadas-persona positivas, hasta 100,000, con un máximo de dos decimales y sin separadores.
- Identifica una entrega mínima con al menos un Must Have.
- Elemento 1: registra requirement.
- Elemento 1: registra motivo / alternativa / exclusión.
- Elemento 1: registra pruebas de aceptación o límite de exclusión.
- Elemento 1: registra owner.
- Elemento 1: introduce jornadas-persona positivas, hasta 100,000, con un máximo de dos decimales y sin separadores.
- Confirma personalmente el alcance, la unidad de esfuerzo y las dependencias registradas; el ejemplo no está preaprobado.
Lista de comprobación rápida
Conclusión final
MoSCoW funciona cuando modifica una decisión real. Protege el resultado mínimo aceptable, identifica alternativas realistas, estima el esfuerzo y acuerda quién puede negociar alcance si cambian las condiciones.
El resultado útil no es un tablero lleno de etiquetas. Es una entrega mínima que las personas pueden explicar, trabajo opcional que realmente están dispuestas a aplazar y un límite honesto para esta versión.