Agile Metrics...To use or not to use?

Metrics are not always harmful in an agile team, but if not used appropriately, they can be detrimental. Agile is a value- and principle-based approach that stresses people and interactions over processes and tools. Agile prioritizes the delivery of working products often, adapting to change, and interacting with customers and stakeholders.

Metrics can be problematic in an agile team if they are utilized to emphasize individual performance over team performance or to encourage behavior that is contrary to agile values and principles. For instance, if developers are incentivized to perform tasks as rapidly as possible without regard to the quality of the code, this might result in technical debt and a delay in the delivery of customer value.

In addition, if metrics are used to hold individuals accountable for outcomes without taking the complexity and unpredictability of software development into account, this can foster a culture of fear and discourage collaboration and innovation. In an agile team, it is essential to employ metrics that encourage cooperation, continuous improvement, and learning, as opposed to metrics that drive behavior that is in opposition to agile values and principles.

Nevertheless, metrics can be valuable for an agile team if they are used to highlight areas for improvement, measure progress toward targets, and facilitate data-driven decision making. It is essential to utilize metrics in a manner that is consistent with agile ideals and principles and that supports the team's goals and objectives.

I recently was on the Mountain Goat Software podcast discussing these topics. In this episode we dive into the metrics that help ensure optimal performance while avoiding incentivizing adverse behaviors. I'll also talk through the three tiers of metrics that are crucial for Agile teams to consider in order to stay on course. I'll also share the tools required to gain a holistic understanding of an individual's performance and how leadership styles and stakeholders influence team-level metrics.

The tiers for metrics to consider if you have none are:

Business Outcomes

  • Time to market
  • NPS
  • Support Call Volume
  • Revenue
  • Active Accounts
  • New Customer Onboarding Time
  • Regulatory Violations

Product Group Metrics

  • Work items completed per unit of time (quarterly)
  • Percent of work in active state vs. wait state
  • Cycle time of work times (idea to done or planned to done)
  • Predictability (% of work items that reach ready when planned)

Team Level Metrics

  • Velocity
  • Backlog churn
  • Work in process
  • Team stability
  • Internal Defect Rate (defects found and fixed in Sprint)
  • Escaped Defect Rate (defects found by others after the Sprint)

Example Scrum Metrics Worksheet

Related Articles

Metrics Drive Behavior...Right?

From the beginning of our existence, we have been surrounded by various forms of leadership. Whether the leadership was good or bad, that is a different question. We can agree though, that good or bad leadership sets things in motion. As I work with various organizations, I encounter the same...

Read More

Certificate of Occupancy

Have you ever been in your building and noticed a “Certificate of Occupancy”? These gems enforce a safe occupancy number that are built around fire codes. How many people could realistically exit this building in the case of a fire? My question, as it relates to software development and Scrum...

Read More

A Metrics-Driven Approach to Agile Planning

Using metrics for long-range planning is a great way to build confidence from your stakeholders that your team will deliver. Metrics and data bring a lot more merit to the table than a feeling or an opinion, but you must be careful to use metrics appropriately or they can do...

Read More