Método MoSCoW: cómo priorizar requisitos después de una reunión
Aplique MoSCoW a los requisitos de una conversación: Must, Should, Could y Won’t para el periodo actual. Con un ejemplo, preguntas para el equipo y una plantilla de decisión.
La prioridad depende del objetivo y del periodo
En la reunión, cada persona calificó su función de obligatoria. Esa lista no sirve para fijar el alcance. Acuerde primero qué resultado debe dar la próxima versión y qué la haría inutilizable. Para otra fase, las prioridades pueden ser totalmente distintas.
MoSCoW tiene cuatro categorías: Must Have, Should Have, Could Have y Won’t Have this time. La última excluye deliberadamente un requisito durante el periodo en cuestión. No promete que se hará más adelante ni descarta para siempre la idea.
Hable de las consecuencias de excluir requisitos
Describa el objetivo de la versión
Anote quién la usará, para qué tarea y en qué condiciones. Aclare las restricciones y el horizonte de planificación. Si el objetivo se limita a «mejorar el producto», se aplicarán criterios distintos y casi todo parecerá obligatorio.
Evalúe los candidatos a Must
Pregunte en cada caso si el resultado seguiría siendo utilizable sin el requisito. Considere soluciones alternativas aceptables y dependencias. Un requisito obligatorio necesita un motivo concreto. «Lo pidió el responsable» identifica el origen, pero no explica qué pasaría si se omite.
Distinga lo importante de lo deseable
Un Should es importante: sin él, el resultado es claramente peor, pero sigue siendo utilizable. Un Could es una mejora útil de la que es más fácil prescindir. Explique la diferencia mediante el caso de uso y el costo de la omisión, más allá de frases como «hace mucha falta».
Acuerde las exclusiones y cuándo revisarlas
Para un Won’t en este periodo, registre el motivo y la condición para reabrir el debate. Compruebe las dependencias y si el alcance elegido es viable. Si el trabajo obligatorio supera la capacidad disponible, revise el alcance o el plan. Cambiar la etiqueta no resuelve la falta de recursos.
Primera versión de un formulario de inscripción en un evento
El siguiente ejemplo didáctico es ficticio. Los nombres, las condiciones y los resultados solo sirven para explicar el método.
Tenemos que aceptar una solicitud y confirmar el cupo. Estaría bien poder elegir el color del gafete, pero el evento se puede celebrar sin eso. Por ahora no nos da tiempo a hablar de un cuenta personal.
En este ejemplo, el objetivo es inscribir a la persona y darle una confirmación clara. Poder enviar una solicitud es Must porque sin ello desaparece el proceso principal. Un recordatorio puede ser Should si el equipo puede usar temporalmente una alternativa acordada.
El color del gafete puede ser Could y el cuenta personal puede quedar fuera por ahora. La clasificación es propia de este ejemplo. En otro evento o para otro público, las consecuencias serían distintas.
| Requisito | Categoría | Justificación |
|---|---|---|
| Enviar una solicitud | Must | Sin ella desaparece el proceso principal |
| Recibir un recordatorio | Should | Importante, con alternativa temporal |
| Elegir el color del gafete | Could | La inscripción funciona sin ello |
| Área personal | Won’t por ahora | Fuera del alcance acordado |
Ficha de justificación de la prioridad
Guarde la justificación junto a la categoría. Así podrá volver a la decisión cuando cambien las condiciones.
Versión / periodo / objetivo: Requisito: Caso de uso: Qué ocurre sin el requisito: Alternativa aceptable, si la hay: Dependencias: Categoría MoSCoW: Justificación: Quién confirmó la decisión: Condición para revisarla: Exclusiones de este periodo:
Compruebe que la lista ayuda a elegir
- El objetivo y el periodo figuran junto a las categorías.
- Para cada Must se describe qué pasa si se excluye.
- Se ha evaluado expresamente la alternativa temporal.
- Won’t por ahora se entiende como una exclusión del periodo actual.
Veamos los detalles
¿Puede un requisito cambiar de categoría?
Sí, si cambia el objetivo, el periodo o una dependencia, o si aparecen datos nuevos. Registre el motivo y acuerde el impacto sobre el alcance antes de moverlo.
¿Qué hacer si todos los requisitos son Must?
Pida que expliquen qué hace inutilizable el resultado sin cada requisito, examine las alternativas y acote el objetivo. Si el alcance obligatorio sigue siendo excesivo, revise el plan.