15 agile metrics that matter for success

“To measure or not to measure?” such a paraphrase of Shakespeare’s Hamlet never goes amiss for the project managers who seek to figure out what can improve development lifecycles. This is about Agile methodology and the value it can bring to software development companies. It is taken for granted that Agile development increases overall productivity. Just adopt it and use Agile metrics to make your project management increasingly effective. 

However, things aren’t as clear-cut as they might seem. Agile development metrics are numerous: which of them are worth using and for what? Is there a risk that Agile performance metrics can become a thing in itself having no positive effect on productivity? Let’s find the right answers to the questions together to make sure that Agile project management metrics really matter. 

What is Agile methodology in project management?    

The history of Agile began in the 1990s when a range of efficient development methodologies such as RAD (1991), DSDM (1994), Scrum (1995), Crystal Clear & XP (1996) started becoming popular among software developers. In 2001, when 17 experienced developers gathered together in Utah, United States, they created the so-called Agile Manifesto, which included four main ideas and 12 basic principles of Agile methodology. 

Not to repeat those ideas and principles, we’d like to focus on some key aspects of Agile. 

1. Visual control. Most often, all project participants use colored cards (post-it notes) while completing the project. Each color indicates one or another stage as well as the degree of completion of the stages. Visual control clearly illustrates the current state of the development process for the entire team.  
2. Process transparency. When a project leader, a team, and a client all work together, neither a misunderstanding of the project’s purposes nor data loss can happen. Such transparency means that any problem can be solved almost immediately with the best possible solution.  
3. Adaptable management. Any Agile manager is unlikely to be the one who is just telling people what to do. This is a leader who sets the direction to efforts and determines the rules of collaboration. In other words, Agile management is adaptable. 
4. Sprints and daily meetings. The entire development cycle is divided into many “sprints” allowing a team to complete particular tasks. A sprint, therefore, is a short period limited by certain deadlines. Sprints let a team assess the achieved results. Each sprint is summarized with a daily 15-minute meeting when each team member has to answer the following questions: 

• What did I do yesterday? 
• What should I do today? 
• What interrupts my work? 

Agile project management is popular in the IT sector mostly. However, many companies from other sectors start expressing a keen interest in the Agile methodology today. Education, marketing, business, state governance all can adopt Agile for better project efficiency. The following few use cases where Agile management is already in use can reveal how this methodology is covering diverse organizations: the New Zealand Government, the Norwegian Government Pension Fund, Oreo (world-famous cookies), Aviasales (air tickets), Hewlett-Packard, etc. 

In addition to a clear idea of the Agile methodology, it is also worth understanding the types of Agile quality metrics. But more on that later. 

Why do metrics matter?

“Metrics are evil!” is the opinion that happens to be not so rare amongst various coaches on management efficiency. Why so? Many of them believe that metrics as such can determine the desired effect. Tell me which metrics you use to measure me, and I will demonstrate to you the expected performance, as they say. As a result, metrics are getting better while productivity remains the same. Don’t die wondering, team members. 

What if quality measurements keep going, but metrics are kept in secret? That would be contrary to the Agile principles: transparency, self-organization, adaptable management, and the like. A decent way out is to be in something different. The reason for the intolerance mentioned above, however, is in the wrong metrics applied. 

Managers know a lot of helpful quality metrics. Moreover, they often invent individual ones that seem to be able to shed more light on the working process. But intuitive approaches are promising not for every occasion. Viable versions’ deployment time, numbers of comments from customers, staff to workload ratio, as well as many other “creative” metrics sound reasonable for managers. But what about engineers, testers, architects, analysts, and clients? What would they say in response to the managers’ creativity in metrics? 

Our sincere advice to project managers: regardless of how brilliant your intuitive metrics might sound, try to refrain from hand-off judgments. Go and ask your team which measurements matter for them. Do what one of Toyota’s agile principles suggests: Genchi Genbutsu. Collectively developed quality measurements can bring much bigger value to your workflows. Brainstorming on metrics is useful per se for teams. This is as crucial as both collaborative planning, and group assessments of results are.  

The following examples of questions can give some ideas on what is worth discussing with your team: 

• How do we know that the process is getting better? 
• What will change when we improve efficiency? 
• What should we regularly measure to make sure we are on the right path? 
• How can our customers notice our improved efficiency? 

These and similar questions can help you realize which quality metrics make sense just for your team. At the same time, never underestimate the collective wisdom of the global community of Agile project managers who have developed universally recognized performance metrics. All types of Agile development metrics are generalized by the three basic Agile methods worth knowing. 

Types of Agile quality metrics

Project management methods are numerous. Many of them include various quality metrics. Some of them reflect Agile productivity in diverse facets. The most popular Agile management methods are Scrum, Kanban, and Lean. They represent consolidated typing of Agile project management metrics, as the majority of progressive project managers believe.  

Scrum 

Intensive quality control of the working process makes Scrum differ from the other Agile methods. The two Japanese gurus of strategic management Hirotaka Takeuchi and Ikujiro Nonaka who first described Scrum used to call Agile project management the “rugby approach” where Scrum was a scrimmage.  

The method is based on sprints with certain deadlines. After the sequence of sprints is over, a client is to receive improved software. The working process of a single sprint includes several stages: 

• Determining the amount of work
• Arranging daily meetings to let team members sum up subtotals
• Demonstrating achieved results
• Debating sprints to figure out both successes and failures

Scrum is suitable for complicated software projects when iterative development is practiced. Scrum provides better control on each working stage in a holistic project agenda. Continuous delivery of software to customers is a hallmark of Scrum. Such types of Agile quality metrics as burndown charts and the team velocity belong to Scrum metrics. 

Kanban 

The essence of Kanban is in both the transparency of processes and uniformly distributed workloads among project participants. Kanban motivates people to constantly collaborate. Self-improvement and learning are inherent in Kanban as well. Kanban relies on the following basic principles: 

• Total visualization of everything related to the project. This allows detecting errors to address any gap in time.  
• Completion of each task is performed by the entire team. This helps balance the common effort to avoid uneven workload distribution. 
• The time to complete all tasks is tightly controlled. Time-saving optimization of the process appears as a result. 

Kanban is much younger than Scrum, being not less popular, nonetheless. A cumulative flow is one of the typical Kanban metrics.  

Lean 

The entire working process is divided into many smaller work packages in Lean. In some ways, they resemble Scrum sprints. But in contrast to Scrum, Lean’s packages evolve independently from each other. Besides, they have their individual workflows with corresponding stages such as planning, development, testing, deployment, etc.  

Lean has no exact deadlines for work packages in contrast to Scrum. Moreover, Lean allows completing different tasks in parallel, which improves flexibility and saves time. Avoiding irrelevant activities is another feature of Lean. Cycle time and lead time are common quality metrics for Lean.  

You might be interested in the following articles:

What is a traceability matrix?

15 Agile quality metrics that matter

Whatever method of Agile project management is selected, nothing prevents your team from using those Agile quality metrics that supposedly belong to other Agile methods. Improved quality, along with better efficiency, is your goal at the end of the day. And the ends justify the means, as Jesuits used to say. Below we indicate 15 viable quality metrics that are worth your attention if Agile project management is what facilitates your development process. 

Sprint burndown

This is a Scrum-related metric that helps figure out whether different tasks are completed within a single sprint. Time and remaining work are the two parameters of the metric, while the measurement units are working hours. A sprint burndown chart shows how your team is meeting the desired sprint results in terms of completed work.  

Velocity

This is about the average work your team does over several iterations in a sprint. The more iterations the team executes, the better accuracy the metric provides. Velocity helps forecast the way your working process tends to go. This metric shows how consistent your performance is. If velocity goes down, something wrong is happening with your process. 

Lead time

A period between the order for software and its actual delivery to a customer is the lead time metric. In other words, the entire development process goes under the lead time. Every related work is included in it: prototyping, designing, bug fixing, etc. It is crucial to know how long your development process lasts. 

Cycle time

This metric can be considered a part of lead time but in a narrower sense. In contrast to lead time when the whole process is counted, cycle time measures just a period when a particular task is actively developed. Once the entire development process includes numerous tasks (aka cycles), this metric shows how much time you spend for a single cycle. 

Code coverage

This metric demonstrates the quality of programming when a particular code test reveals how completely the code of a program is executed. The higher the code coverage is, the fewer bugs are potentially present in raw code. Running such a measurement through every build, you can track your coding progress. 

Static code analysis

This is a sort of source code review performed either before debugging or together with it. Static, in this case, means that code is checked before a program runs. Such a kind of code analysis can be made either manually or via special tools. The code examination goes against some special coding guidelines and standards (ISO 26262 and the like). 

Escaped defects

This metric shows those missed bugs that appear in a released product. Once a bug in production is always a problem, any sort of bug detection is crucial for a team. The escaped defects metric helps assess the quality of raw software. 

Failed deployments

This is another quality metric that shows the number of deployments when a sprint is over. This helps assess both the entire production environment and the development lifecycle for each particular product. The quality of testing can also be estimated through such a metric.  

Cumulative flow

This metric belongs to visualization inherent in Kanban mostly. A cumulative flow chart can show the status of each work (sprint, version, task) over a particular time frame. It helps understand how stable your workflow is. This metric makes flow bottlenecks visible for your team to see which task needs to be fixed. 

Net promoter score

This metric reveals how loyal your customer is in terms of your products’ promotion. This is about word of mouth and other relevant means your customers use to recommend your product (service, company) to other customers. It provides an outside perspective to look at what you offer through the lens of potential clients.  

Value delivered

This metric uses either dollars or other value units to assess how valuable the delivered features are for your customers. You can track certain trends taking place over your development process with this metric. If an upward trend goes, you deliver valuable features. A downward trend, on the contrary, hints at the decreasing value of your software for customers. 

Epic and release burndown

This metric is similar to the sprint burndown one somehow. However, more detailed info on various types of work can be found via this metric. Completed works, remaining works, additional works, as well as other types of work taking place in a sprint can be estimated in terms of the achieved progress.  

Blocked time

When a team member stops fulfilling a task for some reason, a corresponding blocker card appears on the board. When working on the task starts going on, the blocker card is removed. By calculating of both the number of blockers and the time spent under each blocker, you can assess unproductive periods that occurred over a sprint.  

Quality intelligence

This is similar to code analysis. However, the quality of code is considered in a broader sense with the metric. This applies to some changes made in the code before testing. The metric helps us understand what should be done to avoid a decline in quality. 

Throughput. This metric is used to measure the working capacity of the entire team. An average number of tasks fulfilled per iteration demonstrates the performance of all team members in your workflow. Throughput shows your productivity with score points dedicated to iterations, sprints, or other time units. 

Conclusion

It is always worth remembering that theory and practice are different things. Using new metrics and technologies is a challenge for your team. This is because achieving better efficiency is a sort of individual stuff. Agile quality metrics are neither a panacea nor a guarantee of success. They help find the right policy and determine signposts on the way. 

Project managers have to generate new ideas on how to make workflows more productive without compromising quality. The entire team has to accept new approaches to constantly changing market conditions. Agile development, in general, and Agile quality metrics, in particular, are not the only silver bullet available for better project management.  

At the same time, Agile software development metrics really matter if Scrum, Kanban, Lean, and other Agile methods are not just empty words for developers. Agile metrics are able to add value to the working process, and they do it if those who use Agile are aware of where and when Agile quality metrics should be used. 

Contact us to know more about Agile methodologies since Agile quality metrics have long been a well-adopted practice for our team.