By: Jolly Rajan

When an organization goes through a transformation, the stakeholders are keen to see the results of all that change. The PMO kicks into high gear capturing every data point they can measure and create dashboards (pretty much like the one above). This does help to overload the stakeholders with data, but does little to bring continuous improvements to the change process. The process is of data collection and analysis will be onerous and soon lead to data burnout.

To get started, we recommend that you keep it simple. And it is important to recognize the intended outcomes behind the metrics. Here is a metrics starter pack for programs who are new to agile and is looking for some leading and lagging indicators for program health and team level diagnostics.

Program Health

These metrics are usually radiated outwards. Potential audience includes stakeholders, other programs and customers.

Are We Working On The Right Thing?

Features represent the smallest unit of end to end user value. They are composed of many stories that together completes an activity performed by the user. The Features in play now and where they are along the path to completion provides insight into whether we are working on the right thing. Keep an eye on whether there are too many Features in progress, or whether the Features are too big.

Are We On Track?

Use the Release Burnup when you want to communicate where you are at the program level. This metric doesn't dive into the details of what is being worked on, but shows the trend of where you are headed with respect to the current total scope. Actions will be needed if the scope and completion grow at different rates or if the scope fluctuates from sprint to sprint.

Are We Delivering Quality Code?

Agile teams focus on Escaped Defects - the defects that are identified after the stories meet their Definition of Done (DoD). These could also be Production defects. High performing agile teams focus on zero defect code, no known defects exist. Even in zero defects code, look to see whether too many defects are identified after the stories meet DoD. Another code smell is where all the defects are identified (and may be fixed) towards the end of a release.

Team Diagnostics

These metrics can be used by teams for continuous improvement. They can be valuable data points to power retrospectives.

How Fast Is the Feedback Loop?

This is one of easiest and most valuable metrics that a team can track. Cycle time may be defined slightly differently from one organization to another. But the core idea is to measure the time elapsed between the story getting to a READY state and the story getting to DONE. Reducing this time is the key to increasing feedback and hence quality. Even if you try to reduce cycle time by creating smaller stories, it is a win-win.

How Is The Flow Within The Team?

Improving the flow of stories from READY to DONE is key to reducing cycle time. Are there too many handoffs? Are there wait states that can be eliminated? Where are the bottlenecks? Are all the stories getting completed towards the end of the sprint?

How Is The Team Throughput?

Throughput is a measure of what the team gets done in a specified time frame. It could be a sprint if you are using Scrum. Predictable throughput is much more important than a continuously increasing one. Throughput for a new team will increase for the first few sprints when the team goes through the storming phase. As the team settles into the norming phase, we should be seeing more predictable throughput. Warnings signs include stories spilling over to the next sprint regularly or spikes in throughput coinciding with release windows.