See Your Agile Measurement Traps

In honor of my new book, Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, this is the second in a series of four trap emails, the measurement trap.

Here are three common measurement traps:

You/your management thinks velocity is a target or a measure of progress.
Someone (often a manager) tries to compare teams.
Teams or management confuse team measures with project status measures.

1. Velocity is a point-in-time measure of capacity, not progress.

Velocity is easy to measure, especially if you use story points to estimate. However, velocity is not the same as person-hours or person-days and changes with the state of the code base, the tests, and the technical capabilities of the people.

Here's why velocity is not consistent even within a team. Imagine you are going for a walk in the park. Your circuit in the park is 4 miles. On a sunny day in June, you maintain a brisk pace of 4 miles/hour. Your walk takes an hour. Now, imagine that same park in January with ice on the path and a 20 mph wind. You can't walk at the same pace as you did in June. And, if you're like me, you'll stop part of the way through because it's way too cold.

You still have the same distance. However, your speed differs depending on the terrain and your comfort with the weather.

It's the same problem with a product development team. When the team works on a well-understood code base with great tests, they have some capacity. Change anything—the code base, the tests, the people—and their capacity changes. Velocity is useful as a capacity measure for this team, on this project, now.

2. Teams are not comparable and here's why.

Teams don't work on the same code base when they create features even for the same product. Some teams have more UI needs, which means they might need to use paper prototypes with their customers or product owners. Other teams might need to monitor database performance as they complete features.

The risks for each team are different. Even if the teams estimate the same way, or if they use one-day stories, each team's work is different. Since the work isn't comparable, the teams aren't comparable either. You can't compare the teams in any meaningful way.

On the other hand, you can look for a cadence of throughput—finished features—and ask the teams to monitor their cycle time, how long it takes to create a feature.

In my experience, managers want to see finished product as often as possible. (Yes, that leads to estimation traps.) If they do, the question of comparing teams disappears.

3. Team measures contribute to project status, and here's how they are different.

When teams measure their cycle time or their cumulative flow, they learn about where they are now. When teams demonstrate finished features, or show the product backlog burnup chart, or show what's finished but not released, they show and explain their project status.

Agile approaches allow us to see a team's state. And, they help us see the product evolve and the progress towards being done.

If you are having trouble with measurements in your agile project, do check out the two measurement chapters in Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.

Johanna's Books and Workshops

If you have seen measurement traps, check out my new book, Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. The book is available in ebook and print forms. I wrote the book so you can decide how to use an agile approach, for your team and your context.

I have just a few spots remaining in my writing workshops:

These workshops start in January. Email me with questions. I would love to see you there.

New to the Pragmatic Manager?

Are you new to the Pragmatic Manager newsletter? See previous issues.

Here are links you might find useful:
* My Books
* Online Workshops
* Coaching
* Managing Product Development Blog
* Create an Adaptable Life
* Johanna's Fiction

Till next time,
Johanna