Skip to content

Better Metrics for Measuring Agile Development Success

Posted in Agile, Business Strategy, Experience Design, Leadership, Product, and Technology

metricsThe term agile was first coined for this in 2001, in the Manifesto for Agile Software Development.  According to the manifesto Twelve Principles of Agile Software, their highest priority is to “Satisfy the customer through early and continuous delivery of valuable software.” Which is a good thing, especially in today’s rapidly changing marketplace. Another one of their principles is “Working software is the primary measure of progress.”

Agile development is the fastest growing development methodology be it a variant of Scrum, SAFe, Lean and/or Kanban or any combination of these. More organizations today follow Agile or a hybrid of Agile than any other development process. The main reason organizations adopt Agile is the accelerating product delivery, enhancing their ability to manage changing priorities and project visibility.

As agile is grabbing the attention of the C-suite, there is an increased interest in measuring agile success as part of the overall business. For several years now the top three measures of successful agile initiatives have been on-time delivery of projects, product quality, and customer/user satisfaction. But in a recent blog, Examples of Outcome-based Metrics, they share better metrics for measuring Engineering success:

Feature Usage

Before the feature is developed, identify the measures that define what success will look like for that feature. In addition to putting focus on the outcome, this future-looking approach also gives the team the ability to engineer in a way to measure its usage. It gets them thinking about who is going to use the feature and for what benefit, about how the customer will define the success of the feature. Thinking about results in these terms helps eliminate situations in which a team has worked hard to develop new features, but no one cares: a situation that demoralizes the engineering team. The resultant data also has the benefit of providing functional areas across the company with the insight they need to maximize the business benefit after initial release – whether it’s additional development that is required, more training or promotion, or any number of other paths.

Product Scorecard

Use a product scorecard to review the business outcomes of the engineering organization. By having stakeholders from different parts of the company such as Customer Support, Sales, and Professional Services provide inputs, you put emphasis on the results of what has been developed. Questions that serve well in this capacity focus on things like how easy the feature is to implement, how easy is it to support, how competitive it is, how is the quality, how satisfied are customers, and how complete is it compared to where it needs to be.

Cycle Time

Cycle time measures from the time work starts until the time it’s finished – how quickly an engineering team delivers value to the customer. This is not measuring velocity, but instead of looking only at speed in the context of customer value. For instance, if you’re building out a new vertical area for the product, or if you need to work on stats for how quickly you can get something back to the customer – those are the types of things to look at in order to evaluate engineering performance.

Lead Time

The Lead time metric measures from the time a feature is added to the backlog to the time when the engineering team has the capacity to start working on it. It’s essentially how long the feature is aging in the backlog. Measuring lead time can provide insight into engineering team capacity and other ways to attend to a roadmap. There’s value, too, in identifying features and functionality that have aged out because that can help the team recognize misaligned priorities. Looking at lead time can provide insights that generate executive conversations about how investments are being made in the company and what’s really important.

Whichever metrics you use, make sure you consider the energy you’ll need to expend tracking them. Can the data you need be collected easily? Make sure that the return you’re getting warrants the effort. And even more importantly, make sure that the metrics you choose ultimately tie back to growth. If it’s not about increasing the revenue, achieving high customer satisfaction and growing the business, then why track it?

We will be talking about this and more at the UX Boot Camp for Agile Development October 15 in Santa Monica, California. Early Bird Special price of $299 ends September 15.

agiledevelopment orange

Be First to Comment

Leave a Reply

%d bloggers like this: