Avoid output-based Agile metrics and embrace outcome-based ones.

We have seen many productivity metrics used in the Agile world. To begin with, Velocity, Escaped defects, Burndown charts, Defect ratio, etc. These are all output-based metrics, and it is not connected to any outcome.

Above all output-based metrics can be easily manipulated and inflated. It is better to use the following metrics to measure the health and productivity of the projects.

Testing Lead Time

We have seen an elaborate cycle for various testing in highly regulated industries like the Financial and Pharmaceutical domains. It starts with Quality testing (QA), Integration testing (SIT), User Acceptance Testing (UAT), and product testing before it is released to end users. Sometimes, this testing phase consumes more time than the overall execution of the project.

Involving the testing stakeholder during the upstream process than the downstream will reduce the long testing phase.

Rework Effort

Along with the elapsed time, we need to measure the rework effort due to bugs in various testing phases. Just keeping a tab on the bug count will not help. Instead, we need to measure the time and effort spent on fixing the bugs. These rework efforts can spread across ST, SIT, UAT, and production.

Lower rework effort is a powerful indicator of the health of the project.

Deployment Time

It is pivotal to measure the time it takes for a feature to move from creation to production. This metric tells us how agile the team is and how tuned is the engineering process to help turn a feature into reality. Less deployment time is inversely correlated to the team's stress.

Long deployment time during the weekends is not a good sign productive team.

Deployment frequency

To get an idea of the deployment frequency, we need to ask the team how frequently you make a production release? Is it daily, monthly, quarterly or yearly.

Faster deployment cycles will help understand how fast the team can push the backlogs.