Measuring Value, 3

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!

For reference, the first two parts of this series are here and here

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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s