Saturday, February 21, 2009

Metrics in Agile development

Metrics seems to be the part and parcel of any software development project. In typical waterfall development projects, different types of pre-defined metrics would be used across various projects even though each project is different. However when a team migrates to Agile methodology it becomes bit complicated. They get confused about the metrics to choose. This is because as such Agile methods are not prescriptive and freedom is given to the team to invent the ones which adds value to project. This instant freedom makes the team to come up with more questions than answers.

If you are new to Agile and would like to know the metrics to use in your projects, here are some tips

1. Don't try to invent new metrics as soon as you move to Agile, instead use some of the existing CMM and other matrices and use it within an iteration.

For ex: In typical non-Agile companies the metrics commonly used include,
  • Total number of defects,
  • new change requests,
  • resolved defects,
  • total major,minor defects, etc.
Convert them into Agile by using them in iterations. For ex:
  • Total number of new defects found in each iteration
  • New features added to backlog in each iteration
  • New tasks discovered in each iteration
  • Number of resolved defects in iteration, etc
2. Above discussed point could be used as a starting point, however going forward it is critical to identify some of the pain points in the project and create metrics around them. Pain points can be identified by looking at what the customers/stakeholders are unhappy about most of the time.

3. It is also important to display the up to date metrics in a visible area in an Agile development environment.

4. There should be some action associated with the numbers captured as part of metrics,whether it is good or bad. If the numbers are as per the target/plan, then one should create actions to increase the bar. If the numbers are not good, then one should take actions to reach the bar.

5. Metrics can drive the behavior of the team. It is very important to choose the right metrics.
Recently I heard from some one that a management of a start up company imposed a metric to measure the productivity of individuals based on the number of times a developer checks the code into the repository. This metric obviously resulted the behavioral change in developers, as they were more worried about how frequently they check the code in to meet the target rather than any other deliverable.

Here are couple of good websites with information on Metrics in Agile environment


Anonymous said...

I don't think a behavioural change is avoidable when moving to an Agile methodology. In essence you actually are initiating an intentional behavioural change.

Managing the team members during such a migration from waterfall to Agile would is an integral part of such a change.

When you make the change to the project style, the team members suddenly have to work in a different fashion, such as iterations. This will definitely affect people meeting deliverables and in general how the proceed with their tasks.


Anonymous said...

The choice of metric should be determined by what you are trying to measure: metrics should not be collected for their own sake. The top three reasons (according to a forester report commissioned by Borland) for collecting metrics are:

- Process improvement
- Communicating with the business
- Time/scope trade-offs

In some some of the more popular Agile practices the need to collect these sorts of metrics can decrease and be replaced with people. For example instead of monitoring defects I've worked in an agile environment where the customer would sit down and write acceptance tests for the system before the features were coded. This is a system where inputs and outputs could be described in a tabular fashion using Fit or similar. Regression testing then is automatic and the introduction of defects is immediately obvious as builds (whether continuous or smoke-test) would fail.

Metrics for reasons of process improvement can mainly be concentrated on code level: code coverage, number of tests, OO type metrics, complexity metrics. These can now be built into some development environments to warn the developer when the code is not good. This instant feedback fits well with the agile culture.

Monitoring the success of the project can largely be done through burndown and as you say managing the backlog. Have you come accross moutain-goats alternative view of the burndown chart?

This rolls some of your agile metrics into a single chart.

The best way to introduce productivity is to move to a pair-programming environment. I worked in an environment where there was a pairing area where you sat together and coded all day. I know some companies that adopt this in the city that don't give the developers an email address or anything like that as they will be coding all day (in pairs).

Unknown said...

My cousin recommended this blog and she was totally right keep up the fantastic work!
Agile Software Development

Olivia Jennifer said...


Amani Phoenix said...

great article.