Cuando hablamos de la planeación y manejo de un proyecto es importante desarrollar un entendimiento muy claro de las prioridades y requerimientos de los clientes para que se realice de la mejor manera posible.

¿Cuál es el mejor método para hacer esto?
No sabemos, pero éste nos ha funcionado muy bien.


MoSCoW fue desarrollado por Dai Clegg de Oracle UK (Reino Unido) en 1994 y se hizo popular entre los exponentes del Método de Desarrollo de Sistemas Dinámicos (DSDM).

Es un acrónimo en inglés donde cada letra mayúscula representa una palabra. Las "o" minúsculas facilitan la pronunciación, y las mayúsculas sirven como preguntas para priorizar las acciones a hacer en cualquier proyecto.

Must have - Lo que debe de tener para satisfacer las necesidades del negocio.

  • Un mínimo producto viable.
  • No es legal sin eso.
  • No es seguro sin eso.
  • Para saber sí es un "must have" Haz la pregunta "¿qué pasaría sí no se cumple este requisito?" Si la respuesta es "cancelar el proyecto: no tiene sentido implementar una solución que no cumpla con este requisito", entonces es un requisito obligatorio.
  • Si hay alguna forma de evitarlo, incluso si se trata de una solución manual y dolorosa, entonces es un requisito "should have" o "could have".

Should have - Debería de tener esto si es posible, pero el éxito del proyecto no depende de él.

  • Importante pero no vital.
  • Algo que agregue valor comercial.
  • Puede ser doloroso omitirlo, pero la solución sigue siendo viable.
  • Puede necesitar algún tipo de solución, por ejemplo: gestión de expectativas, alguna ineficiencia, una solución existente, papeleo, etc. La solución puede ser solo temporal.

Could have - Podría tenerlo si se tiene tiempo.

  • Algo querido o deseable pero menos importante.
  • Cuando la fecha límite es un riesgo es la primera opción de eliminar.

Won't have this time - No se van a hacer en esa versión del proyecto.

  • Estos son requisitos que el equipo del proyecto ha acordado que no se entregarán (como parte de este marco de tiempo).
  • Se registran en la lista de requisitos priorizados donde ayudan a aclarar el alcance del proyecto.
  • Esto evita que sean reintroducidos informalmente en una fecha posterior.
  • Esto también ayuda a gestionar las expectativas de que algunos requisitos simplemente no se incorporarán a la solución implementada, al menos no en esta ocasión.