How big should a backlog be?
However you look at it, that’s a good question. It’s also one of those questions in agile to which there isn’t a right or wrong answer, and you will have to come to an answer of your own.
A backlog that’s too big for one team may be one that’s too small for another and vice versa. And let’s not forget that the way that these two teams estimate their work may have nothing in common!
Sure, it would have been nice if I could say to you, “A backlog is too big when it’s this big,” and then move on, but we both know that the answer is a little more nuanced than that. So to help you figure that out, let’s take some time to understand what those nuances are.
Which Backlog Are We Talking About?
First and foremost, let’s define which backlog we’re talking about.
When you work with Kanban, you only have one backlog, the product backlog. Together with the rest of the members of your team, you pull work items from this backlog and move them from the leftmost column (“To Do”) to the middle (“In Progress”) all the way to the rightmost column (“Done”).
When you work with Scrum or Extreme Programming, you have two backlogs: the product backlog, the single source of work undertaken by the team, and the sprint backlog or iteration backlog, the subset of work items planned for the active sprint or iteration.
So when we talk about how big a backlog needs to be, we need to look at these two types of backlogs separately and individually (which is what we will do in the rest of the article, so I invite you to read on).
How Big Should the Product Backlog Be?
The size of the product backlog is a Goldilocks dilemma: it must be neither too large nor too small. Basically, it must be “just right” so that both decisions and delivery can flow without interruption, no matter what methodology and framework you use.
On the one hand, the product backlog must always have enough work items in a state that makes them ready to pick up by the members of the team. Otherwise, drafting and refining them can cause bottlenecks in the flow (Kanban) or planning (Scrum, Extreme Programming).
On the other hand, the product backlog must be as free of clutter as possible at all moments of time. If it isn’t, this clutter can cause waste in the form of wait time—and the resulting underutilization of talent and opportunity.
So the size of the backlog comes down to simple mathematics. Ask yourselves:
- At what rate is your team completing work items?
- How many ready-to-pick-up work items do you have in the backlog now?
- At what rate are ready-to-pick-up work items being added to the backlog?
Add the factor of time, and it will be easy for you to determine if you’re about to have one work item too few, or one too many. Then, a decision for the person(s) formulating and refining those work items should follow.
How Big Should the Sprint/Iteration Backlog Be?
If a handful of questions can spark a heated debate even among the friendliest of agilists, “How big should the sprint/iteration backlog be?” absolutely has to be one of them.
Remember, there is no right and wrong answer—and any decisions you make for the size of your team’s backlog are best taken with the context of your industry, organization, department, team, and stakeholders.
To cut a long story short, you don’t really know how big your sprint or iteration backlog should be. You can only make an educated guess, then inspect and adapt as you make progress, uncover novelties, and learn lessons during the iteration.
The key here is to use the KISS, a.k.a. “Keep It Simple, Stupid” method.
When predicting the future, the simplest methods tend to be the least inaccurate. Or, as Albert Einstein once put it, “No worthy problem is ever solved within the plane of its original conception.”
A really simple way to look at sprint or iteration planning, then, is this:
A sprint backlog should be about as big as the amount of work you were able to complete in the previous sprint, plus/minus (A) your team’s willingness to do more/less work and (B) its capacity in the sprint.
For example, if you estimate your work in story points and your team completed 20 story points in the last sprint, but it’s summer and you will have two fewer team members in the next sprint, you should probably plan for fewer than 20 story points.
(Sure, the remaining team members can always commit to doing more and try to make a push. But then you violate one of the fundamentals of the agile manifesto, which is that you should work toward a sustainable pace.)
In Conclusion
Generally speaking, you should make sure the product backlog has enough items that the team never runs out of work, but not so many that the backlog (and your collaboration on it) gets overwhelmed by clutter.
The sprint backlog should have about as many items as you and the team were able to complete in the last sprint while taking into account the willingness to do more/less and the capacity of the team to deliver.
