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.