September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
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?
A healthy Product Backlog will be specific to a team. There are no best practices in Scrum. And why quantify it, who is this data meant for? What need do you have to measure such a metric? I'm a curious person, sorry.
A couple notes on DEEP" attributes (Detailed, Estimated, Emergent, Prioritized). Detailed should be "detailed appropriately". The other challenge with the it is a myth that the Product Backlog is prioritized. The Scrum guide changed 'prioritized' several years ago to now state 'order'. There is a difference. The backlog is ordered in many ways: value, dependencies, risk, business conditions, cost to the business, etc.
Also, fyi, velocity is an optional metric and not part of Scrum. It has done more harm than good.
And evaluate each user story in the backlog against
INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)
and can it meet the SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) Sprint Goal?
Backlog means different things to different people. We use it to describe things that are past-due. There is still a healthy level there as well. If your on-time release performance is 100%, you likely aren't setting aggressive enough goals. It can also be the difference between first pass quality, and releasing whatever you have when it was due to game the metric.
Chris, appreciate you chiming in!
The perspective I was coming from back then was to get a sense of when teams say their backlog is healthy, what does that mean? And if we can say it, and explain it, can we show it?
There may be a level of value knowing that a team's backlog can support the work they can accomplish in a given sprint.
Another input would be whether there are enough work items for the team for the next 1-2 sprints (assuming a sprint-based cadence is used) or for a meaningful amount of time if a continuous flow approach is used.
That will ensure that we don't have the opposite issue (to the "everything and the kitchen sink backlog") of a starved backlog.
Please login or join to reply