Priorización MoSCoW: Must, Should, Could y Won't

MoSCoW es un método de priorización que divide el alcance de un proyecto en cuatro categorías según su necesidad, no según su atractivo. Nació en el marco DSDM y lo adoptó el mundo ágil, pero funciona igual en un equipo de tres personas con un backlog de cuarenta tarjetas. Su valor no está en las siglas sino en el compromiso que obliga a tomar: antes de empezar, el equipo y el cliente deciden juntos qué es imprescindible y qué no entra esta vez.

La trampa está en la cuarta categoría: mucha gente cree que MoSCoW tiene tres niveles de «sí» y un cajón de recados. No. Won't have es una decisión tan activa como Must have, y se escribe —más abajo vemos por qué. Y ojo al alcance del método: ordena el alcance de un proyecto, no tu semana. Para ordenar tu día sirve la matriz de Eisenhower, y para el puente entre lo urgente y lo importante, cómo priorizar tareas sin morir en el intento.

Son el mismo gesto mental aplicado a escalas distintas, y confundirlas hace fracasar a los dos métodos. Si usas Eisenhower para priorizar el alcance de un proyecto, las decisiones caducan al día siguiente, porque la urgencia cambia a diario y el alcance no debería. Si usas MoSCoW para ordenar tu martes, pierdes una hora en una ceremonia que no necesitabas. La diferencia, en una tabla:

Usadas juntas se refuerzan: MoSCoW define qué construyes este trimestre; Eisenhower decide qué tocas esta mañana. El error es hacerlas competir por el mismo espacio.

Una sesión de priorización MoSCoW no necesita un facilitador certificado; necesita un tiempo cerrado y estas cinco paradas:

1. Volcar el backlog (10 min). Toda petición en una lista plana y visible, sin discutir todavía ni una sola. Si algo está mal redactado, se anota como está; reescribir viene después.
2. Votar solo los Must (15 min). Cada persona marca en silencio sus 3–5 imprescindibles y después se comparan. Solo se debate lo disputado; el resto se clasifica sin ceremonia. Este es el corazón de la sesión.
3. Fijar el presupuesto de capacidad (5 min). Regla práctica: los Must no deberían pasar del 60 % del esfuerzo disponible. Si el voto dice que el 90 % es Must, la sesión se ha equivocado y hay que repetir el paso anterior con más honestidad.
4. Rellenar Should y Could (10 min). Con el núcleo garantizado, el resto se ordena por valor y esfuerzo. Aquí entran las peticiones del jefe y del cliente que «no pueden esperar»: casi siempre acaban en Should.
5. Cerrar y publicar el Won't (5 min). Se escribe qué queda fuera de esta entrega y se comunica a quien pidió cada cosa. Sin este paso, la sesión no existió: los fuera quedan flotando como expectativas.

El resultado no es una lista bonita: es un acuerdo con fecha y con presupuesto. Si a la semana siguiente alguien suma alcance sin quitar nada, la sesión te da la base para negociar en lugar de improvisar.

MoSCoW falla siempre por los mismos tres sitios, y los tres se detectan en la primera sesión:

1. Todo es Must. Es la muerte canónica del método. Si el 90 % del backlog es imprescindible, nadie priorizó: se recicló una lista de deseos con otra tipografía. El antídoto es el presupuesto del 60 %: es negociable, pero alguien tiene que defenderlo en voz alta cuando se rompe.
2. Must mayor que la capacidad. Aunque la clasificación sea honesta, si el Must ya excede el tiempo y el equipo disponibles, firmaste un compromiso imposible el día uno. El antídoto es comparar el Must con la capacidad real antes de cerrar la sesión y bajar a Should lo que no quepa, ahí mismo, no en la semana seis.
3. Nunca revisar el Won't. Lo que era inútil en enero puede ser urgente en marzo; si el documento no se reabre, pierde autoridad y todos vuelven a pedir por chat. El antídoto es barato: diez minutos de revisión al inicio de cada release o de cada mes.

Hay una condición de fondo: la prioridad solo respeta si existe un límite de trabajo en curso que la haga visible. Sin él, el Must y el Could entran igual al tablero y la clasificación es un adorno. Si trabajas con flujo continuo en lugar de sprints, la combinación natural es priorizar la cola con MoSCoW y dejar que el tablero con límites WIP la consuma; el modelo completo está en ScrumBan.

El Won't have es la parte más incómoda y la más valiosa. Escribir lo que no vas a hacer hace tres cosas que ninguna herramienta hace sola: protege el alcance cuando aparecen las peticiones de mitad de proyecto, gestiona expectativas porque el cliente vio el «no» firmado antes de empezar, y convierte un rechazo en un aplazamiento, que se negocia mejor y se reabre con datos en la siguiente revisión.

Por eso el Won't se publica, no se archiva. Vive junto al alcance acordado, se lee en el arranque y se revisa en cada release. Un proyecto serio no se mide solo por lo que entrega, sino por lo que resiste a agregar sin discutirlo.

Si quieres sostener esta priorización en una herramienta que vive en tu carpeta —JSON local, sin cuenta, sin asientos, kanban con límites WIP y procesos documentados— Hito está pensado para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — prioriza el alcance y respeta el WIP en un tablero local-first, sin nube.