Because the first principle of the Agile Manifesto talks about delivering valuable software to the customer, many agile practitioners are constantly thoughtful of the value in each step of the software-development lifecycle.
At the thirty-thousand-foot level, value creation starts with gathering requirements and continues with backlog creation, backlog grooming, writing user stories, and development, finally ending with integration, deployment, and support. Even with knowledge of all these moving parts, it is common to see organizations only measuring value during development and ignoring the rest of the steps.
What’s the fix? During backlog creation, user stories need to be compared and contrasted in order to promote maximum value delivery. The product owner might need to use different techniques, such as T-shirt sizing, in order to better prioritize the project’s stories.
An alternate approach to measuring the business value of user stories is to use a three-dimensional metric that incorporates complexity, business value, and the ROI. Creating value can often require a change in perspective from the normal project’s tasks and functions. Thinking outside the box, identifying business value before writing the user stories is much better than writing and then trying to evaluate.
Even with a push to measure the value of all moving parts, there are some who don’t quite see the value in the way many people are measuring the business value of user stories. Mike Cohn at Mountain Goat Software has found some loopholes in the concept and recommends measuring at the epic and theme levels.
However, I feel that assigning a dollar value delivered at the end of each sprint creates a false optimism, and as Mike suggests in his post, manufacturing one wheel does not add value until it is integrated and sold with the rest of the car.
But building software that could deliver future value to the customer is not so easy. There are several ways to measure that value.
Not only is there no standard formula for measuring value, but a clear view of what “value” means to the stakeholders needs to be articulated in the beginning. “Value” can differ from one product to another, so don’t expect a one-size-fits-all approach. Lastly, keep in mind that measuring the dollar value at the user story or sprint level can create a misperception about the value being created in your agile project.
Venkatesh Krishnamurthy is an author, speaker and a coach. In his 15+ years of career in the software industry, he has played different roles as a developer, architect and an Agile coach.