Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Nov 21, 2008 — Enterprise Agile Planning expert

Going Down the “Metrics” Rabbit Hole

Enterprise Agile Planning


When we are introducing Scrum to a new environment, we often get into debates, sometimes heated, with people who question the validity, truth and/or value of a particular agile or Scrum principle. My general feeling is that any time spent having a philosophical argument with a client/Product Owner is time not spent adding value.

In my experience, Product Owners and their organizations care about results. Rather than trying to convince someone of a particular point with a carefully thought-out and bulletproof argument (which probably won’t work), figure out what result the Product Owner wants. If the PO says he wants “metrics,” solicit him for the measure he considers most important. Ask the PO what he wants to measure and why. Going down a philosophical rabbit hole will not get the PO or the organization any closer to embracing Scrum. Getting results does that.

As a math geek who spent years gathering, interpreting, revising, and deriving all sorts of fancy “scientifical” metrics for measuring everything you can imagine, I have found that, more often than not, metrics obscure our picture of reality rather than clarify it. There is only one metric that matters: “working product as a measure of progress.” Everything else is, in my opinion, academic. Actually, there is one other metric that matters to business owners: ROI. But then I would put an experienced, high performance Scrum team up against anyone in that category and confidently guarantee greater ROI than a team using traditional methods.

Nonetheless, the metrics question is one of those philosophical rabbit holes that comes up often. Business people are conditioned to expect, value and trust metrics even if they don’t know how they’re derived, what they actually mean or how useful they really are. Often times, the value of the metrics is really only perceived.

Our goal is to determine what it is the business actually wants to measure and figure out how to make such a measurement in an agile context that does not interfere with the team’s ability to meet its sprint goals. What that means in a specific context depends on the situation.

The point is, though, rather than trying to convince the business that a particular metric is “not agile” or useless, we should adapt to the circumstances and try to find a comparable measurement we can make that will satisfy the underlying need. We should NOT do so, however, at the expense of the fundamental principles of agile development and Scrum.

Jimi Fosdick

Download the PDF version: Going Down the Metrics Rabbit Hole_blog


More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us