Where did that come from?! – tips for avoiding the ‘bloated backlog’

‘Where did that come from?!’ – tips for avoiding a ‘bloated backlog’

How many times when going through a product backlog have you said, ‘where did that come from??’ We’ve all seen it right? Here’s what normally happens….you open up the backlog item to see what the description is and who put it there so you can ask them for more information and guess what? Yep, they’ve left the team and there’s no information in the item, just the heading. And it’s not normally the odd one or two, there tends to be lots of them, from my experience anyway.

You may think, ‘what’s the problem with using the product backlog for ideas, is that not the point of it?’. Well, not really. ‘In the simplest definition, the Scrum Product Backlog is simply a list of all things that needs to be done within the project. It replaces the traditional requirements specification artefacts. These items can have a technical nature or can be user-centric e.g. in the form of user stories.’ – <https://www.scrum-institute.org/The_Scrum_Product_Backlog.php>

Now, if people are allowed to add anything to the backlog, very quickly the product you’re building starts to look different to what was intended and features turn up without any user research carried out to validate it’s something the users need or want. And it doesn’t seem to matter whether you have your backlog on the team wall or online, it always seems to happen.

So how can we make sure we have less of those, ‘where did that come from?’ moments?

Tip #1 – Instil good habits early

If you are creating a backlog from scratch, you want to ensure all the team know the purpose of a backlog, what it is and more importantly, what it is not!! From my experience, the main cause of the bloated backlog is when the team (including stakeholders) see the backlog as a place to store every single idea, whim and ‘wouldn’t it be good if…’  scenario.

Now, that’s not to say these should not be captured in the backlog but this is where the good habits start. Don’t let people think of it as a dumping ground for everything/anything as this is where I see most of the ‘where did that come from?’ moments. I agree with Mike Cohn that anyone can add an item to the backlog so make sure the whole team are aware of these habits.

And if you’ve inherited a backlog, the same applies. If you urge this good habit from the off, it makes life so much easier. You may have read other articles on Agile or had training to say that nothing gets put in the backlog unless it’s agreed by the Product Owner but I still see ‘phantom’ items going in there. If you control it using the PO as the gatekeeper, brilliant. However, even POs can have a habit of using the backlog as their personal reminder board.

So here’s my tip: when a backlog item is created, make sure it has a description of some sort and not just a heading. Put some detail in there so that if someone look at it at a later date, there’s some context. And this tip is not restricted to stakeholders, this goes for all team members.

Tip #2 – Revisit the ‘whole’ backlog at regular intervals

While this may seem obvious, I rarely see it done and this for me is one of the main causes of the ‘bloated backlog’. I’m not suggesting you revisit the whole backlog every sprint but I do recommend every other sprint or so. The BA, Product Owner and possibly the Scrum Master should carry out the exercise. I recommend these roles as the Product Owner is responsible for the backlog (they own it after all), the BA should know the detail of all the backlog items and the Scrum Master should be aware if there are ‘rogue’ items going in so he can coach and advise the team on good backlog management practices.

Now you might be thinking, ‘isn’t this just backlog refinement?’. While you should be having regular backlog refinement sessions, I feel the refinement sessions go in to more detail of the stories in the backlog and not necessarily tidying it up. And refinement sessions, you tend to look at those stories either just about to go in to a sprint or a little further out where.

And finally…

Instil these good habits in the team and you’ll have a manageable backlog that reflects the product you’re working on, you’ll be able to plan sprints easier as the backlog won’t be cluttered with items that have no or little meaning to what you’re building and you’ll only be adding items that reflect the vision for your product.