Measuring Quality of Work

In addition to quantity of work, quality of work can be measured—and should be measured—so that the team doesn’t focus solely on quantity and neglect quality.

Rework percentage (R%) is the percentage of effort focused on rework vs. new development. As I mentioned in the “More Effective Agile Quality” chapter, rework is a useful proxy for inefficiency or waste on software projects. A high R% can indicate that the team is not spending enough time refining stories before implementing them, does not have a strict enough Definition of Done, is not adhering to its Definition of Done, is not testing adequately, is allowing technical debt to accumulate, or other problems.

On Sequential projects, rework tends to accumulate at the end of the project—unplanned—and is therefore quite visible. On Agile teams, rework tends to be worked off more incrementally, and it is therefore less noticeable. But it’s still there, and it’s useful to monitor R% on Agile teams.

The use of story points provides a foundation for measuring rework. Stories can be classified as new work or rework. R% is calculated as the amount of rework in story points divided by total work in story points. The team can then monitor whether its R% increases or decreases over time.

Teams often need to align on what counts as rework. For teams working on legacy systems, reworking issues created by earlier teams should count as new work. For a team that is fixing issues that it created earlier itself, that work should count as rework.

An alternative to measuring R% is to set a policy that rework is simply not assigned story points. You won’t be able to calculate a rework ratio, but if the team spends much time on rework, you’ll see its velocity decrease because the time spent on rework does not add to the team’s story point count.

In either approach, the purpose is to balance the quantity-oriented measure of velocity with a quality-oriented measure.