I recently gave a webinar about . There are a number of ways to do this, some of which I’ve discussed before, but there are big questions we need to answer related to business value. How can we measure business value? Individual user stories convey some information about business value, but what should we be looking to really determine the value a team or team of teams is delivering?
What Is Business Value?
We often look at a form of business value from the user story perspective. In the prototypical user story, we use the format seen to the left.
The business value of a story gives the team context for why they’re doing the work. But it doesn’t really tell us whether there’s any particular return on investment (ROI) that we will achieve from that work. And there may be opportunities that are made available from doing that work. And it may reduce our risk in some areas.
In a broader sense, though, business value is something that matters to our businesses and enterprises. When we consider business cases for creating a product, we examine very large chunks of work. Delivering a user story may not have a substantial level of visibility for our business owners.
What Are Our Choices?
If user stories are too low-level, we need to look at larger chunks of functionality to measure business value. As an example, the (SAFe) does this during PI Planning. We ask our business stakeholders to estimate the value of a team’s objectives for the program increment (or PI). Each team converts the features and stories for the PI into plain language objectives. The business then rates those on a scale of one to ten with one being the least valuable and ten being the most valuable.
After we finish the PI, the business owners then rate how much of the original estimated value was actually delivered. We can use some metrics to determine how well we’re performing as a team and as a team of teams (in SAFe parlance, an Agile Release Train or ART). If for some reason, we deliver very little value versus what was estimated, we can examine the reasons behind that and make adjustments in future sprints and PIs. And we can track our performance over time through a predictability chart (shown right). You can read more about how SAFe does this .
Closing Thoughts
Measuring team performance isn’t quite as straightforward as we’d like to think. And measuring business value is far more complicated than measuring team performance. It’s important that we consider this principle from the :
Business people and developers must work together daily throughout the project.
It’s only by working together and focusing on those items that have the most value to the business, both at the story level and higher, that we can deliver what our business needs. SAFe doesn’t provide the only technique for doing this, but it is a good starting point. I’ll be writing more on this topic in the future as it is a critical component that is very poorly understood, even by longtime agilists.
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)