The week long Assessment helps us to gather important information and insights related to the project’s practices and processes. But that’s not the only information we need. We also need to quantify the data or in other words set baseline metrics to keep the productivity under check. All subsequent metrics values and alerts are calculated relative to this baseline.

An Agile Coach makes recommendations by observing the patterns and trends provided by such metrics. In case the organization chooses to Adopt Agile we can use these metrics as a benchmark for progress in the areas we desire. Effectiveness of the coaching can also be determined by comparing the Before metrics with subsequent After metrics. This from a sustenance point of view is an inspect and adapt strategy at the organizational level.

Collecting qualitative data may seem simpler to some as compared to collecting the quantitative data. But in actual practice its the other way round. It is not just hard but sometimes even risky to collect metrics. With the vast variety of tools available it is actually easy to find the numbers but determining which number matters the most is where the difficulty lies. This is particularly the case during the assessment period when both the team and the coach are oblivious of the team’s stress points. Not all metrics are useful. Following a metrics which is not relevant can actually hinder a team’s progress. For this reason metrics for the project should be selected only after careful consideration of the end goal. In some cases an Agile Coach may opt to gather all the metrics the project allows only to make sure that the information is available when required. The metrics for which you don’t have a reason to collect should be archived with the disclaimer of potential use in the future.

Some common metrics collected during the assessment period are listed below.


  • Lead Time
  • Cycle Time
  • Team Velocity


  • Committed Stories vs Delivered Stories
  • Defects Count over time

Code Base

  • Cyclomatic Complexity
  • Code Coverage

Build and Deployment

  • Build pass/fail Ratio
  • Deployment Frequency