Priorización Agile - Valor de Negocio, Riesgo, Coste. Tres variables dependientes.


Existen muchas técnicas que se enumeran para la correcta priorización de Product Backlog Items en Scrum. Principalmente se debería de priorizar en base al valor de negocio, riesgo, coste:

  1.  Valor de negocio.

  • En este punto se puede priorizar mediante la tĆ©cnica MOSCOW:

         - M (Must): Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un Ć©xito.

         - S (Should): Requisito de alta prioridad que en la medida de lo posible deberĆ­a ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podrĆ­a ser prescindible si hubiera alguna causa que lo justificara.

         - C (Could): Requisito deseable pero no necesario, se implementarĆ­a si hubiera posibilidades presupuestarias y temporales.

         - W (Won’t): Hace referencia a requisitos que estĆ”n descartados de momento pero que en un futuro podrĆ­an ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorĆ­as anteriores.

  •  TambiĆ©n tenemos la tĆ©cnica KANO:

           - Esenciales: Tiene que estar en el producto obligatoriamente.

           - Lineales: Funcionalidades complementarias, el valor de cliente aumenta en función de la implementación de dichas funcionalidades (de ahĆ­ su nombre).

           - Asombrosas: Mejoran la satisfacción del cliente en gran medida, aunque estas estĆ©n poco elaboradas o no sean muy completas.

  •  MĆ©todo de los 100 puntos: Repartimos 100 puntos en el backlog entre las personas responsables de priorizar, y ellos repartirĆ”n sus puntos (5-10 puntos en la funcionalidad), realizĆ”ndose una priorización automĆ”tica por orden de mĆ”s a menos puntos obtenidos por funcionalidad.

Existen muchas mƔs tƩcnicas para priorizar desde el valor de negocio, estas son solamente algunas de las mƔs utilizadas.

      2. Obtener e identificar los riesgos de cada funcionalidad:

  • Mediante el Definition of Ready (DoR) se identifican riesgos a tratar en cada Product Backlog Item.

  • El cuerpo de la historia o el propio Definition of Done (DoD) puede identificar riesgos tecnológicos.

  • Es conveniente realizar una matriz de dependencias entre historias, para identificar los riesgos, permitir repriorizar y crear planning o roadmap en base a dependencias que han de ser resueltas para poder continuar con otro Product Backlog Item. Las dependencias pueden ser:

  • Personas del equipo.

  • Dominio del problema.

  • Tecnológicas.

  • Software externo.

  • Externas (equipos, personas, departamentos, proveedores).

       3.- Coste de desarrollo: La estimación del equipo supone una estimación de esfuerzo, cuanto me lleva realizar esta funcionalidad, eso se convierte a un coste de desarrollo monetario cuantificable y por supuesto  impacta en mi priorización.

La causa por la cual se prioriza en base a valor de negocio, riesgos y coste es para que los items o Product Backlog Items mƔs altos en la pila sean los que suponen mayor valor de negocio con el menor riesgo y menor coste.

Sirve para identificar altos riesgos con gran valor de negocio y menor coste que si se deberƔn realizar tan pronto sea posible, y por el contrario mitigar los Product Backlog Items con gran valor de negocio, gran riesgo y gran coste.

Esta es una primera aproximación a la correcta priorización Agile, haciendo inca pié en que la priorización es un todo, basado en Valor de Negocio, Riesgos y Costes.

Para un correcto funcionamiento agile y mitigar el riesgo de problemas y fracasos han de tenerse en cuenta siempre las 3 variables, de lo contrario, ya no solo no estaremos siendo Ôgiles si no que estaremos nosotros mismos metiendo riesgos al proyecto y siendo autores de nuestra propia frustración.

Cada vez que identificamos un nuevo valor de negocio, un riesgo o un nuevo coste, esto incurre en una repriorización de dicha funcionalidad o del backlog impactado por dicho elemento.