Tracking work in Agile development

Reading time

3 min

One of the Agile principles is that we should measure progress based on the completion of working software. We should build this into the way that we track work. Work is done or it is not done. Partial completion of a work item does not earn partial credit in our tracking. Backlog items that are still being worked on gain us no credit. If they are not complete, we cannot be sure if they will hold surprises later.

Agile is intended for high uncertainty environments. It is very hard to estimate that you are “halfway through a piece of work”. We have all heard the anecdote that the last ten percent of the work takes ninety percent of the time. It is amusing because we intuitively realise that “the last ten percent of the work” has no inherent meaning. Instead we need to focus on work being “done” or “not done”.

Tracking is based only on completed work

Sizing work items

To measure progress based on work done, we need to score work items. If we make progress by completing backlog items, we need to agree how much progress. We therefore need to know how big each item is relative to the others. Then we can earn more for completing a big item than a small one. This idea of “earning value” for progress is a well established approach in project management.

It is exactly the same problem as we have with estimation. Understanding how big each item is relative to the others. Which means that we can tie the two problems together. The estimate we assign to a backlog item can also be the value that we “earn” for completing that item.

Imagine we need to complete ten items. Their estimates add up to size 100 (let us consider what the units are at a later point). The first item is estimated as size 10 in the same units. When we complete that item, we are completing what we have estimated as 10% of the work.

Partially completed items

People frequently react with concerns over not measuring partially completed items. Surely we are further ahead after five and a half items than we were after five items? Yes, of course we are. But we cannot say how much further. That “half” isn’t reliable. “Working software” is our best measure.

What if we are halfway through ten items? It is true that this will make us appear further behind than we truly are. We have made some progress (but we are unclear how much). Our tracking suggests we have made none.

Good Practices

To make this approach effective, we need to follow two key good practices. These are vital in ensuring effective tracking.

Firstly we should focus on breaking down work items through Backlog Refinement. We need to ensure that work items are small at the point they are executed (Rightsizing). If the work items are small, then partially completed items will not represent much work. So a single half completed item causes a small error in our tracking.

Secondly we must minimise Work in Progress. Work in Progress is the amount of incomplete items which the team are working on. Parallelism is inefficient. It also leads to a large number of partly completed items. As we have seen, this builds uncertainty and lag into our tracking. We should ensure we have few items in progress at any time.