Valor de Negocio vs Esfuerzo

Luego de una encuesta rápida ( https://plus.google.com/+LorenzoSolano/posts/U6ZSU5t22vA ), en la cual se preguntaba sobre la relación entre los Puntos de Historia y el Valor de Negocio, quise hablar un poco sobre este mal entendido.

Definiciones Rápidas (contexto: Agile, Scrum, Desarrollo de Software)

Valor de Negocio [Entregado]

Incremento en cierto aspecto de una organización, fruto de un cambio en algún producto de software. Ese aspecto puede ser una fuente de ingresos, mitigación de algún riesgo, etc.

En palabras simples, el valor de negocio entregado luego de una iteración / sprint es el incremento en la capacidad del negocio para generar más dinero o evitar ciertas perdidas (financieras, de reputación, etc.).

Puntos de Historia

Esfuerzo percibido, por un equipo de desarrollo, como necesario para construir cierta característica en un sistema de software.

Las ideas principales aquí son: percibido y un equipo de desarrollo [especifico]. Lo que esto significa es que el esfuerzo es una medida subjetiva, y que ese “sujeto” es un equipo de software en todo el universo. Usted no puede comparar un equipo a otro en términos de cuantos Puntos de Historia (esfuerzo) ellos le asignan a una característica a ser construida.

Los Puntos de Historia y el Valor de Negocio no tienen Relación

Escenario

Imagine dos equipos de desarrollo de software, a los cuales se les da la tarea de estimar cuanto esfuerzo requieren (no horas / tiempo, no dinero), para construir la Característica X. Ambos equipos tienen exactamente el mismo contexto (imaginario por supuesto): ellos pertenecen a la misma organización, responden a los mismos interesados, trabajan con las mismas tecnologías y herramientas.

Donde ellos difieren es en su nivel de experiencia. Así que, tenemos un Equipo de Principiantes y un Equipo de Expertos. Si usted les pregunta a los principiantes acerca del esfuerzo requerido para construir la Característica X, ellos responderán con un estimado mucho más alto que los expertos.

Desde el punto de vista del dueño del negocio, el valor agregado a la organización por la Característica X (luego de ser construida), es el mismo sin importar quienes lo construyan. El negocio solo quiere su nueva funcionalidad, no importa cuán difícil o fácil sea para los constructores lograrlo.

Utilizando un ejemplo menos abstracto; piense en que la cantidad de valor de negocio agregado por la Característica X, es un litro de agua fresca en el desierto. Imagine que su familia vive a una milla (1.6 KM) de distancia de la fuente de agua,

( fuente de agua: contenedor del "valor de negocio" )
Bayuda Desert Well by Clemens Schmillen CC. https://commons.wikimedia.org/wiki/File:BayudaDesertWell.jpg

y que usted necesita ese litro de agua para cocinar las comidas del día. Ese es su valor de negocio, usted necesita el agua no importa como la consiga.

Ahora viene el esfuerzo: si usted debe ir caminando y traer el agua a su casa, el esfuerzo requerido seria alto.

( esfuerzo requerido por el "Equipo de Principiantes" )
Desert walk https://www.flickr.com/photos/maartmeester/5130198174 by Maarten van Maanen @ Flickr.com

Pero, si usted utiliza un camello para ir y buscar el agua, entonces la tarea se vuelve más fácil.

( esfuerzo requerido por el "Equipo de Expertos" )
Camel at desert https://pixabay.com/en/camel-desert-sand-mongolia-692648/ by hbieser @ pixabay.com

Conclusiones

De esta comparación, inadecuada, me gustaría puntualizar algunas observaciones clave:

• No compare equipos utilizando su velocidad promedio (Puntos de Historia por Sprint)
• No asuma que un equipo entrega más valor de negocio porque ellos tienen una “velocidad” más alta que otro
• La velocidad de un equipo es solo para su uso
• Usted puede comparar la velocidad pasada a la actual, analizar tendencias y responder a cambios bruscos en ella (incrementos o decrementos) como indicador de que algo está pasando: nuevos miembros, rotación, cambios en infraestructura tecnologías, etc. Obviamente, la comparación será entre medidas presentes y futuras DEL MISMO EQUIPO.

Business Value vs Effort

After a quick poll ( https://plus.google.com/+LorenzoSolano/posts/U6ZSU5t22vA ), asking about the relation between Story Points and Business Value, I want talk about this misconception.

Quick Definitions (context: Agile, Scrum, Software Development)

[Delivered] Business Value

Increase on certain aspect of an organization, due to a change on some software product. That aspect could be a revenue stream, risk mitigation, etc.
In simple words, the delivered business value after an iteration / sprint is the increase on the business’s capacity to generate more money or to avoid certain losses (financial, reputational, etc.)

Story Points

The perceived amount of effort, for a development team, required to build certain feature into a software system.

The main concepts here are: perceived, and a [specific] development team. What this means is that the effort is subjective measurement, and that the “subject” is one software team in the entire universe. You cannot compare one team to another in terms of how much Story Points (effort) they assign to a given feature to be built.

Story Points and Business Value are Unrelated

Scenario

Image two software development teams given the task estimate how much effort (not hours / time, not money), they as a team, will require to build the Feature X. Both teams have the exact same context (imaginary of course): they belong to the same organization, respond to the same stakeholders, work with the same technology stack, and with the same tools.

Where they differ is in their seniority (experience) level. So, we have a Beginner’s Team and a Senior’s Team. If you ask the beginners about the effort required to build Feature X, they will respond with an estimate much larger than the seniors.

For the point of view of the business owner, the value added to the organization by the Feature X (after construction), is the same. They just want the new functionality, no matter how hard or easy is for the builders to do it.

In a, less abstract, example; think of the amount of business value added by the Feature X, as a litter of fresh water in the desert. Imagine that your family lives one mile away from the water well,

( water well: "business value" holder )
Bayuda Desert Well by Clemens Schmillen CC. https://commons.wikimedia.org/wiki/File:BayudaDesertWell.jpg

and that you need to get that litter of water to cook the day’s meals. That’s your business value, you just need the water no matter how you get it.

Now comes the effort: if you must go by foot and bring the water to your house the effort required will be high.

( effort required by the "Beginner's Team" )
Desert walk https://www.flickr.com/photos/maartmeester/5130198174 by Maarten van Maanen @ Flickr.com

But if you use a camel to go and get the water, the task becomes a little easy.

( effort required by less Expert's Team )
Camel at desert https://pixabay.com/en/camel-desert-sand-mongolia-692648/ by hbieser @ pixabay.com

Conclusions

From this, inadequate, comparison I want to point out some key takeaways:

• Do not compare teams per their average velocity (Story Points per Sprint)
• Do not assume that one team is delivering more business value because they have a higher “velocity” that another
• A team’s velocity is only for their usage
• You can compare past to actual velocity, analyze trends, and respond to abrupt changes on velocity (up or down) as an indicator that something is happening: new members, rotation, infrastructure / technology stack changes, etc. Obviously, the comparison will be between measurements of the SAME TEAM, past and present.

Ideas Locas

Imagina que los Dioses del Código te dieron una varita

mágica*. Esta impresionante herramienta te permite analizar, instantáneamente, una base de código y darle una puntación de 0 a 10 acerca de su mantenibilidad; donde cero (0) significa imposible de cambiar y diez (10) realmente fácil de cambiar.

De repente, recibes tres propuestas de consultorías de clientes distintos (A, B y C). Ellos te están requiriendo la implementación de nuevas funcionalidades en su producto principal. Utilizando tu varita mágica determinas que:

• El Producto A tiene un índice de mantenibilidad de 6,
• El Producto B tiene uno de 1.5, y
• El Producto C tiene un índice de mantenibilidad de 9

Tus clientes potenciales te aclaran que sus respectivos productos son de misión critica y que el impacto de introducir nuevos defectos podría ser catastrófico. Por tanto, ellos van a transferir ese riesgo a ti: cualquier defecto encontrado durante un periodo de validación de dos meses deberá ser resuelto lo antes posible y sin costo alguno.

Asumiendo una estrategia de precios X (basada en tiempo, basada en esfuerzo, etc.), ¿podríamos

• Cobrarle al Cliente C la tarifa regular?
• Cobrarle al Cliente A la tarifa regular ajustada (multiplicada) por algún factor basado en el riesgo (inversamente proporcional al índice de mantenibilidad)?
• Simplemente descartar el Cliente B y evitar el riesgo?

¿Me sigues?

• ¿Podríamos educar a nuestros clientes utilizando una estrategia de precios la cual refleje directamente el nivel de riesgo y esfuerzo que debamos asumir al trabajar con productos de software desordenados (baja mantenibilidad)?
• Con el tiempo, y algunas experiencias duras, ¿Estarán nuestros clientes más vigilantes acerca de la calidad de su base de código, y tal vez comiencen a requerir mayor calidad a todos los desarrolladores, tanto a lo interno como fuera de su organización?

* No esperes a los Dioses, puedes utilizar SonarQube, PMD, ReSharper, Checkstyle, y muchas otras.