The ‘Essence’ of Agile Metrics. Part 1.

This is my initial blog for Project Times and I’m certainly happy to be joining the community. So, a little about me.

My name is Bob Galen and I’m from Cary, North Carolina. I’ve spent the greater part of 25 years doing software development—in roles such as Developer, Software Director/ Manager, Test and QA Director/Manager, and Project Manager.

For the past 10 years, I’ve been moving my thinking and practices towards those espoused by the Agile Methodologies. I’ve found them to be the most congruent, humane, and effective approaches for delivering software and I try to share my insights and excitement with everyone I meet.

Perspectives – you’ll see a strong skew in my posts related to the following topic areas:

• Implications of agility for the project manager
• Implications of software testing for the project manager
• And leadership and soft skills topics for the project manager

and I also blog for Business Analyst Times on similar topic areas. So that gives you a feeling for coming attractions. But, enough of that…

I’ve been struggling for quite some time figuring out the “essence” of agile metrics. What are good ones versus bad ones? Are there related sets that are relevant and how many are needed? And how much change do we need to make from our traditional metrics thinking towards agile metrics?

Another thought I’ve had is whether they should represent a trailing indicator or a leading indicator? Meaning, should we measure the processes (at the beginning or leading edge) or should we more so focus on the results and learning (at the end or from the trailing edge)?

For example—

I think of measuring estimate accuracy (estimate + actual) as a leading indicator. Why is that since you measure actuals at the end of your work?

I’m thinking of it from the point of view of what you’re trying to improve. In this case, you’re measuring estimates and actuals to improve your overall planning and estimation processes. These activities are typically front-loaded actions and are often static…meaning they are completed once at the beginning of the project.

The other challenge with this metric is taking corrective action for improvement. Effectively, you can only effect a change with the next planning interval for a project. Depending on the length of that interval, improvements could be infrequent and delayed. Or depending on project success, they might not be useful at all.

So I’ve seen some agile teams that try to measure various things. Let’s take a typical example.

How about if we measure user story volatility in the sprint? What we’re trying to focus on is how many times do stories change (get added to, become reframed or reduced in scope, or removed entirely) within any particular sprint. To what end? Well, we’d like to improve our story grooming process and monitor how the team is delivering on their sprint planning commitments.

Ah, there’s a key! Sprint planning is sort of a leading indicator, in this case you’re measuring the quality of story entry. What if we turn this into a trailing, more results oriented, measurement? Let’s measure the velocity of the team as they exit the sprint. We can measure velocity in stories produced and in story points delivered.

An even better trailing metric is to measure how the team delivered value towards their sprint goals. Meaning, did they deliver what they committed to? Not in tasks or in stories, but in content that exactly met the spirit of their customers needs and the level of their commitment.

You notice that I reframed the notion of a trailing metric to a results oriented metric. Another way of thinking about it is measuring at the “outbound side” of the team’s work. That way, you’re leaving the doing of the work up to the team and simply measuring results or outcomes. To be continued…

Don’t forget to leave your comments below