How to keep your product backlog the perfect size for your team

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 big, causing all kinds of stress and chaos for unsuspecting Product Owners. Avoid this fate. Read on and learn how to determine if your backlog is the right size.

If you do know your optimal size, you can not only approve the right items into the backlog, but you can also confidently guide 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 is that it should be between 50 and 150 items. Even here, smaller is better. If you are closer to 150, try to remove items from the backlog.

There is also a rule about the calendar time it should take for the team to deliver everything in the backlog. Here, you 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. Lower-commitment work (ideas and unapproved requests) can be kept 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 the Product Owner, keep the lower-commitment work in other places, it becomes easier to manage the size of the true backlog.

Signals that suggest your backlog is too big

An easy way to detect an oversized backlog is an item count. Backlogs should stay below 150 items. If it grows beyond this to 200, 300, or 400, then the backlog is way too big.

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 in the backlog, then it’s too big.

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’s not as difficult to get them to do it. But if it is too big, the team will  not be motivated to scan through it because they know:

• It will take too much of their time.
• They will sift through items they know will never get done.
• Some items are so far into the future that more important ones will almost certainly be discovered first.

Note that while staying under 150 is good, you should still aim for an even smaller backlog. You and your team spend more time managing the backlog when it is 150 items long than when it is 50. Getting to 50 items is tough, maybe even impossible, but trying to keep it small will make you more focused.

Signals that tell if your backlog is too small

Having a backlog that’s too small is not as common as one that’s too large, but it can be a problem.

For example, if your team is starting to build a product, your backlog may be almost non-existent. 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 that the backlog is small in terms of item count and doesn’t change over time. A small item count by itself is not a good signal, but if, at the same time, items do not change, it is a clear signal that the backlog isn’t functional.

There can be several root causes for this:

• The team may start work that’s not in 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 at the optimal size, you need to ensure the inflow of new items matches the outflow of completed ones. 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’s not generally the case. 

It’s better to set up regular maintenance and cleaning of items to be removed from the backlog, which should be done together with the team.

A good approach for this is the ”scan-and-plan” practice that I describe in this blog post. In one of the regular weekly backlog refinement sessions, in addition to refining items on the top of the backlog, the team also scans through the rest of it to clean and reprioritize items. Scan-and-plan is 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 two to three months and also provide opportunities to clear the backlog of items that will not get done. You may also consider the "scan-and-plan" approach here.

The four R’s method

In "scan-and-plan" sessions, you can use the four R’s method, where backlog items are reviewed in reverse priority or in order of age from oldest to newest.

The four R’s:

• Remove

• Reprioritize

• Reinvent

• Reduce

Remove means that you decide an item doesn’t belong to the backlog. In this case, move it to the suitable workflow state (rejected, postponed, or similar).

It’s better to keep a backlog item and change its state to indicate that it will not get done rather than delete it. When you do this, don’t forget to communicate the rejection to the originator and interested stakeholders.

If you aren’t going to remove the item, then you must change it or reprioritize it. Reinventing and reducing both mean changing the item. Reinventing means going back to the original problem and rethinking the approach. Reducing means simplifying the item.

The right backlog size makes for a happy team that generates value

When the backlog is of optimal size, your team can trust that they are always working on the most important items of work. This also motivates them to refine the backlog and helps the Product Owner maintain it.

It’s on you, as the Product Owner, to know what is the right backlog size for your product, your team, and your environment.