SCRUM: PO y Valor, nivel 2

¿Cómo medimos el valor trabajando bajo un marco ágil como scrum? y ¿cuán precisos somos midiendo valor? 

En la práctica estas preguntas se resuelven dependiendo del grado de madurez del equipo Scrum y de su PO. Tal vez, el primer nivel considera medir en forma relativa, subjetivo a la perspectiva del PO, sin una transparencia precisa (no se dan argumentos basados en datos ni se conoce el valor que aportan los entregables), priorizando sin técnicas precisas, etc.; y un segundo nivel puede ser como el que paso a contar seguidamente. 

Scrum y el valor

Primero que nada recordemos que, Scrum es una herramienta que puede ayudar a enfocarse a la entrega temprana de valor [1], a re-enfocarse en la rentabilidad de la inversión relacionada al desarrollo de features orientadas al valor aportado [4] y a disminuir el riesgo financiero asociado al valor de pérdida por un mal producto que tarda en salir al mercado y falla [7]. Aunque no es una herramienta que brinde el cómo hacer esto ni cuán precisa debe ser la medida de valor que se tenga en cuenta. Respecto a lo primero, scrum da un “qué” relacionado al valor, el objetivo de scrum es conseguir un MVP en manos de los futuros clientes o usuarios cuán rápido sea posible y obtener sus comentarios [2] o  feedback. Esto se hace para descubrir lo valioso para el cliente o usuario, validar el producto y encaminar el desarrollo en esa dirección, de ser factible el producto. Para ello se propone enfocarse en las features de valor. Ahora, el cómo se valoran las features o cómo se hace el trabajo de priorización de features de valor no es solución brindada por Scrum ni por el Manifiesto Ágil [3] -pues scrum solo da el contexto como marco de trabajo-.

ROI y técnicas de priorización de valor

Para priorizar trabajo por valor se usan técnicas, recomendaciones y prácticas complementarias cuya selección será subjetiva al equipo, organización que las implemente o seniority y skill del PO. Por ejemplo se pueden  recomendar, para buscar el MVP y focalizarse en el valor, algunas técnicas como: ley de Pareto 20/80 para priorizar [7],  priorización por KPI, estimación relativa de valor, técnicas de "cost of delay", priorización urgencia e importancia, medición técnica de satisfacción del usuario, ROI [5] y ROI Scorecard, NPV [5], IRR [5], EVM [8], etc.; y de estas, la más renombrada es el ROI, ya que el PO debe buscar lograr y maximizar un retorno de la inversión. La fórmula de ROI genérica es la siguiente:

Tipos de valor 

En cuanto a cuán precisa debe ser la medida de valor que se tenga en cuenta, también es ajeno al marco Scrum y al Manifiesto. Por un lado, hay que tener en cuenta (a) ¿el valor para quién? ¿para el usuario final o para el cliente negocio?... y por otro lado (b) ¿qué es específicamente el valor? (valor hipotético vs valor real)

¿El valor para quién?

En relación a los primero (a), en Scrum se recomienda definir esto al comienzo y luego nos enfocamos según los objetivos planteados que involucran al beneficiario del valor. Aquí puede ser el usuario final (“valor percibido por el usuario”) o la compañía cliente (“valor del negocio” [1]). Relacionado a esto último es que con scrum nos proponemos responder rápidamente la pregunta: ¿Ganaremos dinero con esto? [7] Aunque siempre se termina validando contra el usuario final en cuanto a “software funcionando”[3] (o producto funcionando) como valioso para el usuario.  Otra pregunta que el PO debe tener siempre en su mente es: "¿Qué es lo más valioso que podemos entregar bajo un costo y tiempo fijo?" (aquí el el costo y tiempo fijo es el equipo y el sprint)

¿Qué es específicamente el valor?

Con respecto a lo segundo (b), hay que partir de que el valor mismo siempre es subjetivo y no existe realmente un valor real concreto y empírico, aunque mientras más nos acerquemos a la realidad del mercado económico, será mejor. Siempre en un justo balance, ya que lo que sí recomienda el Manifiesto es “la adaptación” en vez de seguir un plan minucioso, o sea a no tener toda la información precisa y detallada -la económica por ejemplo- de antemano, desde el comienzo, sino más bien tolerar ciertos grados de incertidumbre -valores hipotético o cercanos al real- en pos de entregar software funcionando que el usuario percibe como valioso. O sea, pretender saber qué valor real en dólares tiene asociado cada entregable es poco válido dentro del agilismo y de scrum; y hasta cierto, punto es utópico. Como versa la frase: "No hay tal cosa como valor absoluto en este mundo. Sólo se puede estimar qué cosa es valiosa para ti" [4] (Charles Dudley Warner, 1829-1900). 

Tips para POs

Particularmente recomiendo, a equipos maduros y principalmente a POs más que juniors, las siguientes prácticas: 

1. El establecimiento de objetivos comunes entre todos los stakeholders (internas y externas) alineados al negocio [4] (Alineamiento con metas y KPI definidos). 
2. ROI mediante desarrollo de las features más importantes [4], según MVP y KPI definidos. 
3. La identificación de las features innecesarias o de bajo perfil para remoción del backlog durante la “priorización continua” [4], usando ley de Pareto 20/80 [7] u otra técnica de priorización. 
4. Motivar al equipo haciéndoles saber cuánto valor relativo de negocio están entregando por features o historia de usuario [4], se puede usar el Value Point como medida; o midiendo el impacto mediante el KPI propuesto. 
5. La reducción del riesgo mediante uso de MVP, MMP y release plan [6][7]. 
6. Medir la satisfacción del cliente para buscar su incremento [4] (NPS, CSAT, etc.). 
7. Respaldar con datos al “Business Case” u "Opportunity Assessment" y al release plan o Roadmap. 
8. Medición o estimaciones de KPI principales, como revenue, save cost y penetration. De lo cual se desprende el análisis de qué features aportan a la reducción de los costes, aumento de revenue y/o penetración en mercado. Justificar el “Business Case” u "Opportunity Assessment" y el valor aportado en las reviews. 

Hay que recordar que lo relacionado a valor es responsabilidad del PO y la calidad relacionada al mismo dependerá, en gran medida, de su seniority como PO. La excelencia es un principio en la agilidad, por lo que un buen PO debe procurar excelencia como analista del negocio y del valor del producto/servicio que el equipo entrega o brinda. Un trabajo de precisión ágil y excelencia requieren un PO de seniority alto que busca la excelencia. 

Referencias: 

[1] Scrum Alliance: Scrum Values. URL: https://www.scrumalliance.org/why-scrum/core-scrum-values-roles

[2] Book: Summary: Scrum - Jeff Sutherland: The Art of Doing Twice the Work in Half the time, by BusinessNews Publishing.

[3] Manifiesto por el Desarrollo Ágil de Software. URL: http://www.agilemanifesto.org/iso/es/

[4] Scrum Alliance: What Is Required for Business Value? Sumanth Reddy Bathula. URL: https://www.scrumalliance.org/community/articles/2016/april/what-is-required-for-business-value-(1)

[5] Scrum Alliance: Business Value Metrics. URL: https://www.scrumalliance.org/community/articles/2016/april/business-value-metrics

[6] Artículo: Desarrollo Ágil - Desarrollo mediante MVP. URL: http://programminglabpoint.blogspot.cl/2016/05/desarrollo-agil-mvp.html

[7] Book: Scrum The Art of Doing Twice The Work In Half the Time by Jeff Sutherland, 2014.

[8] Agile estimating and planning. Mike Cohn.

[9] Characteristic of a good product owner, Toqir Khalid, 2016. URL: https://blog.red-badger.com/blog/2016/04/20/characteristic-of-a-good-product-owner