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?