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:
- 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.
- 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.
2. Obtener e identificar los riesgos de cada funcionalidad:
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.
- Valor de negocio.
- En este punto se puede priorizar mediante la técnica MOSCOW:
- 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:
- 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.
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.
Comentarios
Publicar un comentario