I work with many teams that have extensive product backlogs. Each iteration has a backlog of more items than the team can typically finish. Worse, some organizations want many quarters' worth of backlogs, as in the image in this post.
There are several problems with long and extensive backlogs:
- They tend to be wishlists of features, not problems to solve. Worse, wishlists tend to be outputs, not customer-focused outcomes or intermediate steps to get to those outcomes.)
- Inevitably, something else that's much more important will arise. Too often, someone has to rejigger the entire backlog to accommodate that new information. That's called “where do we fit this in without removing anything else?” We play Tetris with both the roadmaps and backlogs.
- Any so-called prediction turns out to be unpredictable.
The result? We create WIP because the teams have to start considering work far off in the future. Worse, we wasted most of that time because things will change. That increases our Cost of Delay for work we have not yet finished.
Why do we do this? Everyone has a different reason. Let me start with the team.
Team Reasons for a Long Backlog
When I ask teams and team members why they want a long backlog, they say:
- The more we understand the final product and the features it needs, the easier it will be to architect and design that product.
- That understanding will help us estimate how much we can do and when.
- The more planning we do, the less risk and the less uncertainty we will have.
That's when I ask them to consider the last three times they created a backlog longer than a month. Using that information, did they ever have to rearchitect or redesign the product? Was their estimation accurate? Did they foresee their risks and create more certainty?
Every so often, a team can point to some up-front planning that informed the rest of their work. (Not in the last few years, but a couple of times before then. So it is possible.) But much more often, the teams realize that no, the upfront planning didn't inform their work.
Instead, it was the internal or customer deliveries where the team got feedback that informed their work.
However, the team reasons are all about managing technical or date risks. Teams can do that with either a combination lifecycle or an agile approach. (See Project Lifecycles for more information.)
But teams often feel pressure from their management to create a long and specific roadmap that is evidence of the team's planning. Even though planning cannot create certainty or predictability, too many managers think the plans will lead to certainty.
Don't blame the managers. They're reacting to pressure.
Management Reasons for a Long Backlog
Managers often tell me:
“I want to know when I can depend on the team delivering a specific piece of functionality.”
I would love that, too. For everyone I support with my consulting and coaching and for my own work.
As far as I can tell, everyone has big, audacious goals and plans they want to achieve. However, planning does not create certainty about delivery. And because the managers often want to know about far-off delivery, those plans are likely to change due to changes in product risks, product strategy, and organizational strategy.
If the team has a fairly regular cycle time, we can know this: That the team will deliver some outcome on a regular basis. (See How to Move from Story Points and Magical Thinking to Cycle Time for Decisions for cycle time series graphs.)
But unless the outcome is within a few days—maybe up to a few weeks—we cannot know when we will deliver a specific outcome. (See How to Predict When the Team Will Complete a Specific Backlog Item, Part 1 for my lunch analogy.)
Managers: No one has a crystal ball. The team cannot tell you when they will deliver something that's longer than a month away. (I'm not sure a month is within the predictability of most teams, either.)
However, managers can:
- Re-rank the order of the outcomes if they feel strongly about when they want the next outcome.
- Remove organizational delays. (See Why Minimize Management Decision Time and ask the team to create a value stream map as in Measure Cycle Time, Not Velocity to see what causes the various delays.)
- Make sure the team knows the overarching goal for this product.
Remember that people under external pressure don't work better. Instead, they tend to take shortcuts that lead to longer cycle times.
However, product leaders can create a smaller roadmap and keep small backlogs to satisfy management. That starts with removing the pressure from management and the team itself.
Product Leaders Can Release the Pressure
Too many product leaders feel the pressure of management's demands, too. That's why I wrote the Product Roadmap series. However, the product leader has many options for releasing the various pressures on the team:
- Explain the product strategy, starting with the big, overarching product goal. Then, choose the first outcome you want.
- Rank order the work. I still see supposedly agile teams that bucket their work into “High, medium, low” or some variety of that. That's prioritization, not rank ordering.
- Right-size stories so this team can complete a story inside of two days. I happen to like team collaboration with pairing, swarming, and mobbing. What matters is that the team can complete their work regularly, say a story inside of a couple of days.
But there's a huge problem with all this planning. We create too much WIP, which reduces our throughput.
Planning does not create reality. Instead, too often, planning creates the illusion of progress and prevents delivery. I'll address that in the next post.
This turned into a series: