The end of the year is a good time for reflection and doing a personal sprint retrospective.  One of the things that I’ve seen in the last year is dealing with cruft in the backlog.  Stories that are stale, that have been consistently de-prioritized in favor of other stories. On the face of it, this is how most agile methods are designed to work: you work on the most important thing to do right now and the less important things later. That makes sense, but how do you tell if there is something that is less important and getting to the point of irrelevant? Or for that matter what if there were a way to start detecting when changes are occurring that could be fixed in the backlog management process?

I had started thinking about this when looking at the backlog for a project that we took over early in the year.  There were items on the backlog that were consistently low priority to the point where the people that were originally involved in the item had all left the company, so there was no one to answer questions about them. This was kind of an extreme example, but it started me thinking about early detection and management of the backlog.

So as a thought experiment, I came up with a metric that might help detect and easily highlight these problems.  I haven’t tried it out yet, other than looking back forensically at the projects that I was involved with this year.  it will be interesting to try and apply it to the projects coming up to see what happens.

Backlog Ratio

This metric is basically, the ratio of how long an item has been in the backlog compared to the time it takes to deal with an item. It’s actually fairly simple to calculate although it depends on two metrics that should already exist: lead time and cycle time. The most concise definition of lead and cycle time is here: http://leanandkanban.wordpress.com/2009/04/18/lead-time-vs-cycle-time/ Basically, the clock starts ticking on lead time as soon as the item hits the backlog and ends when it is delivered. Cycle time is the time spent actually working on an item. So everything in the backlog already has a lead time for it, even though it doesn’t have a cycle time.

Thee backlog ratio is: (lead time – average cycle time)/average cycle time. For brevity, I’ll just call this “Br”.

This will give you a number that corresponds to the number of cycles an item has been in the backlog to date. It ranges from -1 for something that was added now to some large number indicating infinite staleness. By expressing it in terms of cycles, it evens out the fact that different projects have different cycle times.  For example, if you’re using lean to deal with support requests, you might have a cycle time in hours vs a standard development project with a cycle time in days. It should work especially well with a devops style environment where you have both types of requests being managed in the same backlog.

Detecting Low Priority Items

One of the problems with backlogs is that we like to lie to ourselves a little.  In theory, the priority assigned to a backlog item is how important we think it really is. In practice, we don’t always deal with things in priority order. There’s a simple way to figure out which items are low priority, ignoring the priority we say that they are.  If you were to calculate the average Br, then anything with a Br value greater than average is a low priority item; regardless of what people think it’s priority is.

Basically, this measurement lets you know that there are items getting added to the backlog that are getting worked before this one. That’s the very definition of low priority.

Scrummerfall Projects

When you have a scrummerfall style project, usually all the stories get added at the start.  What this will mean is that you have a lot of stories with a very high Br value.  But the average Br will also be very high. When the average is very high, that’s just an indication that there were a bunch of stories that were added at the same time and are slowly being worked. When the average starts dropping because things like bug fixing stories are getting added and there are still some stories from the original batch that starts to indicate which ones are lower business value.

Setting the Agenda for Backlog Grooming

One of the side effects of this is that figuring out the agenda for a backlog grooming meeting becomes an task that could be automated. If you select all the items that have not been started with a negative Br (they’re new so probably haven’t been looked at before) and some number of them with the highest Br, they’ve been around for a while. Now the agenda could be sent out automatically for regularly scheduled meetings.

Capacity Planning and Problem Detection

One way that this could be used to detect problems is to look at the average Br over time. I suspect that there is a healthy range that a team’s average Br will move in. Onve the average gets out of that range that could be the first indication of a problem.

For example, for a more ops centric team dealing with issues that are coming in constantly, a healthy average Br range for backlog items would be <1. That would indicate that most of the time, issues haven’t been waiting for more than the time that it takes to resolve a single issue.

For a more new development oriented team, the average Br range might be best in the 1-4 range, that would mean that there is always a new story that can be worked on; but there aren’t so many stories to start that they risk becoming obsolete by the time people are ready to work on them.

Conclusion

This metric will be an interesting experiment to apply to projects in 2014.  I think that it will really highlight some of the areas that we neglect even though we don’t want to admit that we’re doing it.