# Top 10 Agile Metrics for Successful Projects

9K
• by Deepti Sinha
• 19th Feb, 2021
• Last updated on 17th Mar, 2021

A long-standing platitude says: “What gets measured gets done”, and in today’s context the phrase is upgraded to “What gets measured gets improved”. Either way, the emphasis is on measurement. In this article today, we will learn some basic agile metrics that can be used by the development teams to access and improve development, and optimize ways of working. With a strong competitive market, there’s a need to stay ahead of your peers, and provide optimal solutions.

Here, we will discuss 10 agile metrics that can help teams carve their path towards success.

## What is an agile metric?

Just going the agile way or adopting agile practices won't help much if the output is not measured. Agile metrics help to monitor productivity and quality across different phases during development. Metrics are standards of measurement that help the team to keep the performance in check and help to expose any gaps in performance early.

## Why should the teams use agile metrics (Benefits)?

There are multiple benefits of using Agile metrics. Let’s first take a look at some questions that get answered:

• What are the problems that need to be addressed?
• Is the team on track?
• Is the value being generated out of the efforts invested?
• Is the team improving?
• Is the team working on the right things?
• Are the deliverables abiding by the quality standards?

## Top Ten Metrics

### 1. Sprint Burndown

This is one of the basic and most popular metrics used to measure the work remaining during the execution of the sprint. The graphical representation through a chart helps to keep a check on the rate of work completion, and how much needs to be accomplished.

The chart comprises of X-axis and Y-axis, where the horizontal X-axis denotes time/no. of days and the Y-axis denotes the total amount of work. The total work can be estimated both in terms of man-hours or story points. The burndown helps in the prediction of whether the team will be able to complete the target sprint goal in the said sprint timeline.

Image source

### Components in the Burndown Chart:

• Total Estimate – The output of the sprint planning is in the form of work items or user stories that have been broken down further into tasks. Each task has an estimate with the unit in hours. The sum of the estimate from all the work items constitutes the total estimate which is represented in the Y-axis.
• Remaining Effort – With each passing day in a sprint, the team will be burning efforts on the tool according to the work completed. This creates a slope in the chart as the remaining effort gets decreased towards the end. This is the component that gets tracked in the burndown down the chart.
• Total Days – When the sprint length is defined, a set number of days are locked as the length. On the chart the total no. of days is represented on the X-axis. If there’s a holiday/weekend, the chart will show a flat line as the team will not burn any effort. This, again, depends on the tool and its customization. Some tools omit weekends and just represent the working days.
• Ideal Effort – It is represented through a diagonal line cutting across the chart and represents the ideal burning pattern. This is usually an auto-generated line to guide the team.

### 2. Velocity

Velocity is one of the powerful metrics in agile which is simple and easily adoptable. It is the sum of units delivered in a sprint, which is usually in story points. For example, if a scrum team commits 30 points in a sprint and delivers 28, then the velocity for that sprint is 28. As the team matures, the average velocity is calculated to predict the future capacity for the sprints. Velocity helps in getting the teams to predict correctly the amount of work that can be completed. If the average velocity of the team is 30, they know they can finish 300 story points worth of work in approx. 10 sprints.

Velocity is not the measure of productivity, as it is just an average calculated unit based on the last few sprints. There might be fluctuations in the velocity due to an unstable team, holidays, legacy code, etc. It should be used as a planning tool for defining the work in a sprint. Each teams’ velocity is unique, and no two teams should be compared in terms of velocity.

### 3. Cumulative flow diagram

CFDs are stacked area charts that represent the number of work items in each column for a particular period. The lowest layer specifies the number of items in the completed state. The graph provides an essential way to envision project development and supports to visualize any possible difficulties. It represents the count of Backlog items on the Y-axis and maps them according to the state on the timeline represented on the X-axis. The cumulative flow diagram can be customized as per category or as per status.

### 4. Release Burnup

The Release Burn Up Chart shows the current work progress against the total work planned. It also displays the total planned work, and the total work accomplished to date. One of the important aspects of this chart is the scope line which captures the deviation between the release start and the end dates.

The horizontal axis (X-axis) represents the time; it can be sprints, phases, or just the timeline representing the completion of a quarter or the project or just a particular period in discussion.  The vertical axis(Y-axis) represents the total story points in the backlog.

The Burnup charts make it easy to read the total completed work, the scope changes, and their impact on the timeline, and the remaining effort to reach the completion. Along with this, it also helps in forecasting to achieve the release plan.

### 5. Control Chart

As per Wikipedia “Control charts, also known as Shewhart charts or process-behavior charts, are a statistical process control tool used to determine if a manufacturing or business process is in a state of control. It is more appropriate to say that the control charts are the graphical device for Statistical Process Monitoring.”

A control chart is used to monitor quality regularly. It helps to measure the impact of process change, or any team composition changes. It supports to evaluate the team’s historical performance and forecast the future work pattern. This helps the teams in setting up the goals.

The Control Chart displays the Cycle Time or Lead Time for your project or sprint. It takes the time consumed by a respective problem in a certain status and plots it over a stated period. A Control Chart helps you categorize whether statistics from the existing sprint can be used to govern forthcoming performance.

Lead Time metric originated from the manufacturing method, more specifically from Toyota Production System. It is the total time elapsed from the initial request being made by the customer to the final product being delivered. When talking of software development, it is the movement of a requirement from ‘New’ state to ‘Completed’ state. In simple words, it is the time between the start and finish for any work item.

For example, when you stand in a queue to order a burger, the time between when the order is placed and the time when the burger is received is the Lead Time. In Scrum, the lead time is defined as the time it takes from a requirement being added to the backlog to when it’s ready for delivery.

### 7. Blocked Time

During the execution of the sprint, there might be situations that block the way of smooth sprint delivery. For example, an environment issue where the test cannot be performed on the code on the higher environment. Or a case where a technical dependency is blocking the way for the development team. The reasons can be countless, but it is important to capture the total time the team got blocked in the entire sprint. The scrum team can either block the task or raise a block card on the system/tool. The management can pull the real-time report on the blocked cards and help the team move forward. This should also be a part of the retrospective discussion for further improvisation.

### 8. Escaped Defects

Not every product delivered is error-free, as although multiple rounds of testing are done still some of the defects go unnoticed. They are found by the customers after the release date. These are termed Escaped defects. The cost of fixing a defect increases considerably the later it is found. The appetite for RAG(Red/Amber/Green) count/percentage varies across organizations. Getting more than 3 escaped defects can make the report RED for some. It is measured by the number of issues (bugs, defects, etc.) found in the product once it has been delivered to the user.

### 9. Story Completion Ratio

When the team collectively comes up with the work items committed in a sprint during the sprint planning meeting, they come up with a list of user stories to be completed. The story completion ratio is the percentage of the total no. of stories delivered in a sprint against the committed ones. So, if a team commits 10 user stories in a sprint and delivers 9, the story completion ratio will be 90%.

• Story Completion Ratio = (Total No. of Stories Delivered / Total no. of Stories Committed) * 100

This can also be used in the retrospection as a discussion point to identify the root causes and solutions for better delivery.

### 10. Net Promoter Score

The Net Promoter Score is an index that measures the readiness of clients to commend a company’s products or services. To calculate NPS, one can ask, “How likely are you to recommend us to a friend or colleague?” and score the answers on a zero-to-ten scale. Based on their rating, customers are then classified into 3 categories: detractors, passives, and promoters.

#### Conclusion

Metrics help in building up the organization by analyzing the results and striving to make it better. They provide quantifiable awareness into the team's performance and deliver assessable goals for the team. Metrics helps the team to define a way for a better customer experience and a healthy work environment. The organization should opt for only those metrics that support the systems to flourish and not to counter the individuals or the team.

### Deepti Sinha

Blog Author

Deepti is an Agile Coach by profession and Freelance Trainer with over 11 years of industry experience working primarily with healthcare & finance clients in delivering business. She has played a wide variety of roles in the graph of her career, whether it be, management, operations or quality. She likes reading fiction, management and loves to write her experiences. Her colleagues mostly describe her as very detail oriented person with a knack of creativity and imagination. And yes, she loves feedback more than her coffee!!