Big backlog? Don’t worry about it.

So you have a huge backlog? Should you be worried?

If we assume that in any given workstream backlog there is a percentage of following story types:

  1. Critical (important bugs or high business value items)
  2. Important (significant business value)
  3. Nice to have (some business value)
  4. Unimportant (limited or dubious business value)
  5. Not required (descoped, duplicates, obsolete, forgotten why they were raised, wacky etc)

Having a target to remove the unimportant or not required stories makes no sense. Even a target to do all of the medium value and above stories doesn’t make a lot of sense.

A better target would be to fully understand all of the critical stories in the backlog and to have them correctly prioritised and groomed for a development team to pick them up.

What do you track instead of backlog size?

If you are trying to track progress, don’t count the total number of stories, instead report on the total number of critical and high value stories.

In addition start tracking the time between critical stories being raised and when the fixes go live. This is called the lead time.

You can also track the amount of time it takes to complete a critical story once a team starts work on it. This is called cycle time.

Finally you can track the number of stories that get completed over a given time period. This is called throughput.

Once you know how many critical stories you have and the average lead time this will allow you to predict when all critical work will be completed.

 

Starting your backlog again – nuclear backlog grooming!

One Scrum team I took over had a backlog of over THREE THOUSAND STORIES that the business “needed to get done”. Given that the team has a velocity of about 30 stories in each iteration and their iterations were two weeks long this meant that if no new work arrived they theoretically had enough work to last them for almost four years, assuming no new stories were added.

To clean this mess up we started a brand new backlog and stopped using the old backlog.

We then worked with the current business stakeholders and the team to identify what they really needed and added those Stories to the new backlog. This worked for everyone. The business were able to identify and prioritise what they really needed. Everyone got a much better idea of the highest priority work and what was coming up in the near future. The nagging doubt that there were high priority Stories lingering somewhere in the monster backlog was removed. The team also felt less pressured and more involved in their work coming up. Planning also became much easier.

In the year I worked with this team we only ever pulled one story form the old backlog into the new backlog.

Quickly grooming large backlogs

After a period of time every backlog builds up a number of Stories that will never get done. There are many reasons for why you wouldn’t want to do a particular story in a backlog, these include (but are not limited to):

  • Business changed its mind
  • Already fixed
  • Duplicate of another better written Story
  • Incredibly low or dubious business value
  • Badly written or just forgotten what it was about
  • Change in business strategy
  • Change in legal environment
  • Change in competitive environment
  • Not technically possible
  • It was a shit story to begin with

So how do we quickly identify dead stories and remove them from the backlog?

Whole Team Grooming

One way to quickly identify dead stories in a large backlog is to set up a session with the Product Owner, Team and relevant stakeholders and get them to review the backlog collaboratively.

Prior to the session print every story in the backlog and randomly place all of the story cards on a large table. When the participants arrive ask them to group the stories into related areas and while doing that to identify any stories that are no longer needed.

Have a laptop handy so any questions about the detail of a story can be quickly looked up.

Identify High Priority Stories

Add value to a backlog review by identifying any high priority Stories as you go. Sometimes in a large backlog some high priority stories can get lost or forgotten. This will help the product owner make sure that they are planning the right work into the upcoming iterations.

Top Tips

Print Story cards if you can. JIRA and Rally both have ways to do this. If you are using another tool it might be a good idea to export it into a csv and them use mail merge to create easy to print cards for large backlogs.

Take all of the seats out of the room to encourage people to keep moving and get the job done.

Many hands make light work. Book the session at a time when everyone is available and not towards the end of a sprint.

Make it fun. Bring doughnuts. Have a prize for the person who removes the oldest story or the worst written story.

Results

The first time we did this exercise in my current role we found that 11% of tickets were no longer needed.

The second time we did this was after a major release and we found that a massive 42% of tickers were DONE, not needed, duplicates, related to the old brand or functionality.