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.
