Backlog size and product goal intervals

How large should an agile product backlog be? I like to recommend to keep the backlog small. 50 items is better than 100, 100 items is better than 200. But this creates a problem - how to keep backlog so small? Business demands predictability and "promises". We have to have future work somewhere.

The solution is to think of roadmap and backlog as two separate storages for future work opportunities. Roadmap can stretch much farther into the future. 1-3 years for example. The farther into future it looks, the more uncertain the things will be. The items on the roadmap that are closer to present time are much better understood and more certain to make it into the actual backlog.

This does not happen by accident. Items on the roadmap require diligent investigation. If your organization has separate roles for Product Manager and Product Owner, then naturally the Product Manager owns the roadmap, and the Product Owner owns the backlog. Product Manager can use this excellent question list by John Cutler to control and investigate the items on the roadmap.

In contrast to roadmap, which can stretch to years, the backlog should be kept small. The reason for this is, that in my opinion, when an work item gets approved to the backlog, then the commitment level to actually deliver it is quite high. Items on the roadmap can still be rather uncertain. But when the item is approved and moved to the backlog, it is done with the understanding that "yes, we will do this at least 95% certainly".

The opportunity is the roadmap to backlog transition. This is the place where the dev organization and the product leadership should do the yes/no decisions.

Coming back to the backlog size, what is the optimum backlog size? In some teams, let us call them type A teams, it may be very short, only a few weeks. In other situations (for example if there are lot of inter team dependencies and the product is much more complex, let us call these teams type B teams) the organization may require and benefit from a larger backlog. You need to be able to trust that other teams deliver. In those cases, the backlog (prioritized list of high commitment work) should be longer.

So, here is my idea. What if we define the backlog length with the interval between Product goals? My theory is that the Product Goal interval for the type A team is probably very short. And for the type B teams, the Product Goals probably are spaced out more like 6 months apart.

In my opinion the benefits of this approach are:

• Keep the backlog at optimal size for this organization and team
• Keep the team focused to the next Product Goal
• Force the organization to define Product Goals (this is an often overlooked part of agile)
• Allow the team to start introducing the Product Goal +1 items to the bottom of the backlog gradually

I would love to hear comments from you, what do you think of this approach.