“Measure Everything That Results In Customer Satisfaction”. 

“You cannot improve what you cannot measure”

Traditional waterfall-based metrics may not be suitable in iterative and incremental product development. The reason is, they will be focused on milestone-based and more of output focused metrics. It is better to track value-based and outcome-focused. This article helps you to explore some of the Agile metrics. 

What are Agile Metrics?

Agile metrics provide awareness into various aspects of Product development. This helps to assess the current status and compare to the desired status and identify any improvements to become better.

Agile Metrics can be broadly categorized into following:

  • Product Metrics
  • Process Metrics
  • People (Team) Metrics

PRODUCT METRICS:

Customer Satisfaction (NPS: Net Promoter Score)

NPS helps to check customer satisfaction in a quantifiable approach. Captured throughout the incremental releases so there will be scope to improvement in the customer satisfaction through adaptation of the feedback

NPS rating will be taken from 1 to 10 where 1 to 6 rating is considered as Detractors, 7 and 8 ratings are considered as Passives and 9 and 10 are considered as Promoters. Below is the formula for NPS: NPS = % of Promoters – % of Detractors. The more positive NPS value is the better. If the NPS trend is moving in an increasing direction, it means your Product’s customer satisfaction is improving.

Time to market

Helps to see how often the value delivery is happening with respect to market and customer expectations. This can be tracked based on the time between every Production Deployment. The more it is increasing it shows the time Time to Market is longer.

Business involvement

Helps to measure the gap between business and IT/Development teams. The more involvement will lead to more collaboration, faster clarifications clearance, enhanced transparency. You can measure it at Sprint level or Release Level based on the number of Business touchpoints. An increased or stable number of touchpoints is healthy. 

Working software

Helps to measure how value is delivered in timeframes through working software. This can be measured at the end of every Sprint based on the number of Product Backlog Items that meet the “Definition of Done”. However, the size of the Product Backlog Items may differ so you have to calculate accordingly. 

Escaped defects

Can be captured for every production deployment and it helps to improve quality. Calculate a number of defects identified in the Production environment. If the number is increasing, then it is an alarming situation. You need to check your Definition of Done and make it stronger to address the issue of increasing escaped defects.

Earned business Value

Helpful to measure how business value is delivered. This can be captured at Sprint Level or Release Level. All the Features will be assigned a business value weightage and using a formula you can identify % of business value for every product backlog item. 

PROCESS METRICS:

Cycle time

Helps to have an idea of how the stories are being completed in a Sprint and can come up with ways to improve the speed by splitting the stories if the cycle time is more. Taking average Cycle Time for every Sprint and try to reduce it by optimizing the processes and the size of the User Stories.

Cumulative Flow Diagram

Helps to see where the bottlenecks are and address them. Based on the bottlenecks, WIP (Work In Progress) limits can be adjusted.

Value Stream mapping

Helpful to see value add and non-value add activities in the work flow and improve the process efficiency by reducing the non value add time activities. This helps you to identify the process efficiency.

Burndown/Burnup charts

Burnup helps to track the work remaining and Burnup helps to track work completed. These charts can be used at the Sprint level or release level.

Failed Deployments

Can be measured for every product deployment and helps to improve deployment process and efficiency. If a production deployment has to be rolled back, then it can be considered a failed deployment. Frequent rollbacks represent poor deployment processes, so they need to be improved through automated deployments and regression test suites. 

Downtime

As we deploy incrementally it will be useful to see how much downtime is taken for every deployment and come up with an improvement plan. Aim should be zero downtime. Accordingly improve your deployment practices.

Technical Debt metrics

Every Sprint and Every release these metrics can be measured so that some technical practices can be introduced for future release to address the issues as an improvement action plan. Some of the metrics include: Open Vs Closed bugs, % of High severity bugs, Bug burndown, Defects per KLOC

PEOPLE (TEAM) METRICS:

Velocity

Helpful to see how predictable the team is in terms of value delivery. It also helps to forecast the remaining work and remaining Sprints. Do not use Velocity for comparing the Teams! Amount of work that meets the Definition of Done can be considered as Velocity of the Team. For example if the Developers pulled 25 Story Points worth of items into the Sprint Backlog, and if they completed 23 Story points worth of items that meet the Definition of Done, then the Velocity of that Team is 23. 

Team stability

As agile teams are long-lived, this is useful in terms of measuring their collaboration, skill enhancements etc factors. Number of changes in the Team in a given stipulated time duration can help tracking this metric.

Say-do ratio

Helps to see how stable the predictability of the team. Captured at the end of every Sprint. This is the difference between the amount of work planned during the Sprint Planning and completed by the end of the Sprint (Example: If the planned work is 30 Story points and if the team completed 20 Story points then the say do ratio is 30-20). The higher the difference is alarming. So, you need to identify root cause analysis and address them.

Cross-skilling

Helps to see “I” shaped and “T” shaped members in the Team. “I” shaped is a person with only one primary skill, whereas “T” shaped person is the one who has one primary skill along with a couple of secondary skills. You can track this for every fixed time duration such as quarterly. 

Trust Factor

Trust is the primary factor to create Transparency within the team. Transparency enables effective inspect and adapt opportunities. So checking the level of Trust within the Scrum Team is always important. You can measure the level of Trust based on multiple approaches such as: Survey with questionnaire, based on the answers the “Trust” factor can be calculated. Another approach is to ask the Scrum Team to rate their “Trust” for the other team members on a scale of 1 to 5 (1 is the lowest and 5 is the highest). Based on the ratings given by all the team members, you can calculate the “Average Trust Value”. Once you know the number, you can identify actions to improve the Trust.