A product backlog should contain just about 50 items

An thought-provoking idea has rested in my mind for some time and I’m writing it down right now to get some feedback. Maybe I’m completely wrong, but that ‘ll be clear from the reactions.

I often see very large product backlogs with hundreds of items in them. The sheer size makes it very hard to keep the overview. The symptoms are then solved with ever-expanding structures with epics, features, themes etc. But the root-cause is the size, and I contend that it’s not wise to make the backlog so large.

And I think it is really not necessary to have a large backlog. It’s rather a remainder of a waterfall mentality.

A product backlog with 50 items is enough! And this is why:

The top of the backlog, the work for the coming 2-3 sprints, should contain small and clear items. In my experience most teams deliver 6-10 items per sprint, so that yields some 25 items at the top.

Below that, the items should not be that small. There should be larger items that can be sliced into small pieces later.

Slicing already now is not wise. It could be that we will not deliver this item. New, and more important items can emerge, the PO may down-prioritise these items. Maybe the client asks us to take new directions, or the team invents smarter technical solutions. Slicing the items too early is a form of waste. Having too many small items in the backlog can make us less agile. We don’t want to change direction because we have put so much time in the existing items already.

So, after the top 25 small items, there should be larger items in the backlog. If the top-items are all 1-8 story points in size, the items lower in the backlog should be 13-40 points in size, and lower still the items should be even bigger. So having only 50 items in the product backlog is enough to keep the team busy for a year or so.

Well, this is my theory. Any thoughts?

2 antwoorden
  1. Dennis Mansell
    Dennis Mansell zegt:

    I totally agree that backlogs should be short – they are basically inventory waste. But why fifty? Why the very specific numbers of 25 small items and their ‘point size’ ( what does that mean?). I’ve worked with teams who had one item in each sprint and one item in the product backlog. And they were great: they delivered done product almost every sprint and continuously looked for ways to improve.

    • André Heijstek
      André Heijstek zegt:

      Hi Dennis, the numbers are rough indicators and certainly no musts for all teams. But in the teams I’ve worked in/with, I started to like these numbers. If you only have 1 items in your sprint (as one of your teams), there is a 50/50 chance that this item does not get completed in the sprint. I would not like that as team member nor as product owner. That’s why I always recommend 6-10 items per sprint. If you work nicely top-down, then you should mostly be able to deliver the most important 5 items, and often the rest as well (and sometimes even some more).
      If you only have 1 item in your product backlog (assuming that would fill the next sprint) then you do not have any longer term vision. I would not like that as a team member, nor as a PO.


Plaats een Reactie

Draag gerust bij!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze site wordt beschermd door reCAPTCHA en GooglePrivacy PolicyenServicevoorwaarden toepassen.

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.