Ordering your backlog for maximum economic benefit is a hard problem. The average team is being pulled in several directions at once. New features requests, technical debt, existing defects, non-functional requirements, security, risk mitigation, resource shortages, and more are all competing for your team's attention. So, how does a rational team decide what to work on? In this post, I'm going to show you how to prioritize your product backlog by CD3, which is cost of delay divided by duration.
This post is part of a series on cost of delay. You can find the first post here.
What's the problem?
Have you ever noticed that scrum and agile writers have vague descriptions of how you should order your backlog? They write stuff like "work on the highest ROI stories first" or "the product owner should prioritize the backlog by customer value." That kind of advice sounds good when you read it but it's not going help you answer my next question.
If you only had the following three stories in your backlog, how should they be ordered?
- encrypting your users table and updating the security of your password hashes to the current best practice
- removing an unused feature from your code base that's adding to the complexity of some really important code
- automating the creation of a report for your sales manager
Which story is the highest priority? To whom? Your insurance company would probably pick story 1. You'd probably pick story 1 or 2. And your sales manager would probably pick story 3, right? So where do you go from here? See who can shout the loudest? Pull out your org chart and go with decision of the person who is closest to the top? Rank the stories by ROI (return on investment)? FIFO (First in, first out queue)? Ouija board?
You should prioritize your product backlog by CD3
The value of the stories in your backlog can span several orders of magnitude. And people have very poor intuition about the value of any given story. So, no amount of effort, skill, or talent is going to get you where you need to go if can't identify the highest value stories and get them to the top of your backlog.
There is no consensus on the Internet about how you should prioritize your product backlog. And I actually cringed as I read some really horrible advice in articles with very good search engine rankings. I looked at a couple of books too and they weren't much better.
It's impossible to compare the value of radically different stories because their values are expressed in incomparable units of measure. To get around this problem, you can convert everything to money using cost of delay. And then can divide the cost of delay by duration to calculate CD3. The higher the CD3 score, the higher the story should be in your backlog.
How to prioritize your product backlog by CD3
I'm going to show you how to calculate the qualitative cost of delay and CD3 for the three stories I wrote about above. Read this excellent article on qualitative cost of delay and come back here.
Okay, you're back. Did you read the article? If not, go read it now. What follows isn't going to make sense to you unless you read the article.
We can't do math on text labels so I assigned them integer values as follows:
I calculated the following cost of delay and CD3:
Let me explain what's happening here.
Encrypt users table and upgrade password hashes
I assigned this story a killer value (8). If we get hacked like Ashley Madison we will literally lose our business. So this is a very serious situation. However, getting hacked isn't guaranteed. I estimated that we have a 1/20 chance of being hacked so I divided 8 by 20 and get a value of 0.4. I ranked this story's urgency as ASAP (8) because it is very perishable; it will have no value after we've been hacked. I multiplied the value by the urgency to get a cost of delay of 3.2. And I estimated that it would take one week to complete the story. So CD3 = 3.2/1 = 3.2.
Automate the sales report creation
The sales manager has a member of her staff create the report by hand. It takes one hour per week. So automating this task would save about $40/week. This story isn't very valuable or urgent. We expect the cost of creating this report to remain fairly flat for the foreseeable future. I estimate that this report will take half a week to automate. So CD3 = 1/0.5 = 2.
Remove unneeded feature
This is a technical debt story. Removing this feature will help us reduce the complexity of important code in our project. And since complexity scales non-linearly, removing this feature should help us move faster in the future. But when I read the value and urgency descriptions, I have to admit that it is meh-level (1). And that that urgency is whenever (1). It's pretty difficult to remove code that runs through the heart of the system. So, I estimate that it will take two weeks to get it out of there. So we get a CD3 = 0.5.
Shifting the conversation
So how do you feel about these rankings? Do you want to argue that the risk of being hacked is 1/50, or 1/100? Fine. Do some planning poker with your team and come up with a more realistic value. Do you think that removing the unneeded feature duration estimate is too big? Okay, let's talk about it. If you don't like the 1, 3, 8 values for value and urgency, then change them to something more appropriate.
My point is that we're shifting the conversation from who's highest on the org chart or which story was in the backlog first to a framework where we can rationally break things down and try to figure out what's actually going on.
The benefits of being able to justify the order of your product backlog
I can easily imagine a situation where the sales manager starts to make arguments to try to get the report automation story to the top of the backlog. "The report is hard to create manually." Or "It's been in the backlog for 5 months and I'm losing my patience." Maybe she phones and emails you multiple times per week to say how much she needs this report automated.
If you have a cost of delay and CD3 calculation readily available you can defend yourself against these kinds of pressures. You show the sales manager your spreadsheet and that her story has a CD3 = 2. And she says, "You don't get it. My staff member made two mistakes in creating that report in the last year. One cost us $30,000 and the other one cost of $10,000. I don't want it automated to save time. I need it automated to prevent costly errors!"
Did you see that coming? A miscommunication led you to make a bad assumption. Would you care to recalculate the CD3 of that story and reorder the backlog?
Don't worry about the accuracy of your inputs
Don't worry about getting super accurate inputs into the framework. Reinertsen says our intuition about this stuff is so bad that any reasonable estimates will improve outcomes.
Duration
You want to know how many weeks (on the calendar) it will take to deliver each story. This is the sum of the actual time people spend working on the story and all the time the story is waiting in various queues. This is probably a departure from the way you normally measure effort but it's important in the context of calculating CD3.
Qualitative vs. quantitative cost of delay
When you are getting started qualitative cost of delay is easier for people to understand than quantitative cost of delay. But you should consider switching to quantitative cost of delay as soon as possible.
Qualitative CD3 can create distortions in your assessment of value and urgency that lead you to make suboptimal decisions about the order of the stories in your backlog.
Qualitative CD3 is a score and is only useful for ranking the stories in your backlog. On the other hand quantitative cost of delay and CD3 are rates. And they allow you to make economically optimal decisions about the cost of queues, staffing, and many other decisions that we usually make poor guesses at while we are developing software.
Don't make it more complicated than it needs to be
You can really go down the rabbit hole with this stuff but I don't recommend you do that unless the value clearly outweighs the cost.
It's totally common for the values of your inputs to change based on how you order your stories because the stories are interdependent.
For example, if you put a bunch of technical debt repayment stories at the top of your backlog, the duration of many of the other stories below them in the backlog should decrease. Conversely, if you add a big new feature to a certain part of your application, you might increase the complexity enough to make another feature in that same area much more difficult to implement.
Value and urgency can change over time as well.
Practical advice
Step 1: Ensure all the stories anywhere near the top of your backlog won't result in worthless software or waste.
Step 2: Rank the stories with quantitative or qualitative CD3. Since the value of your stories typically span several orders of magnitude, it shouldn't be hard for you to identify the really high value work. As long as you update your variables and recalculate your CD3 periodically (depending on how fast your variables are changing), this ranking should be good enough for the vast majority of projects.
Step 3: (rarely needed) Consider interactions between variables to fine tune the order of your backlog.
Wrapping up
You can't be effective if you are working on unimportant things. Experience shows that our intuition about which stories are the most economically valuable is shockingly poor. But you can use CD3 to create a rational basis for the ordering of your product backlog. It helps you shift the conversation from opinions and seniority to value, urgency, and hidden assumptions.
Cost of delay isn't just about prioritizing your backlog. I’ll expand on these ideas and show you more complicated examples in follow-up posts. Stay tuned.
Additional resources
You might find the following cost of delay resources helpful:
- excellent website with a great three minute explainer video
- book: "The Principles of Product Development Flow: Second Generation Lean Product Development" (Donald Reinertsen) Chapter 2
- book: "Essential Scrum: A Practical Guide to the Most Popular Agile Process" (Kenneth S. Rubin) Chapter 16
- video of a talk by Donald Reinertsen on product development
Top comments (0)