10 Ways To Improve Every Backlog

Every team I’ve worked with have approached their product backlog in different ways. It’s always surprising to see how much each team differentiates, when from the outside we should all follow a similar method right?

Over time every team, with experience, will work together to find out what works for them so there’s not a one-size fits all, but here’s some tips that can be picked up and applied to any backlog.

# Use user stories

The classic story format ‘As a …. I want to….. so that….’ has been tried and tested since the beginning of scrum. It’s the simplified but most effective way of capturing the value in a story by making it clear who the user is, what they want, and why they want it. I’ll be using this until I can find something better.

# Monitor the size of your backlog

Backlogs that contain 100s of stories become frustrating and painful to manage and it’s easy to loose site of everything that it contains. Is story 199 of 200 REALLY a priority for the product? It’s likely most of the stories at the bottom will remain at the bottom for a long time because by the time you get to them, something of more priority will have come up.

The tip here is: make sure you only have stories you need on the backlog – archive the rest. Backlog refinement sessions are a good time to do this.

# Welcome the team to add to the backlog

My view is that anyone in a team team should be allowed to add to the product backlog but it is the Product Owner who chooses it’s priority. New ideas should be valued regardless of source; a developer may have discovered a more efficient way to do something or had an idea for an amazing new feature, but it would help the Product Owner by having a place, or a ‘tag’ on those stories which they can refer to during refinement.

# Keep it in priority order

This should be an obvious one. Your backlog should always been in priority order. This should be driven by the Product Owner but often needing input and guidance from the team.

When entering sprint planning the team should be able to pick the stories from the top of the backlog with confidence the Product Owner has already decided it’s highest priority for the sprint.

# Make it transparent

Everyone in the team should be able to see and have ready access the the backlog; Developers, Scrum Master and Product Owner. It’s valuable for everyone to see the vision for the product, what is likely to come up next and empower the team to contribute to that vision. I’ve seen too many times where the Product Owner doesn’t have access and someone manages the backlog on their behalf and am puzzled as to how this is possible.

# Regularly groom it

Backlogs are a living, breathing to-do list. The team should (driven by the Product Owner) often inspect the backlog and use the stories as talking points so everyone can really understand the Product Owners vision for that story. The team should also be able to relay back what are the dependencies,blockers, or ask questions before going into sprint planning.

# Estimate at a high level

In scrum we’re told to only really care about what’s in this sprint and a bit about what’s in next sprint. However business’s always want to know how much work there is roughly and how long roughly it will take.

We need a release plan. Each story should have a high level estimate of work so the Product Owner can relay to stakeholders when they may be able to use their shiny new feature.

This should be done as a team – not the Product Owner or a single developer.

If anyone wants to know exact delivery dates for something in the distant future, say ‘I don’t know, that’s not agile’

# Capture the detail

Every story should contain a user story, requirements to complete it (acceptance criteria), the definition of done and any other detail needed that will help deliver the story. It’s likely there has been some conversations about each story so write down the important parts from the conversation as we’re likely to forget when we come to work on it.

# Keep stories small

If you use planning poker or at least the Fibonacci number series to put an effort against a story, the higher the estimate, the less confidence we have in it.

Break down the stories until you are comfortable it can be delivered in the time you’ve estimated. Keep in mind that story still needs to deliver value.

# Most detail in prioritised stories

The backlog is in priority order and now it’s time to refine those stories. We should only refine stories looking 2-3 sprints ahead. Being agile, the priorities are likely to change. The higher priority the story, the more attention and detail it should get and this should gradually reduce as you move down the backlog.