Don't Crap in the Product Backlog

I've got news for you, if your product backlog has so many items (stories, features, bugs, back log items, call them whatever you like) that you feel the need to create a web of dependencies that you then need to visualize in a chart or use some other huge time sink, then you're doing it wrong. There's too much crap in your backlog and you're drowning in it.

This is an astoundingly common problem and one I deal with on a daily basis as I interact with various Scrum teams. Here's what the problem looks like:

1. Change wording in system options from "Foo" to "Bar" in random context menu.
2. Move dropdown menu in system options from "Bar" tab to "Foo" tab.
3. Simplify security settings for "Foo" in system options menu.
4. Other random change to system options that is too small to ever make it into a real sprint

Multiply this by every feature in the product and you end up with a backlog spanning 100s if not 1000s of things to track. The problem here is that any tools you use to manage this behemoth product backlog is really just masking the problem bigger; you're getting lost in the details and missing the bigger picture.

Don't look for ways to manage everything, look for ways to make everything simpler and the problem will solve itself.

So what should those 4 backlog items look like?

1. Optimize the system options menu

That's it. Each of those 4 original backlog items are bullet points inside of the bigger one and I've effectively shrunk the amount of crap I have to manage by 75%. Do this with your entire backlog and you'll get something you can actually refer to in conversation with the team.

Product Owner: I'm thinking we should probably get around to the menu item in the backlog

Team: The whole thing or just parts? I took a peek at it last week during Sprint planning and it was getting pretty big, that's one of the reasons we didn't do it then. Has it changed much since then?

Product Owner: I've changed it a little since then, but I don't think we need the whole thing done by next sprint. I'll pick out the bits I like and send it to the top of the priorities, but we've been putting those changes off for too long already.

As opposed to:

Product Owner: There's a bunch of menu changes in the backlog I'd like to try to get some of them done in the next sprint.

Team: There's work for the menu in the backlog? We never got a chance to look at the whole thing during sprint planning. What kind of changes are we talking about? I haven't had time to even look at any of the menu changes yet.

In the first example, the Product Owner can refer to something in the backlog and the team knows exactly what he's talking about. In the second example, the conversation needs to refer back to an artifact, list or tool for even general conversations.

You'll notice by the way, in the first conversation, the Product Owner wasn't afraid to pick out the bits in the backlog item that should be implemented, in effect, he's splitting the product backlog item, but he's only doing it when he needs to. The same thing will happen with the estimation; the team will estimate the new backlog item that's high enough in the priority for them to do. The other will probably sink lower into the backlog and doesn't need to be estimated until it makes it to the top again. If the item needs to be split again to fit it into the sprint then it's usually handy to have the Product Owner around so he can help figure out which half needs to make it into the sprint.

So, what about when feedback comes in? After all, the backlog is filled directly (if possible) by the stakeholders and those ideas are likely to be fairly small compared to our new larger items. The product owner should look at each and every backlog item that comes in and if the item doesn't seems similar enough to other backlog items, it should be assimilated by another item.

More objects, more moving pieces means more administrative overhead for the Scrum Master and the Product Owner (they have enough going on as it is). Like most things in Scrum and for that matter like most things in life, make things as simple as possible (but not simpler) and only add complexity as the need arises.

Related Posts:
6 Things a Product Needs to Know
Should Your Scrum Team Stop Using Story Points?
5 Big Issues when Scaling Scrum