The Scrum Backlog is where Features go to die

What we can do about ever growing Backlogs.

What’s a Backlog?

The product backlog is a […] list of requirements that […] need to be done in order to successfully deliver a viable product.
— Wikipedia

While only a few teams I know manage to fiercely protect their product backlog in this fashion I came across another way to describe the backlog at a party in San Francisco …

The Scrum Backlog is where Features go to die.

At first this might sound fun but it is not seldom that product backlogs grow to hundreds if not thousands of “essential requirements”.

Yet only a tiny fraction of the ideas, bugs, feature requests, requirements & epics that are carefully added to the backlog will ever see the light of day.

Adding an idea or a potential awesome feature to the backlog is way easier than designing, building, delivering, marketing & maintaining it.

What’s the Job of the Backlog?

A backlog tells you what’s coming next. It shows you what you will work on next after you’re finished with what you are focussing on right now.

next /nekst/, adverb
“on the first or soonest occasion after the present; immediately afterward.”

In a nutshell it is a buffer.
A buffer of things you’ve committed to implement in the near future.

Why “in the near future”?
Because if you go beyond the near future all bets are off.

What happens if we limit the Backlog?

Here is a recent exchange on twitter between Adrian Howard and Graham Siener on the pain of huge backlogs.

I think moving stuff away from the backlog or even deleting it is the right way to go in most situations.

Backlogs that are not limited to the near future create a black hole for focus, time & resources. They are demoralizing. They are impossible to prioritize.

I believe if we want to manage software projects effectively we need to start to entertain the idea of a limited backlog.

Limit the Backlog & move it onto your Kanban Board.

If you have a Kanban or Scrum Task Board you can use the first row, name it “Next” and limit it to a few items at a time.

This way every time someone wants to add something to the backlog it needs to be a convincing case on why it is more important than anything else that’s already on there.

But where do we put all the other Stuff then?

Often ideas don’t need to be written down at all. If you get to the time to implement them you will most likely already have a better understanding of the situation than you had a few months earlier.

That said some ideas or defects feel just too important to not save them somewhere. Even if you don’t know when you will finally be able to actually get to them.

Writing these things down helps to free your mind & get back into the now.

Fortunately there are a lot of great tools that you can use to capture ideas for future improvements.

If they are product strategy related how about putting them into a free form Google Doc or into Evernote?

If they are defects you might want to put them into a dedicated issue tracker or bug database.

If they are support requests from users, how about using your helpdesks’s bookmarking or tagging feature?

Another thing are inspirations. I’ve seen many teams just use social bookmarking tools or even share them with the world on twitter, facebook or pinterest.

Way better than forcing all these different things into a generic and never ending product backlog right? ☺

What matters in the End is what actually gets built.

In the end managing software projects is all about deciding what to do and what not to do. Having a clear separation between what sounds like a good idea and what actually gets implemented is key.

Using the Backlog as limited buffer of things that come “next” helps a lot to keep a firm grip on that separation.

You don’t want to drink from the backlog firehose.

If you found this post helpful follow me on twitter where I tweet about Software Development & Product Management ☺

Also make sure to check out Blossom an Agile/Lean Project Management Tool I’m currently working on ☺