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.
