As a Product Owner, you need to understand the optimal size for your backlog. Otherwise you cannot manage it effectively.
Unfortunately, most product backlogs are far too large, causing all kinds of stress and chaos for unsuspecting Product Owners. Avoid their fate. Read on and learn how to determine if your backlog is of the right size.
Because If you do know your optimal size, you can not only approve the right items into the backlog: but you can also confidently guide the cleaning, screening, and refinement activities.
As a result, your team will deliver more value, and your life will be a whole lot easier.
How large a backlog should be
In terms of the number of items, a rule of thumb says it should be between 50 and 150 items.
Then there is a rule about the calendar time it should take for the team to deliver everything on the backlog. Here your should aim for between two and six months of work.
Of course, these are general rules. You may face situations and environments that dictate either longer or shorter backlogs.
Your backlog should not be the only place for work
Product Owners often try to keep all work in one single place: the backlog. This is totally wrong.
The backlog should only contain high-commitment work. When it comes to lower-commitment work — such as ideas and unapproved requests — you keep in other places, such as roadmaps or wishlists:
- Wishlists can contain work that is interesting but requires study or further signals before it can be approved for the backlog.
- Roadmaps can map the product journey further into the future, up to several years.
If all this work is added to the backlog, it confuses the team and the stakeholders. The backlog should remain a short, prioritized list of high-commitment work. When you as a Product Owner keep the lower-commitment work in other places, it becomes easier to manage the size of the true backlog.
Signals that tell if your backlog is too large
An easy way to detect a too-large backlog is item count. The optimal backlog size usually is below 150 items. If it grows beyond this, to 200, 300, or 400 items, the backlog is too large.
Similar signals can be found in the calendar time. If you estimate that it will take more than half a year for the team to finish all work on the backlog, the backlog is too large.
Another signal you want to look out for is when your team is reluctant to scan through the backlog. When the backlog is of the right size, it is not too difficult to get them to do it.
But if it is far too big, the team is not motivated to scan through it. They instinctively know:
- it is going to take far too long
- they will sift through items that they know will never get done
- some items are so far into the future, that more important items will almost certainly be discovered before they ever get to these items
Signals that tell if your backlog is too small
Having a too-small backlog is not as common a problem as having a too-large one, but it can be a problem.
For example, if your team is starting to build a product, your backlog may be almost nonexistent. The problem then is: While you build the product and architecture, how do you grow the backlog in a manner that engages the stakeholders, continues to gather feedback, and evolves the product concept?
One signal to look out for is: the backlog is both small in terms of item count and at the same time not changing over time. A small item count by itself is not a good signal, but if at the same time, the items do not change, it is a clear signal that the backlog is not functional.
There can be several root causes for this. For example:
- The team may start work that is not on the backlog
- The Product Owner may not engage with customers and other stakeholders enough
How to maintain a backlog of the optimal size
To keep the backlog near the optimal size, you need to ensure the inflow of new items matches the outflow of completed items.
However, herein lies a common pitfall:
As a Product Owner, you need to be aware of the velocity, but if you try to exactly match the approval speed to the implementation velocity, you will almost certainly fail. You would need all backlog requests to always be of similar value and importance. And that is not generally the case.
It is better to set up regular maintenance and cleaning of items that need to be removed from the backlog. And this should be done together with the team.
A good approach for this is the Scan-and-plan practice that I describe in detail in this blog post. The Scan-and-plan practice takes place in one of the regular weekly backlog refinement sessions where — in addition to refining items on the top of the backlog — the team also scans through the rest of the backlog to clean and reprioritize the items. Scan-and-plan is therefore a regular monthly activity.
On a higher level, most organizations have some form of longer-term planning practices set up. These can resemble or follow SAFe Product Increment planning. These kinds of planning sessions can take place every 2-3 months. In addition to planning the things that will be done, the sessions are also opportunities to clean the backlog of items that will not get done. You may also consider Scan-and-plan approach here, too.
The four R’s method
In Scan-and-plan sessions, you can use the four R’s method for this cleaning and upkeep work. In this method, the backlog items are reviewed in reverse priority order, or in age order from oldest to newest.
The four R’s of this method are:
- Remove
- Reprioritize
- Reinvent
- Reduce
Remove simply means that you decide “this backlog item does not belong to the backlog”. In this case, move it to the suitable workflow state (rejected, postponed, or similar). It is better to keep the backlog item instead of deleting it, but change its state to clearly indicate that it will not get done. When you do this, do not forget to communicate the rejection to the originator and interested stakeholders.
If you are not going to remove the item, then you must either change it or reprioritize it. Reinvent and reduce both mean changing the item. Reinvent means going back to the original problem and rethinking the approach. Reduce means making the item simpler.
The right backlog size makes for a happy team that generates value
When the backlog is at optimal size, your team can trust that they are always working on the most important thing. This also motivates them to refine the backlog and help the Product Owner maintain the backlog.
This means it is on you as a Product Owner, to know what is the right backlog size for your product, your team(s), and your environment.
Published: February 13, 2023
