Elad Sofer - LeSS - Large Scale Scrum blog

The product backlog (PBL) is probably the second most important artifact in any LeSS (Large Scale Scrum) \ Scrum implementation, the only artifact I find more important is the product itself.

In a on-team scrum the Product Backlog is pretty much simple (though not easy) to manage, if you follow the recommendation of having each team take 3-4 PBIs (product backlog items) per sprint, this means that the product owner needs to deal with about 12 fine-grained product backlog items at any given time, not all require full attention.

Why 12 you ask?

It is recommended that we have product backlog items refined & ready (AKA groomed) for the next two sprints or so.. Given that we have 4 items in progress, 4 for the next sprint and 4 being refined for the next-next sprint. Total is 12.

Got it? Good :) If not, please feel free to contact in the comments or contact me personally

So far so good, now let’s scale it to 8 teams. (8 teams) x (12 items) = ~100 items, which is what the LeSS Framework suggests to be the limit of items that one Product Owner can deal with simultaneously. I know it sounds like a lot of items to deal with, but it is totally doable when performing the Product Owner role as described in the LeSS framework.

The Large Scale Scrum framework is designed (just like Scrum, mind you) in a way that the Product Owner deals mostly with prioritization and less with clarification, with this description most people agree that 100 Product Backlog Items sounds like a reasonable number.

Assuming that you work properly, at any given moment there are ~33 items in work which require low to no attention, 33 items ready for the next sprint that requires low attention as well, so most of the work is spent on the remaining 33 items, now what should the PO do with these items?

Mainly: Prioritize. Given that you have a 40 hour work week and a two week sprint, that gives more than enough time to prioritize 33 items and even get some more stuff done. Capish?