What is a good total size for a Product Backlog?

Question

General

I realize the size of a product backlog will vary with each project. But assuming a project that is large enough to require a significant length time, is there any research or statistics on diminishing returns in terms of refining stories and epics?

In Zsolt's answer: https://pm.stackexchange.com/a/6715/2730 It mentioned that the last 2/3 of the backlog is going to change in the future.

This seems to be inline with the idea of Agile and Scrum. I'm wondering if there's a point where it is better to consolidate those stories into just epics, until such time as they may be in near future sprints.

What is a good size for a backlog, relative to the teams velocity?

Does it make sense to consolidate existing stories into epics, if they aren't to be worked on for a significant period of time? (Assuming that the epic will hold the same knowledge of the original stories)

Specific

This question stems from our specific case. We have nearly 400 stories, and complete an average of 5 per sprint, in 2 week sprints. This is mostly because the initial push into scrum was to get every possible story into the backlog, rather than to form epics and divide as true needs were discovered through iteration.

It obviously affects our ability to manage the upcoming stories, creating duplicates, wading through hundreds of possibly irrelevant or just wrong stories in the process. We are unable to update stories as new knowledge is gained, causing us to spend more time second guessing meaning and purpose of stories rather than iterating.

We do suffer from a lack of prioritization. However, I'm thinking the sheer number of stories is causing our product owner and stakeholders to not want to invest the time into prioritizing. It feels very chicken and egg.

I'm hoping to find some information I can use to suggest consolidating large numbers of stories into epics, to be broken down later, when the actual need for the epics is in the near future (4-8 sprints).

Answer 1

There is no real standard on product backlog. There are too many variables to what is essentially the company's strategy plan. The one common bit of guidance out there is more to do with pruning a backlog. It is "if an item has been on the backlog more than X (usually a year or two years) then remove it. If it was really important, it will be added back."

With 400 individual user stories, you have roughly two years of backlog. However, from what you're saying, it sounds like your "ready backlog" is not very deep. Ready being it can be picked up by the development team and run with. Here there is a commonly accepted standard that the top of your product backlog should have 2-3 sprints worth of stories that meet the definition of "ready", where the development team can pick them up and run with them. I might work on this discipline first, if possible by just focusing backlog grooming on the top 20% of the backlog.

To try and tame your product backlog I would suggest two solutions, one proactive, one reactive. I would recommend doing them in the following order.

Affinity Mapping (reactive): Basically a fancy name for "put them in Epics". The exercise is important though. You'll want a facilitator (scrum master, unbiased project manager, etc.) Print out those 400 user stories on physical paper. Get a big open wall and tape all the user stories up on the wall on one side (even another wall). Then, as a group, start pulling stories and putting them on the wall. The goal is to start grouping them. There isn't a preset list of categories though, the categories will grow out of how people group them. s these categories grow, create post-its to label these categories. You may find some stories fit in different groups (if this happens you can dupe the story or put the two groups close together so the story straddles them.

When you're done, you'll have some natural ordering and grouping of the stories. These are your Epics. By doing this, you don't end up with arbitrary assignments, you end up with categories that make sense to every one. You will also get some idea of dependencies as a result.

Prune the Product Tree (proactive): Conteneo.co offers collaboration exercises that companies can use for pretty much anything from strategic planning to retrospectives. Most have online and offline versions.

Prune the Product Tree is an exercise to map out release horizons and what is important in those horizons. Short version (Go to Conteneo's site for a proper instruction) is you have a big wall map that looks roughly like the outline of a tree. For the body of the tree lay out several concentric rings (a bullseye) and assign these time horizons (next quarter, six months, next year, etc.).

Take your categories from the last exercise and place them on "apples" (can be just post-it notes). Also create ten to twenty blank "apples". All the apples get put on the wall next to the tree. The exercise is then the act of putting the apples on the tree where they make sense on the time horizon. The blank apples allow the creation of new concepts and themes. Roots are also important, they represent required infrastructure or outside dependencies. You may end up placing apples here to track these dependencies.

Hope that helps.

Answer 2

Using the just in time principle, assuming you use stories purely as tangible work items that the team consumes, and that you do not use your product backlog to reflect your product roadmap...

The minimum "good" sized backlog ensures that your team never runs out of work at any time during the lifecycle of the iteration.

If your team has a velocity of X that usually varies up to Y story points, try and keep a groomed backlog that always has at least X+Y story points in it. Everything beyond X+Y story points can be represented as higher level epic.

By staying at the epic level after your throughout is met in stories, you reduce waste that occurs when grooming stories that are likely to change by the time they are pulled into an iteration.

For example, a team with a velocity of 70, that has been known to deliver up to 100 during an iteration should have a groomed backlog with minimum of 100 pts of stories in it that can be pulled at any time.

After the ~100 pts, additional stories can be groomed as needed from epics in your backlog just in time as stories are pulled into an iteration.