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:
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.