As part of the ongoing look at metrics that can help indicate whether a project or team is being truly Agile, we’re going back to the basics – to the Agile principles.
#3 Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.
So, principle #3 is obviously the most fundamental, because if you’re not delivering working software (or other equivalent), then you’re probably not delivering value to the customer.
This is pretty much what I call an eyeball-level assessment, because it is so straightforward, but here are some of the metrics that could be used to capture the level of delivery value:
- % of stories that are releasable, i.e. stories that meet the definition of done
I definitely distinguish between releasable and released since less than 5% of teams I’ve worked with were set up to actually deliver to production/client at the end of every sprint. So whatever definition of done is for a specific team, that is what matters for this metric.
- % of releases where business value delivered and cadence are reviewed.
- Release value analysis (combination of planned vs. achieved and burn-down)
If you’re doing release-level planning and retrospectives, then you’re probably meeting the first criteria. The second is usually a custom measurement that combines several indicators to highlight client-specific priorities.
- % of completed epics / business features where team reviews the time it took to get across the board (cycle time)
- % of completed stories where teams review the time it took to get across the story board (story cycle time)
The first criteria is one I track for my own purposes especially for stable/mature teams because it can often reveal underlying pain points and that make for great discussion during retrospectives. The second applies when I present the data and then the team discusses trends, their implications as well as possible causes and effects.
- Distributions of all the story sizes in backlog go from smallest size/most stories to largest size/least stories.
I don’t track this as formal metric but it provides a good visual gauge for me to ensure that the backlog grooming is going well. If the size/quantity ratio is off, then I’m going to dig a little deeper into the backlog to see if there are any issues that need to be addressed.
As always, these metrics have been borrowed/adapted from several Agilists that I’ve met and worked with over the years, so thanks – and remember that all mistakes are my own!
And remember that even the best metrics are a starting point for discussions because the context is just as important to understand the full picture.