The Churning Backlog AntiPattern

An estimated and prioritized backlog drives a reasonably dependable release plan. If you have an idea how long features will take to implement, you are able to project when major releases will be available to your clients. This relationship is natural and good. The rub problem lies in that some of the work in set B wasn’t in set C during the last iteration.

We know from Tracer Bullet Development that we should learn from our latest release and change the plan as we move forward to hone in on the perfect software. We also know that in 99% of the business world, we need to plan far beyond the end of our next 2-week iteration.

It becomes a natural balancing act to stay nimble with our iterative learning process and to stay true to the strategic vision of the product. The key to staying true to both masters is properly balancing your backlog.

Balancing the Backlog

Suppose the image on the right represents a feature backlog for a development team. 

• Set A is the set of all features in the backlog.
• Set B is the set of features currently prioritized at the top of the backlog and likely to make it into the next iteration (on deck).
• Set C is the set of features unlikely to make it into the next iteration (in the hole).

Now suppose you are a product owner an it is time to get ready for the next iteration. It is Thursday and the next iteration will begin on Monday of next week. As you organize set B in preparation for Sprint Planning on Monday, how much of set B should come from set C? How much of your set B for Monday should be new to set A altogether?

This is a roundabout way of getting to the issue of backlog churn. Backlog churn is like code churn in that it isn’t bad in and of itself, but it may be an indicator that something is amiss. The magic question is how much of the work going into the next iteration may be introduced on short notice. I propose 20%.

This means that as a product owner, you are doing a good job of getting your features right if you aren’t churning more than 20% of set B on Thursday afternoon as you prepare your backlog. More than 20% means that you likely are not doing a good job of understanding your customer in the first place.

Maybe you aren’t doing user testing on prototypes. Maybe you aren’t doing proper market analysis. Whatever the reason remember an iteration of a Scrum team is far more expensive than just the salary. The cost of failing to make progress on your strategic work in set C is huge for your organization. For more information on this phenomena, see The Innovator’s Dilemma.

The Bottom Line

Product Owner is a real job that takes discipline and expertise. For a good overview of what it takes to be an effective Product Owner, see the article Being an Effective Product Owner by Roman Pichler.

Agile does not mean no planning.

Iterative development does not mean no strategy.

Monitor backlog churn and use your head.