Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Risk Management, Scrum
Measuring a Healthy Backlog of Work

What criteria do you use in measuring a healthy backlog?

For those who have, or currently capture their work in a backlog, what is the process and set of criteria (if any) used for determining the health level of the backlog?

Follow-up question. How are these metrics shared (remember, transparency!)?

Update: Added a below response for further develop the thread.
Sort By:

Interesting question, Andrew!

What criteria should we use to judge "health"?

Three come to mind and there may be more:

1. Is everything the team is actually working on related to the product/project found in the backlog?

2. Does the relative ranking of backlog items reflect "real world" priority balancing business value, dependencies, solution risks, cost of delay and other factors?

3. What is the percentage of "won't have" items in the backlog relative to the "Must have", "Should have" and "Could have" ones? In other words, is the backlog a garbage can?


I'm sure you're already familiar with the classic "DEEP" attributes (Detailed, Estimated, Emergent, Prioritized). If we accept that these are characteristics of a healthy backlog, then you could inspect some metrics as a health check.

Can you see if your backlog is being updated? If so, you could (theoretically) use that as a metric. A backlog that's never updated can't be emergent, and it's probably not prioritized (or the order could be obsolete). That could be a sign that your product owner needs to spend some time in the backlog.

Do you have a lot of un-estimated items in your backlog, especially near the top? That could be a sign that your development team needs to spend some time in the backlog. You could measure your estimated vs un-estimated items as an indicator of backlog health.

Does your team waste a lot of time trying to decipher cryptic cards in your planning sessions? That could mean your backlog isn't detailed appropriately. You could measure the time spent in planning and see how well that goes.

Your team's performance is more important than any of these metrics, but it's something you could investigate.

I like Wade's metric suggestions for measuring backlog health. The only caveat I would have is about using an input (i.e., time spent) as an indicator of results or outcome. We all know spending a lot of time does not necessarily translate into business value.

I would probably add a metric showing the percentage of backlog items with an acceptance criteria (definition of done, if you prefer).

Awesome. Love the [virtual] dialogue!

When we think about a healthy backlog, how do we then quantify it? Whether gauging on prioritization or story attributes, how do we provide a true, data-driven, metric that the backlog is in-fact health - as in able to support the teams [proven] track-record, i.e., velocity?

As a leader, my expectation would be quantifiable evidence. Any additional thoughts?

Please login or join to reply

Content ID:

"When a stupid man is doing something he is ashamed of, he always declares that it is his duty."

- George Bernard Shaw