¿Qué es el método de priorización Must Should Could Won't?
Must Should Could Won't, más conocido como MoSCoW, clasifica el trabajo en cuatro grupos: lo que debes hacer, lo que deberías hacer, lo que podrías hacer si hay tiempo y lo que no harás esta vez. Usado como retrospectiva, consigue que el equipo acuerde en voz alta las prioridades del próximo sprint o release, con todos presentes. Dai Clegg desarrolló el método en Oracle en los años noventa, y se convirtió en una parte habitual de la gestión ágil de proyectos y del análisis de negocio, sobre todo en DSDM. Las categorías son Must have (imprescindible), Should have (importante), Could have (deseable) y Won't have (esta vez no). Encaja con las formas de trabajo ágiles porque pone primero el trabajo de mayor valor. Además, ofrece al product owner una forma estructurada de ver el backlog desde el punto de vista del cliente: si un cliente notaría su ausencia en el lanzamiento, probablemente sea un Must. La columna Won't aporta más de lo que parece. Dejar por escrito lo que habéis acordado no hacer evita que vuelva a colarse en el sprint y deja claro a los stakeholders qué no se va a entregar.
Formato Must Should Could Won't
Must
¿Qué tenemos que entregar pase lo que pase?
Son requisitos innegociables, críticos para el éxito. Al hablar de los elementos Must, anima a los participantes a pensar en verdaderos bloqueos o elementos esenciales sin los cuales el proyecto fracasaría. Pide al equipo que sea estricto con lo que cuenta como Must para evitar la inflación de prioridades.
Should
¿Qué es importante pero no crítico?
Son funcionalidades o requisitos importantes que aportan un valor considerable, pero que no son críticos para el lanzamiento. Guía al equipo para que piense en elementos que dolería dejar fuera, pero cuya ausencia no impediría que el proyecto funcione. Céntrate en lo que tiene mucho valor y menos urgencia.
Could
¿Qué estaría bien hacer si hay tiempo?
Son funcionalidades deseables que estaría bien tener si los recursos lo permiten. Ayuda al equipo a identificar mejoras que harían mejor la solución pero que no son esenciales. Estos elementos suelen ser buenos candidatos para futuras iteraciones o releases.
Won't
¿Qué acordamos no hacer esta vez?
Son elementos que el equipo decide explícitamente descartar en esta iteración o proyecto. Fomenta un debate sincero sobre funcionalidades que quizá valga la pena hacer, pero que no encajan con los objetivos o las limitaciones actuales. Ponerles nombre mantiene al equipo centrado y fija expectativas claras.
Cuándo utilizar este estudio retrospectivo
- Al planificar un nuevo proyecto o iniciativa en el que necesitas prioridades claras
- Durante el refinamiento del backlog, para ordenar y priorizar las peticiones de funcionalidades
- Cuando los recursos son escasos y hay que tomar decisiones difíciles sobre el alcance
- En reuniones con stakeholders, para fijar expectativas sobre qué se entregará y cuándo
Preguntas sugeridas para romper el hielo
- ¿Cuál ha sido la decisión de prioridades más difícil que has tenido que tomar en un proyecto?
- Si solo pudieras entregar tres funcionalidades en tu proyecto actual, ¿cuáles serían y por qué?
¿Le gustaría que su equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Eche un vistazo a los rompehielos gratuitos →
Ideas y consejos para su reunión retrospectiva
- Limita los elementos Must a un máximo de alrededor del 60 % del esfuerzo total, como recomienda DSDM, para que el plan tenga margen ante imprevistos
- Revisa las categorías a medida que cambian las necesidades del negocio y las limitaciones
- Pon un tiempo límite al debate de cada elemento para que una sola discusión no se coma la reunión
- Anota por qué cada elemento acabó donde acabó, para que el próximo debate no empiece de cero
- Implica a los stakeholders responsables de los requisitos para que las prioridades se mantengan
- Revisa las dependencias antes de colocar un elemento: un Could del que depende un Must es en realidad un Must