Is your product backlog getting big?
It happens easily.
With no size constraints but the size of your hard drive, you can drop every hopeful idea into it, while discarding very few. (What if, after all, a particular backlog item could turn out to be an industry-altering one?)
More ideas mean more value for customers, right?
The opposite is true.
When it comes to your backlog, bigger isn’t necessarily better.
Once you reach the point when you have more ideas than manageable, the backlog begins to stifle innovation and stall productivity. Because there’s no way to differentiate the brilliant ideas from the bad ones.
When does a backlog become oversized? And how big is too big? Do you need to undertake remedial steps immediately? Or simply begin to monitor its size so you don’t reach the point of no return?
If you don’t know — if your gut alone doesn’t give you direction — here are a few methods for understanding whether your backlog is holding your product back from its potential. Keep in mind these are just rules of thumb, as every backlog is as unique as the team working on it.
Method 1: Backlog Items Per Quarter
For the sake of comparison (and knowing that each company, product owner, and team is different), what follows is a typical example of a maximum backlog size. Pushing far beyond this number may mean you’re hitting your threshold and should become more proactive about backlog management.
Let’s begin with the product owner, who is responsible to maintain a backlog for the next six to eight sprints. As for the team, let’s assume they are working in two-week sprints, and in the last couple of sprints they completed an average six to eight user stories. That means your maximum backlog should be seven stories times seven sprints, which equals 49 stories. That will take you 14 weeks (seven sprints times two weeks) to complete.
So, if you have substantially more than 50 stories in your backlog per quarter, identify this as an issue and make a root cause analysis as to why it is so big.
Method 2: Time Needed to Review Your Backlog
Another way to measure is to look at your backlog as an investment of time.
The formula below takes the measurement one step above the product owner role and looks at scaling teams. The result will help you understand whether or not to be more proactive about backlog refinement.
- Write down the number of product owners in the entire team of teams.
- Write down the size of your backlog.
- Divide the number of items in the backlog by the number of product owners.
- Multiply the resulting number by 5. (Each item in the backlog needs about 5 minutes of discussion for everyone to grasp it.)
- The resulting figure is the approximate time (in minutes) it will take for the teams to go through their backlogs.
Look at that number.
Given the availability of your team members and the demands of production, is such a time commitment remotely feasible? If the answer is “no”, then refining the backlog, with a focus on managing its size, should become a priority.
Method 3: Human Limitation of the Product Owner
Another option is to measure the backlog size per product owner. Since she is principally responsible for a backlog, her capacity to administer the information is often the true limitation. So, a backlog for a large product with ten product owners, each responsible for a different area, may be twice the size of a backlog for a product with five product owners.
General advice?
Use Dunbar’s number.
This number, arrived upon by anthropologist Richard Dunbar in the 1990s and based on the brain’s finite ability to maintain relationships, suggests that, because of the size of their neocortex, a human being can effectively maintain only 150 relationships at a time.
Given the contextual similarities (a product owner must manage relationships with interrelated backlog items), Dunbar’s number provides helpful guidance in this case as well. Therefore, estimate that a product owner should comfortably be able to maintain approximately 150 different items at any given time.
Need to Downsize Your Backlog? Download 6 Tips for a Leaner Product Backlog.