Good Agile Metrics or Working Software

As agile coaches, we use and value metrics as an objective way to evaluate the strengths and weaknesses of teams that we are coaching. When we first engage with a new team, we conduct an agile assessment of the team’s capabilities that results in a baseline metric that pinpoints exactly where we should focus our transformation plan.

The assessment considers team skills in areas like defining the product backlog, planning and coordination, and ability to deliver product. As we progress through our coaching plan, we will conduct additional assessments on a schedule to gauge progress against the baseline, and use the data to tweak our plan of action.

We also use metrics to report fundamental agile stuff to our client’s management team via weekly status reports. These metrics demonstrate team capabilities around things like stable velocity, a team’s ability to finish the sprint and deliver what they said they were going to deliver, and whether teams are stable and members are consistently available to focus on sprint work.

So we view metrics as an important and meaningful tool.

But occasionally we will see situations where the metrics actually become the defining measure of progress and the definition of team success. ScrumMasters worry that if their metrics are not good then “heads will roll” and trouble will ensue. Stand-up meetings become all about discussing what the team needs to do to guarantee favorable agile metrics instead of being about finishing tasks, completing stories and meeting commitments. The team is admonished to log more hours against their open tasks if the sprint burn-down deviates slightly above the ideal line.

Don’t lose sight of the real measure of success, which is producing working and tested software consistently at the end of every sprint. Metrics can help guide you to stay the course for your agile journey, but should never become the primary measure of whether a team is really agile or not.