In an Agile context, defining value isn’t necessarily about calculating return on investment or measuring profit margins. Those things matter in the big picture, but they aren’t directly relevant to getting work done Sprint-to-Sprint. At the team level where work gets done, defining value must be understood incrementally, in terms that make the right decisions possible.
Three Kinds of Value
Breaking down value into three basic categories can make a huge difference in how an Agile team organizes the backlog to become more outcome-driven. These include:
- Positive Value
- Negative Value
- Feedback Value
This is what most of us think about when we think about value:
“If we build this feature, we can sell this service to more customers.”
Positive value also correlates with enhanced functionality:
“This feature will allow our customers to do things they haven’t been able to do before.”
Positive value can be anything that causes the customer to engage in additional dimensions:
- Creating a $20 game expansion that allows players access a new map or character class
- Expanding access from desktop to mobile
- Offering a localized version of your accounting software in French
I first learned this contradictory-sounding concept back in my early days in customer support. Negative Value represents the cost of inaction. In other words, by neglecting to do something, you lose value. So addressing Negative Value is a net positive. For example:
- If we don’t fix this bug, we will continue to get 100 calls a month with an average call resolution cost of $843.
- If we don’t make this compliance change, we’ll be fined $3000 per month.
- Game performance is way down and players are leaving the platform because they get tired of waiting.
Feedback Value is the least well known form of value in an Agile context. It leverages concepts from Lean Startup, Minimum Viable Product, and the First and Third Principle of the Agile Manifesto.
Feedback value is the ability to get feedback from the customer or user that will allow you to improve the product. It is this kind of value that can unlock a new Agile team’s ability to deliver in small iterations in an Inspect and Adapt cycle. For example:
- The Beta programs that were popular in the 90s and early 2000s are a classic example from waterfall methodology
- The multivariate testing that Amazon continuously conducts is a more modern example of Feedback Value
Estimating Value with Impact/Effort Prioritization
The ability to estimate value and to slice work into the right increments relies on the ability to understand what value is. I recently wrote about this in How to Incorporate Value into Agile Estimation, which introduces the concept of using relative estimation to calculate business value.
The principle behind relative estimation is that the exact number isn’t what matters. It doesn’t matter if my Ford pickup truck weighs 5000 pounds or 6000 pounds, I know it’s heavier than my wife’s minivan and a heck of a lot lighter than a city bus.
You extend this theory into value and instead of trying to decide if adding a chat bot will save you $25,000 or $40,000 you are asking if the chat bot is more or less valuable than improved search.
Going Deeper with Weighted Shortest Job First
You may want to consider Weighted Shortest Job First (WSJF) to expand how your organization thinks of value. The added dimensions around time criticality and risk/opportunity will provide even greater depth of understanding that will allow even better prioritization of work. Scaled Agile has incorporated WSJF into its SAFe methodology and you can read more on the practical use of it in our article on Features and WSJF.
New Tools to Fix an Old Problem
Figuring out what the value of future work might be has been a challenge as long as people have been building things that took longer than a couple of minutes. “Yeah, building this pyramid is probably going to take about 20 years. It’s going to be awesome though, trust me!”
Shifting to Agile development practices has allowed a faster realization of the potential value. And it’s still important to put value in a broader form of systems thinking. That’s why we’ve developed the Profit Engine Framework.
With these tools we hope you can better define that value ahead of time and allow you to focus on building the right things first.