Okay, so as I kept thinking about metrics after writing the last post, it became apparent to me that I had more to say on the topic before moving on to something else.

Let’s go back to the Scrum Guide for a minute here: the word “metric” doesn’t appear anywhere. There’s a damn good reason for that. The only metric that matters is a successful increment of working software. Period.

“Sure,” you say, “but in the real world we need metrics. I track my team’s velocity every Sprint and we rely on a butn down chart to radiate information to stakeholders.” Allow the Scrum Guide to speak once more here:

“Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.”

My own personal disdain for burn-downs has been documented elsewhere on this blog, and I will not repeat it here when you can read it for yourself. I’ve also expressed my liking for release burn-ups, which are also not part of the Scrum Guide, I just happen to like them as a way of ballparking when a release might be ready to go. If my team is mature and releasing every Sprint, I don’t bother with even tracking a burn-up unless I’m asked to forecast when an Epic will be ready for general release.

Metrics are fine when properly deployed, but they can also box the team into predictive behavior patterns that quickly become anti-agile. Be certain of what it is you need to measure and exactly how that metric will be used before you even start to come up with it. Don’t generate metrics for the sake of having metrics, or just because someone asked you for a number. Learn more and proceed with caution, lest those metrics become a ball and chain around the collective feet of your team.