Software development is measured for many reasons:

• To assess productivity
• To enable the tracking of progress to determine when the project is ahead, behind or on schedule
• To establish a baseline for estimation and to encourage team members to improve their ability to estimate based on historic metrics
• To provide some indication of software quality
• To identify problem areas

What to track?

The data to track obviously varies widely from project to project, however, the minimum criteria to track are:

1. Estimates and actual time used
2. Acceptance tests created and passed (as defined and witnessed by the customer or business representative)

Only track measurements that are genuinely useful to the project. Other common metrics to consider are grouped as follows:

1. Resources: Planned versus actual, Number of developers, Number of testers
2. Scope: Number of requirements over time, Number of completed requirements over time, Requirements progress, Total estimation time versus scope consumption
3. Quality: Number of unit tests failing per run, Number of acceptance tests defined over time, Number of acceptance tests succeeding over time, Bug density, Functional code bulk measured against test code bulk, Number of integrations performed over time, System performance
4. Time: Estimates and actual time used

When to track?

Tracking should be a passive activity and should not be invasive. Every team member should record the designated software metrics for their tasks on a daily basis, thus ensuring that the metrics accurately reflect the time used and the results produced for each day.

How to track?

Software metrics can be recorded using a form on an intranet, for example. This does not disturb an individual's concentration. The collection of the metrics, and the subsequent analysis and generation of graphs should be automated to prevent the introduction of additional process overhead.

Visible graphs

Any team member should be able to sense the status of the project by examining the graphs. The graphs should be published daily and be publicly accessible - this ensures everyone is on the same page. They can be available for viewing on the intranet but they should also be posted on the walls, at suitable locations throughout the work area.

Interpreting the graphs and assessing progress

The graphs provide feedback to the team on progress and the estimates on which the iteration is based. Marking tasks and requirements as complete indicates progress.

A requirement can be marked complete when the customer and/or business representative decides, based on a demonstration and the execution of the acceptance tests, that the implementation satisfies what is expected. Only the customer or business representative is qualified to decide whether any failures that occurred are acceptable as concessions.

An iteration is completed on the day that was set during the iteration-planning phase. The scope of the iteration should be managed by the customer or business representative to satisfy the completion date. Requirements that were de-scoped by the customer or business representative due to reprioritization or requirements that were not completed are deferred for consideration for implementation in the next iteration-planning phase.