¿Cómo priorizar la pila de producto de forma cualitativa y que cada valor tenga un significado intrínseco?

Tablero con elementos priorizados por MoSCoW
cortesía foto de Christina Morillo en Pexels

Aunque todas las historias de usuario puedan ser importantes, para poder focalizarnos en el trabajo de forma eficiente, es necesario destacar aquellas que den mayor valor al sistema, por tanto, las historias de usuario deben de estar priorizadas. Estas deben de tener asignadas un valor que intervenga en el sistema de priorización, un valor asignado por el Propietario del Producto y que se debe de basa básicamente en las siguientes variables:

• Valor de negocio; beneficios al implementar una funcionalidad y coherencia con los intereses del negocio
• Criticidad en el tiempo; pérdida o coste que demande posponer la implementación de la misma
• Reducción de riesgos que implica implementarla
• Valor de oportunidad; valor diferencial con respecto a productos de la competencia

Uno de los aspectos a tener en cuenta es que la definición de "valor" puede variar para cada uno de nuestros clientes. Más allá de un sistema de clasificación de tipo prioridad alta, media o baja es muy recomendable utilizar algún tipo de escala cualitativa, una que tenga un significado intrínseco. Este es el caso de la técnica MoSCoW, en la que el usuario responsable de asignar la prioridad es consciente del efecto real que producirá su elección. Esta técnica fue definida por primera vez en el año 2004 por Dai Clegg de Oracle UK Consulting en el libro "Case Method Fast-Track: A RAD Approach". Su finalidad es obtener un entendimiento común entre cliente y el equipo del proyecto, en concreto sobre la importancia de cada historia de usuario. La clasificación es la siguiente:

• M - MUST HAVE (es necesario): Se debe tener la funcionalidad implementada en la solución, sino esta fallará o la solución no puede ser considerada un éxito.
• S - SHOULD HAVE (es recomendable): Se debería tener la funcionalidad implementada en la solución ya que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si no existe pero debería de haber causas justificadas para no implementarla.
• C - COULD HAVE (podría implementarse): Es deseable, por tanto sería conveniente tener esta funcionalidad implementada en la solución, dependerá de las posibilidades de los tiempos y el presupuesto del proyecto.
• W - WON'T HAVE (no lo queremos... quizá en un futuro): Se trata de una funcionalidad de muy baja prioridad o descartada en ese momento, pero que en futuro pueda ser relevante. Posteriormente, cuando cobre importancia, puede pasar a alguno de los estados anteriores.

Es importante distinguir entre prioridad y valor para el cliente. Puede ser que una historia de usuario no tenga ningún valor para el cliente o usuario, pero que esta sea absolutamente necesaria, por tanto de alta prioridad. Por ejemplo la infraestructura necesaria para la implementación de un software, no aporta valor al cliente en sí, pero sin ella no se puede desarrollar ni ejecutar la solución desarrollada.