¿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:
- El establecimiento de objetivos comunes entre todos los stakeholders (internas y externas) alineados al negocio [4] (Alineamiento con metas y KPI definidos).
- ROI mediante desarrollo de las features más importantes [4], según MVP y KPI definidos.
- 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.
- 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.
- La reducción del riesgo mediante uso de MVP, MMP y release plan [6][7].
- Medir la satisfacción del cliente para buscar su incremento [4] (NPS, CSAT, etc.).
- Respaldar con datos al “Business Case” u "Opportunity Assessment" y al release plan o Roadmap.
- 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
