Spring-clean your backlog

Trainline Team
Trainline’s Blog
Published in
4 min readApr 7, 2017
119_3872x2592_all-free-download.com_20539280

Is your development backlog too big? Do you to find yourself having two backlogs without realising it? One which is high priority items, recent defects and tasks to be completed in the next few weeks, and one which is full of nice-to-haves, low priority defects and legacy requests? I think we all know what gets the focus and what is just muddying the waters.

This is a common problem I’ve found with pretty much every project I’ve ever worked on, and I’ve found a few steps that have really helped to get your backlog looking in a much healthier and more manageable state.

You can only focus on so much at once, and not being able to see the wood for the trees, as it were, can cause a team to lose focus. We can only take in so much information at once, and there’s no way a Product Owner can efficiently prioritise a hundred items or more.

Out with the old

A good rule of thumb, is that if something is over a year old, and hasn’t been done, then GET RID OF IT.

If it’s a product request: it obviously isn’t important enough to have been prioritised up to now, and therefore it is pretty unlikely that it will get done in the next year. Unless your business stagnates and you are struggling to find things to do, in which case, you’ve probably got bigger problems.

If it’s a defect: it was that much of an issue, it would have been fixed. And if something changes which causes this defect to crop up again (perhaps more severely) then a new ticket can be raised, probably with much more relevant and accurate information than a year ago.

If you’ve ever moved house and had a massive clear-out of things you don’t need, hopefully you can relate to the following question:

How many times have you missed the items that were gone?

It’s normally pretty rare that you will, as if you haven’t used something in 5 years, you are unlikely to need it again in the next year or two. The same is true of development, especially as you are theoretically buying new products on a daily basis! Once you’ve done this initial clear out, you’ll find it a lot easier to do the next step.

Looking too far forward

Again, if there are stories/requests in there for functionality which is not in line with the business priorities for the next 6 months or year, then there is probably no need to have it in your backlog. In a tech company, it is very difficult to predict what the future will be like, and there is no point trying to work out the details of these stories now or wasting your time on something which may never happen. So if you honestly can’t see it getting done within the next year, GET RID OF IT! This will allow you to focus on the main business priorities. These things should be kept elsewhere, as part of a Product Owner roadmap or at an epic level with no stories.

Timeboxed small defect clear out

There always seem to be these little requests/tasks/defects which are very small changes, and they need to be done. At some point. The issue with these is that they are generally not the most exciting things to work on, and are likely to be the last thing someone will pick up, especially when there is something much more appetising on the backlog. I’ve found that a great way to tackle these is to have a timeboxed “Defect Attack Week”. Although this doesn’t have to be a week, maybe it could just be two or three days:

  • Decide on the top 5–10 bugs that have been lingering (or more if you’re feeling ambitious)
  • Write each on a post-it and place on the wall near the team
  • Every time someone fixes one, move the post-it, throw it away/up in the air in celebration
  • See how many you can fix in the timebox and if the team clears them all, have some treats to recognise it

This approach can also work leading up to a big release or project closure when you’re discovering lots of defects.

Once your backlog is relevant, minimalist and focused, you’ll hopefully find planning and prioritising much easier.

Happy Spring Cleaning!

bunny

About the Author

Karen is a Business Analyst at Trainline. She has a passion for agile development, continuous improvement, and eating and drinking her way around London (Instagramming wherever possible!)

--

--