Must

¿Qué tenemos que entregar pase lo que pase?

Implementar las funciones de seguridad básicas para proteger los datos de los usuarios
Cumplir los requisitos normativos antes del lanzamiento
Corregir los bugs críticos que afectan a los flujos principales de los usuarios
Should

¿Qué es importante pero no crítico?

Implementar una búsqueda avanzada
Añadir mejoras de rendimiento
Crear la documentación completa para usuarios
Could

¿Qué estaría bien hacer si hay tiempo?

Añadir la opción de modo oscuro
Dar soporte a más idiomas
Crear una versión de app móvil
Won't

¿Qué acordamos no hacer esta vez?

Integrar blockchain en esta fase
Dar soporte a versiones antiguas de navegadores
Desarrollar soluciones de hardware a medida

¿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

Preguntas frecuentes

¿Qué es el método MoSCoW?
MoSCoW es una técnica de priorización que clasifica el trabajo en cuatro categorías: Must have, Should have, Could have y Won't have this time. Dai Clegg la desarrolló en Oracle en los años noventa y se usa mucho en entornos ágiles y en análisis de negocio.
¿Qué significan Must, Should, Could y Won't?
Must es lo esencial e innegociable. Should es importante pero no crítico, Could es deseable si hay tiempo y Won't es lo que se acuerda dejar fuera del alcance por ahora.
¿Cómo se hace una retrospectiva MoSCoW?
Haced una lista de los posibles elementos de trabajo y luego comentad cada uno en equipo y colocadlo en la columna Must, Should, Could o Won't. Cuestionad cada Must y poneos de acuerdo sobre cada elemento antes de pasar al siguiente.
¿Por qué se llama MoSCoW?
Las mayúsculas corresponden a Must, Should, Could y Won't. Las dos oes solo están ahí para que el acrónimo se pueda pronunciar.
¿Cuántos elementos deberían ser Must?
DSDM, el marco ágil que popularizó MoSCoW, recomienda que los Must no superen aproximadamente el 60 % del esfuerzo. Si casi todo es Must, el equipo no ha priorizado de verdad.
¿Está listo para llevar a cabo esta retrospectiva?Pruebe esta retransmisión en directo retrospectiva