As the Product Backlog is the single source of requirements for any changes to be made to the product, managing the Product Backlog takes a lot of time. Learn how many items your Product Backlog should have to keep it manageable.
Having a single source of requirements for your product is a great idea because you don’t have to look elsewhere to find the requirements for your product. In your Product Backlog, you have user stories, technical tasks, bugs, features, epics, and all kinds of requirements you can imagine. It is fascinating how fast a backlog can grow. If you are not careful your backlog grow to 300+ items, which will keep your Development Team busy for 2-3 year.
Cleaning up a backlog with more than 300+ items will take a lot of time. The time you don’t have. In case you have to clean up your backlog, follow this step-by-step guide.
A backlog with more than 300 items is not manageable:
- It is really hard to find the item you want, even with an online tool like Jira.
- it is difficult to order the backlog by business value.
- It is impossible to identify dependencies and relationships between items.
So how many items should a Product Backlog have, to be able to find items, edit items, order items, and identify dependencies?
Why Your Product Backlog Needs a Limited Number of Items
Stakeholders can have a lot of power in a company and sometimes it is difficult for a Product Owner to assert oneself against the stakeholder. A limited number of entries of Product Backlog items support the Product Owner in dealing with stakeholders.
If a stakeholder insists on adding a new feature the Product Owner can ask the stakeholder which item from the backlog the stakeholder wants to remove.
Since an item is on the backlog, the customer/stakeholder expectations are that they will be implemented in the future. That’s their logical fallacy, but hard to debunk. A limitation of the Product Backlog is a quick win.
How Do You Determine the Maximum Number of Items
A well defined maximum number of items helps your Product Owner to argue with stakeholders. Consider the following conditions when determining the maximum number of items in your Product Backlog:
- Time frame
- Number of sprints in this time frame
- Number of average items completed in a sprint
Chose a time frame that is appropriate for your team’s situation. This could be
- the OKR cycle (3-4 months),
- Program Increment cadence (10-12 weeks), if you are using SAFe
- Release cycle.
I recommend a time frame of 3-6 months.
Formula:
Maximum number of items in Product Backlog = Number of sprints in the time frame * Average number of completed items per sprint
Let’s have a look at real-life examples:
Example With a 4-Month Time Frame
Time frame: 4 months
Number of sprints in this time frame: 8 sprints (2-week sprints: 4 months = 16 weeks = 8 sprints)
The average number of completed items per sprint: 7
Maximum number of items in Product Backlog = 8 * 7 = 56
You could round the number to 60. It is easier to remember. So your Product Backlog should not have more than 60 items.
Example With SAFe Program Increment
Time frame: SAFe Program Increment: 10 weeks
Number of sprints in this time frame: 5 sprints (2-week sprints: 10 weeks = 5 sprints)
The average number of completed items per sprint: 8
Maximum number of items in Product Backlog = 5 * 8 = 40
So your Product Backlog should not have more than 40 items.
Example With OKR Cycle
Time frame: OKR cycle 3 months
Number of sprints in this time frame: 6 sprints (2-week sprints: 3 months = 12 weeks = 6 sprints)
The average number of completed items per sprint: 8
Maximum number of items in Product Backlog = 6 * 8 = 48
You could round the number to 50. It is easier to remember. So your Product Backlog should not have more than 50 items.
Recap
Use the following steps to identify the maximum number of items in your Product Backlog:
- Set your time frame
- Identify the number of sprints during this time frame
- identify the average number of completed items per sprint
- Calculate: Maximum number of items in Product Backlog = Number of sprints in the time frame * Average number of completed items per sprint
- Optional: Round the number to a memorable number.
