¿Qué es la técnica MoSCow?
El método MoSCoW es una técnica de priorización utilizada en la gestión, el análisis de negocio, la gestión de proyectos y el desarrollo de software para llegar a un entendimiento común con las partes interesadas sobre la importancia que dan a la entrega de cada requisito; también se conoce como priorización MoSCoW o análisis MoSCoW. La técnica de priorización MoSCow desempeña un papel fundamental en la gestión ágil de proyectos. En un proyecto ágil es vital comprender la importancia de las diferentes cosas. Esto se debe a que el tiempo es un recurso fijo, por lo que la priorización se aplica a los requisitos, tareas, productos, casos de usuario, etc. Ten mucho cuidado, esto no es una técnica ágil (incluye Scrum, Kanban, XP y demás) sin embargo esta técnica es muy utilizada en Agile. Hay algunas preguntas en casi todas las certificaciones con respecto a la técnica MoSCoW.
El término MoSCoW en sí mismo es un acrónimo derivado de la primera letra de cada una de las cuatro categorías de priorización (Must have, Should have, Could have, y Won’t have), con las Os intersticiales añadidas para hacer la palabra pronunciable. Aunque las Os suelen estar en minúsculas para indicar que no significan nada, también se utiliza el MOSCOW en mayúsculas.
Priorización de los requisitos MoSCoW
Todos los requisitos son importantes, pero se priorizan para ofrecer los mayores y más inmediatos beneficios para el negocio desde el principio. Los desarrolladores intentarán inicialmente entregar todos los requisitos Must have, Should have y Could have, pero los requisitos Should y Could serán los primeros en ser eliminados si el plazo de entrega parece amenazado.
Must Have
Estos proporcionan el subconjunto mínimo utilizable (MUS) de requisitos que el proyecto garantiza entregar. Esto puede ser definido usando algunos de los siguientes:
No se puede entregar en la fecha prevista sin esto
No tiene sentido entregar en la fecha prevista sin esto; si no se entregara, no tendría sentido desplegar la solución en la fecha prevista
No es legal sin esto
No es seguro sin esto
No se puede entregar el Caso de Negocio sin esto
Hágase la pregunta, «¿qué pasa si 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 Must Have. Si hay alguna forma de evitarlo, incluso si es una solución manual, entonces será un requisito «Debería tener» o «Podría tener». Degradar un requisito a un Debería Tener o Podría Tener no significa que no se vaya a entregar, simplemente que la entrega no está garantizada.
Debería Tener
Importante pero no vital
Puede ser doloroso dejarlo fuera, pero la solución sigue siendo viable
Puede necesitar algún tipo de solución, por ejemplo, la gestión de las expectativas, alguna ineficiencia, una solución existente, papeleo, etc.
Un Debería tener se puede diferenciar de un Podría tener revisando el grado de dolor causado por su incumplimiento, en términos de valor de negocio o número de personas afectadas.
Podría tener
Deseado o deseable pero menos importante
Menos impacto si se deja de lado (en comparación con un Debería tener)
No tendrá esta vez
Una ventaja del método MoSCoW es que coloca varias iniciativas en la categoría «no tendrá». Esto ayuda a gestionar las expectativas sobre lo que no se incluirá en una versión específica (o en otro marco temporal para el que se esté priorizando).
Colocar las iniciativas en la categoría «no tendré» es una forma de ayudar a prevenir el aumento del alcance. Si las iniciativas están en esta categoría, el equipo sabe que no deben ser una prioridad para este marco de tiempo específico. Algunas de las iniciativas del grupo de «no se tendrán» se priorizarán en el futuro, mientras que otras no es probable que se lleven a cabo. Algunos equipos deciden diferenciarlas creando una subcategoría dentro de este grupo.
Resumen
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) se utiliza principalmente para priorizar requisitos, aunque la técnica también es útil en muchas otras áreas. Atern recomienda que no se dedique más del 60% del esfuerzo a los requisitos imprescindibles de un proyecto, y el 40% a los requisitos necesarios y a los posibles. Todo lo que supere el 60% supone un riesgo para el éxito y la previsibilidad del proyecto, a menos que se comprenda bien el entorno, el equipo esté establecido y los riesgos externos sean mínimos.