By Christian Bisson
A key artifact for any successful team is a healthy backlog: a list of what’s needed to bring value to the project—written in a way the team can understand and ordered so the team is always focused on what brings the most value.
Yet between all the user stories, enabler stories, technical stories, bugs, defects and so on, it can be quite challenging for a product owner to order all of this properly.
Here are a few (ineffective) ways I’ve seen it done:
Pitfall 1: Prioritizing what’s understood
Product owners tend to be less technical, and not everyone can properly explain something technical in a way that conveys its value. The result is that items the product owner understands well are prioritized, leaving the other items on the side, which comes with a great long-term cost.
Pitfall 2: Going with instinct
I once heard the following about an item: Its value depends on how we feel that day. When people rely on pure gut feeling, the value of an item will vary depending on their emotions at the time. That means the decision of what will bring value to the product is more or less random, often resulting in leading the team to work on items that end up being pure waste.
Pitfall 3: Leaning into the noise
Some people even order their backlogs based on who complains the most! This merely encourages a culture in which whoever screams the loudest gets what they want.
So what works? There are many ways to take a more mathematical approach to giving value to items. What’s critical is to have an approach that allows the team to properly calculate the value of each item, regardless of what type of item it is. With clear guidelines, all three pitfalls can be avoided—and the decisions can be based on something more reliable.
How do you define the value of your backlog items?