¿Conoces MoSCoW?

“Para conseguir lo que quieres es indispensable dar un primer paso que consiste en decidir qué quieres”

Dentro del mundo de la gestión de proyectos, nos encontramos la mayoría de las veces con la necesidad de priorizar los proyectos a acometer, en función de los recursos y la capacidad de inversión prevista. Y sobretodo, dentro de un proyecto concreto, y una vez definido su alcance, tenemos la necesidad de priorizar los requerimientos de una forma ágil y sencilla, para poder cumplir con los requisitos de plazo y coste, que nos impone el “triángulo de hierro”.

Priorizar es complicado, y además hay que definir en función de qué priorizamos y cómo. Para responder al QUÉ tenemos que tener en cuenta el valor que aporta el requerimiento a la solución final, el coste de desarrollo asociado, la capacidad interna para acometer el reto y sobretodo la cantidad de riesgo que estamos dispuestos a asumir. Y para responder al CÓMO existen técnicas que se pueden aplicar para priorizar. Dentro del entorno de #scrumbok una de las habituales es MoSCoW.

MoSCoW es una de las técnicas de priorización más sencillas que existen. La idea de la técnica de MoSCoW se originó a partir de la metodología de DSDM (Dynamic Software Develop- ment Method).

MoSCoW significa:

  • Must have : Tiene que estar, es decir, son requerimientos imprescindibles que tienen que estar incluidos en la primera versión del MVP. Si no están contempladas en el prototipo el proyecto no puede salir adelante.
  • Should have: Debería estar si es posible, es decir, son requerimientos importantes y de gran valor, pero que no impiden poner el proyecto en marcha si no se tiene.
  • Could have: Podría estar si no afecta a nada más, es decir, son requerimientos que sería bueno tener y podrían incluirse porque no cuesta demasiado implementarlas. Pero que se dejan para una fase posterior para poder cumplir con los plazos del proyecto.
  • Won’t have: No estará esta vez, pero lo estará en un futuro, es decir, son requerimientos excluidos del alcance, porque no afectan a los procesos de validación, y se incluirán en fases más avanzadas del proyecto. En realidad son requerimientos importantes, pero que se pueden relegar en el tiempo.

moscow_jpg

Es una buena idea para asegurarse de que un proyecto tiene un buen número de historias de usuario “Im- portantes y “Buenas”, ya que ayuda a proporcionar al proyecto cierta flexibilidad si las cosas empiezan a to- mar más tiempo de lo esperado.

Si un proyecto sólo tiene tareas “imprescindibles”, el ámbito de aplicación no se puede variar. Por tanto, el coste y los plazos no debería fijarse sin incluir alguna tarea que se pueda excluir de manera razonable.

Es una buena práctica dentro del alcance de un proyecto, asegurarse de tener requerimientos importantes y buenos, que te permitan flexibilizar los plazos de desarrollo, cumpliendo con las validaciones de requerimientos imprescindibles.