Many agilists, in an effort to defy this trend, affirm that measurements should not be used at all, and that only the production of software itself should be considered the criterion for success.
As the legendary engineer W. Edwards Deming wrote “without data, you’re just another person with an opinion”, I think, on a project where no data of any kind is tracked, it is hard to tell whether you are on track for release and it is tough to optimize something you don’t measure.

What are Agile Metrics for?
Agile Metrics are meant to help teams better analyze and understand their workflow, discover shortcomings, and improve the development process, work quality, product being developed, predictability and health of the team.

Who are Agile Metrics for?
Agile metrics are primarily a feedback loop for the team. Teams should regularly review agile metrics to tune and adjust their behavior, they need to understand how they are doing and use the data to become more productive. Most of these metrics are supposed to be starting points for conversations, they have meaning because of the context around them, and the only people who have experienced and will understand that context are the people in the team.

Now that we’ve covered the basics, it’s time to get into 10 metrics I find useful for agile teams. I will start with metrics that relate to the pace of delivery, value and quality delivered, followed by metrics used to measure satisfaction.

Velocity
It simply measures the amount of work that a team completes during a set amount of time, usually a Sprint or iteration. It is primarily used to encourage consistency and prevent burnout on the team. When calculating velocity, remember that something half done, is not done at all. It is crucial to follow how your team’s Velocity changes over time, Velocity will most likely increase as teams eliminate bottlenecks, learn to work and communicate better, and inspect and adapt on their process. However, don’t expect constant linear improvement. As you track it, look also for any erratic moments. If these become the norm rather than the exception, help the team investigate the root cause, possibly during a retrospective. Moreover, Velocity can be extrapolated to longer time frames for release/quarterly planning as we will see in one of my next posts. Be sure to focus on being accurate and not overly precise and be careful not to compare Velocity across teams because story points and definition of done can vary between teams. This is one of the most misunderstood metrics. A team’s velocity is unique to them, it simply cannot be compared to another team.

Cycle Time
It measures how long it takes something to get done from start to finish. It is a very simple metric that describes how work is flowing into and through a system. Cycle Time tells you how quickly your team can process a piece of work. You want it to be consistent and short, regardless of the kind of work being done. If your work items are user stories and your sprints are two weeks, You want your cycle time to be under two weeks, well under. When Cycle Times are longer than a Sprint, teams are not completing work they committed to and this is not a good thing. Moreover, consistent Cycle Time means you can accurately predict when you will be able to deliver individual pieces of work, whether you are using continuous flow or sprint-like timeboxes. Cycle Time also gets you immediate feedback, as you can see the results of any changes right away. Indeed, when you adjust the system, Cycle Time will either increase or decrease right away, so in a short time you know if the experiment succeeded or failed.

WIP (Work In Progress)
It measures the number of tasks that the team is currently working on. Lots of work in progress could mean the team is switching focus constantly and maybe working as a group of individuals rather than working as a team. It is really important to assess how, as a team, you could collaborate or help each other in moving a user-story out of the window. In such cases, you might find useful limiting work in progress that is simply restricting the maximum amount of work items in the different stages of the workflow. Teams should agree on WIP limits and focus on helping members of the team who get blocked rather than starting new tasks while one of their team struggles. The “Stop starting, start finishing” philosophy is not limited to Lean and Kanban world, it is applicable in Scrum too. Moreover, WIP limits ensure that your team will keep an optimal work pace without exceeding its work capacity.

Throughput
It represents the number of work items delivered in a given period of time, it could be measured monthly, quarterly, per release, iteration, and so on. The value in this metric is that it can be used to track the consistency of delivery from a team and organizational perspective. It can also be used to determine how much software can be delivered for a specific time frame. Indeed, empirical analysis of historical data can be used to forecast delivery performance. The more historical data available, the more accurate the projections are likely to be. It is important to remember that the Throughput strictly counts work items, it does not take into account the fact that they might be of different sizes.

Sprint Burndown Chart
Before starting a sprint, a team forecasts how many story points they can complete in its course. The Sprint Burndown Chart visualizes how many story points have been completed during the Sprint and how many remain, and helps forecast if the Sprint scope will be completed on time. This metric allows you to track closely the progress of a Sprint and it shows how agile your team really is.

Committed vs. Completed
It is the percentage of story points completed during the Sprint divided by those committed at the planning meeting. It provides insight about the team’s ability to predict its capabilities. If the percentage is higher than 100%, it might mean that the team ran out of work during the Sprint and brought forward items from the backlog, the metric indicates the team needs to focus on better planning. If, instead, it is much less than 85%, still the team has to improve their forecats with better grooming sessions, or splitting stories better to improve estimations and using spikes for research. There are several techniques to split stories, check out my post “Splitting User Stories with SPIDR” for inspiration. One common mistake you should avoid is to use this metric to compare teams or to evaluate their performance, this is not the purpose of it.

Release Frequency
The first principle of the Agile Manifesto is: “Our highest priority is to satisfy the customer through early and continuous delivery of working software”. Therefore, one of the aims of agile teams is to deliver in short cycles and this metric can help understand whether teams are really building potentially shippable software. If teams are failing to deliver code to production, then they are failing to meet their primary purpose. This metric gives also qualitative insight into the release process, if it is easy for the team or it requires heroics, and how solid the environments are.

Automated Test Coverage
It captures how much of your codebase is covered by automated tests. Test automation brings speed, efficiency and reliability to testing and it is a pre-requisite to continuous delivery in fast-paced agile development environments, as it contributes to reduce the amount of time required to release working software. This metric can have a crucial role in measuring the effectiveness and accuracy of your team’s automated testing efforts as it can help to reveal parts of the software that do not have sufficient test coverage.

Escaped Defects
It measures the number of defects found in the product once it has been delivered to the user. You can capture this metric per unit of time (per Sprint, or release) and your rate is a constant feedback loop to how your team is doing. It is also a measure of deployed software quality and can provide insight into what went wrong with development or testing in a specific part of the project, and you can use the Escaped Defects rate to know when you need to slow down or improve testing. Spikes or a steady climb in this metric would encourage further analysis as with a high escaped defect rate, even the most awesome product is going to have a lot of unsatisfied customers.

Team Morale
My final metric, not strictly related to the agile process, it’s a look at the team well-being. The ultimate goal of this indicator is to ensure the team is successful. There is a direct relationship between morale and productivity, happy teams create better work, which will deliver more satisfied customers. The difficult step in managing morale is measuring it. It is true that there are some signals not difficult to spot such as an increasing turnover rate. When more people than usual leave your team, it may be a sign of dissatisfaction. However, you can also talk regularly with your team, they can often tell you how they feel. You could have a quick survey during a retrospective with the team writing their happiness scores, using a 1-5 scale or smiley face indicators. Moreover, you can track these numbers from Sprint to Sprint to see the trends.

Whether you use all of the measurements discussed or only a subset, it is important that any solution consider the audience for the data. Make sure you use the metrics as a support to improve the process and not to punish the teams. Always be sure to fully understand and communicate accurately what the metrics are saying, and follow where the data lead. Comparing the evolution for each indicator over time and connecting them to the business metrics will help you empower the teams and achieve the expected outcome.