The benefit of any prioritization model is that it allows us to quickly measure an investment against the alternatives, including “do nothing,” and assess it against the goals of the organization. Instead of just considering cost, an ideal prioritization method will produce a fast estimate of the return on our investment without the analytical overhead of having to monetize every aspect of every decision.
For years we’ve been using Business Value-Driven Prioritization, a framework we developed that provides a simple set of rules for evaluating the costs and benefits of initiatives relative to each other. We help teams define their key dimensions of value through hands-on workshops, standalone training, and as part of a learning journey designed to build Product-Oriented Engineer Teams, or POETs. We were asked recently by a team if there’s an article or whitepaper we could share about this practice, so we decided to put one together.
Scoring Business Value
Losing the sunk costs of an initiative that is displaced by a more compelling opportunity can be painful, so quickly scoring the value of an initiative earlier allows us to identify and prioritize the most effective work before we make any significant investments. That way, we can ensure that our resources are focused on the highest value items at the outset and we reduce the pain of having to cancel a project after we've spent a bunch of money on it, or worse yet, continue spending money on it even though we know it's a loser.
For most organizations, it’s clear that revenue counts more than anything else, and understanding your specific team's contribution to top line commitments is essential to driving alignment between teams, and within teams. There are several contributions a team might make to help driver revenue. We might capture new potential customers and move them down the acquisition funnel, strengthen retention, or grow existing customers. We might strengthen how the company is perceived in the eyes of customers, which increases loyalty and improves the likelihood that a customer will recommend us to someone else. Our ability to target specific customers at the right time with right message, understand the nuanced performance of our business quickly, and do it all at the lowest possible cost, all contribute to business performance. Each one of these dimensions of business value could appear in the formula we might create to calculate a total business value score. Here's an example of what that calculation might look like:
Potential increased revenue per month per user reached times the number of users reached
+
New User Acquisition
+
Customer Retention
+
Compliance (multiplied by 2 to reflect its outsized importance)
+
Operational Cost Reduction – Operational cost is the ongoing reduced cost that we gain from doing the work. Investments in automation, infrastructure, simplifying data models, upgrading or transitioning services to new platforms might all reduce the cost of future operations. We would include reductions in risk, monitoring, and cycle time that would result from these investments.
+
Agility (how quickly we can respond to new insights, such as a shortfall in revenue, competitive opportunity, or external event)
=
Business Value Score
Using the Fibonacci Scale
With such variety of topics and the need to assign an initial score quickly, the option of estimating against an absolute scale, such as dollars, time, number of people, sentiment, etc. is infeasible. What we need is a scale that allows some measure of accuracy without getting lost in needless precision. By the way, accurate, but imprecise would be saying that a bottle of water weighs about a pound. Precise but inaccurate would be to say that same bottle weighs 3,274.6 grams (that’s not even close).
The Fibonacci sequence serves this purpose well. It’s enjoyed a groundswell of adoption recently for estimating software effort and, for some reason, people find it fun. Named after a 13th century Italian mathematician, it is defined as a series of numbers where each number in the series is the sum of the prior two numbers. As the numbers grow, they get farther apart, which reduces their precision. Since we only use the numbers in the series, we avoid spending time trying to determine whether something is an 83 or an 84. Here is the first few numbers in the sequence:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233
In practice, it’s unusual to see numbers higher than 21. Larger numbers usually reflect uncertainty and risk and are therefore broken down into smaller tasks.
We see this same pattern in nature. In visual design and architecture it’s most commonly referred to as the golden ratio which is used to determine pleasing dimensional relationships.
Comparative vs. Absolute Estimation
Another important part of the methodology is that estimates using the Fibonacci numbers are comparative, not absolute. That means rather than predicting the number of gallons a jug (A) might hold, we compare it to another jug (B) with known capacity. If jug (A) the same as jug (B), it scores a 1. If it is bigger, then we assume it is at least twice as big and it might score a 2. If it is 3 times as big, then 3, etc. If it is smaller, then we might have to adjust our known jug to give it a higher number for comparison. For example, jug (A) might be 1 and jug (B) would be 2, 3 5, 8, etc..
Over time, we get a sense of the relative benefits of each request as compared to other requests in each dimension of business value. When we use Fibonacci numbers to create business value, we’ll sometimes refer to them as value points.
Effort
Fibonacci numbers are most commonly used to assess the effort related to a task, and the models works exactly the same way. When we use Fibonacci numbers to estimate the relative effort of a task, we call these numbers story points for scrum teams. This is because software teams have been using this approach to assess their work, which is typically organized into stories, which describe a user experience they want to create.
Prioritization Index
Divide the business value score by the effort in story points to get the prioritization index, essentially the relative ROI of each line item. If the prioritization scores don’t feel right, that may be a signal that we’re missing a dimension of business value that is not yet reflected in the model. If that happens, use the item as a way to surface what aspects of business value we missed and incorporate it into the framework.
Implementing Business Value-Driven Prioritization
As we continue to help teams adopt this framework, a few key things help organizations get the most out this work. Start with a small project with limited stakeholders and build the smallest core team possible. Include engineering leaders, product owners, product managers, and stakeholders to define the dimensions of business value. If they are not able to participate, test the dimensions with them and incorporate feedback. Only prioritize and score the top N most promising stories in the product backlog. Establish shared agreement that while the engineering team will consider the business prioritization, they (the engineering team) will ultimately decide which stories to pull into a sprint. Set regular checkpoints to revisit the dimensions and weighting of dimensions in the framework. As priorities shift, the ingredients we use to articulate value in the model should shift in alignment.
We’d love to hear about your experience using this approach. Let us know in the comments, or reach out directly to start a conversation.
Frequently Asked Questions
That sounds great, but I work in a complex organization, can we really let a spreadsheet decide our priorities for the quarter?
Probably, especially when you consider the alternatives. Decisions might be driven by the loudest or highest paid voice in the room. They might appear to grow from deep analysis. Or, they could grow out of long efforts to reach consensus. The idea behind this model is to surface our best instincts and put them out where everyone can see them. You can still inform the team's instincts using factors like executive direction or strategic alignment. Better yet, make a column and score them explicitly.
Why not just estimate effort right away?
Estimation is a costly activity. Using Fibonacci numbers to assign value and effort first lets us focus our planning and estimation efforts on the most important work first. If priorities change late in the process, we can change our focus without having wasted a lot of effort on estimating or planning work that is no longer a priority.
If Fibonacci numbers work so well, why bother creating hours-based estimates at all?
Some teams never create estimates or plans. They just continuously work on the most important tasks, going as fast as they can. Because they spend a minimal time in planning, that leaves more time actually getting work done. Many teams, however, work in environments that require coordination with other teams in order to meet business milestones, or need to make capacity trade-offs late in the process in response to new priorities. In this case, detailed planning happens at the start of each delivery cycle.
How will we know if are expecting more from a delivery team than they can accomplish for a given cycle if we don’t estimate hours?
Over time, delivery teams develop a history of delivering work. Looking back, we can see how many story points they usually deliver. Sometimes they deliver more, and sometimes less. This variation in delivery reflects errors in estimation and over time, most teams get better at this initial estimation. When the variation in story points delivered each period decreases for a given team, we consider that team to be “calibrated.” Changing the make-up of teams, the way they work, they tools they use, or the kind of work we ask them to do will require some time for them to re-calibrate.