Is Your Backlog a Graveyard of Features?

My team is a huge fan of sprints and backlogs when it comes to planning projects. But the more we dig into project management, the more negative patterns we observe. One of them relates to the backlog and how it turns into a place where features die. Sounds familiar? Then keep on reading.

What is Product Backlog?

The product backlog comprises an ordered list of requirements that a scrum team maintains for a product. It consists of features, bug fixes, non-functional requirements, etc.—whatever must be done to successfully deliver a viable product. – Wikipedia

In brief, a product backlog is a list of requirements that need to be implemented. Teams rely on it when it comes to deciding what gets built next. And this works really well – but only as long as you keep it well-groomed and remove everything that doesn’t belong there.

Backlog or Mishmash?

In reality, it’s hard to keep the product backlog protected from waste.

a) We put there everything that sounds like a good idea.

b) We put there everything we don’t want to forget.

c) We add features to the backlog (even though we don’t implement it immediately) to keep demanding stakeholders happy.

This is how the Backlog turns into mishmash. Instead of focusing on what is essential for the project success, you spread yourself too thin.

Grooming Your Backlog

The Backlog is developed iteratively which allows maximizing customer value and minimizes development effort. It means:

• You add items that have customer value. Entries without any customer value are pure waste and should not be present anyway.
• As new items are discovered they are described and added to the list. Existing ones are changed or removed as appropriate.
• The most important items are moved to the top.

The Backlog maintenance is an ongoing process. You should constantly estimate and re-estimate the entries based the team’s state of knowledge at a particular moment.

Avoiding Feature Graveyard

1. Limit the Backlog

The Backlog should tell what’s coming next. Next means “immediately following in time, order, importance, etc.” This is how you know exactly what you will do after your finish what you’re working on right now.

The Backlog should be limited to only those entries that shall be implemented during one of the next sprints. Backlogs that are not limited create a black hole for focus, time & resources. They are demoralizing and impossible to prioritize.

Whenever someone wants to add an item to the Backlog, they should convince why it is more important than anything else that’s already on there.

2. Store ideas for future improvements

Limiting the backlog doesn’t mean all other items should be neglected. Some ideas may be too important to not save them somewhere. Even if you don’t know when you will be able to actually implement them.

Use any tool where you can write these things down, free your mind and get back to the items that are important now.

For this purpose, my team uses Atlaz. We create boards to keep everything in order. The board structure can be as simple as several vertical columns, including “Ideas”,  “Backlog”, “Next Up”, “Doing/In progress” and “Done”.

This works much better that forcing all different things into the backlog at once.

3. See the difference between what is important to have or just good to have

What really matters is what gets built in the end. You have to act as a filter and have a clear separation between what is a ‘good’ idea and what is necessary and sufficient to complete a project/release successfully.

Keep in mind that the Backlog should be limited to the most important things that will actually be implemented and come next on your priority list.

How does your team handle the backlog? Share in the comments.