I’ve been thinking recently about the different approaches to measuring in development projects, and in particular whether to measure effort or duration.

The usual approach is to track time spent on tasks or on a project. This is equivalent to filling in a timesheet. Let’s say that on Monday, Tuesday and Wednesday we work on Task A for 2 hours and Task B for 3 hours. That completes Task A, and a 3 more hours on Task B on Thursday finishes that. We record

Task A: 6 hours

Task B: 12 hours

Or we might be recording effort at the project level (Project X: 6+12 = 18 hours’ effort).

An increasingly common alternative is to measure duration, also known as cycle time. In the example above, and assuming we are only working at the granularity of days, we would record

Task A: 3 days

Task B: 4 days

Cycle time generally isn’t captured at the project level, but at the task or feature level.

If you come from the effort-measuring school then measuring duration looks peculiar. By contrast, if you’re measuring duration because you’re using lean processes then the effort-measuring school looks positively archaic. Either way, the difference between the two records above is striking.

In the end, neither one is right or wrong per se. What’s important is: What do we want to achieve?

Capturing measures or metrics is often for a number of purposes: financial matters, tracking progress, and improving efficiency. Let’s look at each one in turn…

Financial

There are a couple things here: capitalisation and billing.

Capitalisation is the process of representing newly-written software as increasing the assets (capital value) of our company: by having this software we are now worth more. The accepted method is to take the asset value to be the people-cost of building the software, i.e. the salaries or fees of those involved divided across the various projects. There are clearly shortcomings with this approach, but that’s a discussion for another day.

By measuring effort we discover how we divide our time across our various projects and therefore how to split our people-costs proportionally, which becomes our capital value.

Measuring duration is not so obviously appropriate, but it can work. To see it working, it helps first to see where it doesn’t work in a deliberately unrealistic example. Suppose over the course of a year we run 250 tasks of duration five days each, plus one task which we spend a bit of time on on the first day of the year, but which then gets kicked into the long grass until the last day of the year when it’s finished off. If we capitalise by duration that single long-running task would bias the capital costs inappropriately for whichever project it was part of.

So that looks unhelpful. However it doesn’t have to work like that. In particular if we forcibly limit the number of tasks in play (aka work in progress, aka WIP) at any time then long-running tasks will be exposed and people’s natural desire to get things done should ensure they are dealt with and not forgotten. Also, a long-running task can be just taken out of the system, regarded as waste, and started afresh at another time if necessary. More generally, tasks won’t drag on as long as they might otherwise and over the course of several weeks the measurement of duration will be as just as good (and just as as imperfect) as measurement of effort.

So for capitalisation both effort and duration are plausible measures.

For the purposes of billing clients measurement of effort is ideal when charging time and materials. Lawyers, consultants and contractors all do this. Charging clients by task duration isn’t likely to go down well, and I can’t imagine how to make a itemised breakdown look palatable on the invoice.

If, however, we’re the ones being billed then we need to track effort (=spend) and match that against progress.

Tracking progress

Tracking progress (and therefore assessing completion date) is not about tracking effort, it’s about tracking when features are completed. If we’re 25% of the way through the project we want to know that we’ve completed 25% of the features; how much effort we’ve expended doesn’t tell us that. Tracking duration also doesn’t help us, but it is usually a by-product of tracking start date and end date of each feature, and it’s the end date we’re interested in here. If we’re tracking effort then the end date just one more data point we need to collect for each item in play.

Efficiency

If we want to improve efficiency then we have to track metrics (so that we can tell when efficiency has improved). But again, what we want to make efficient will determine whether we track effort or duration.

If we want to improve the single activity of writing software then tracking effort is the thing to do. However, that’s not usually that useful: single activities can almost always be made more efficient, but the most significant gains tend to be found elsewhere. Improvements in writing software will produce very small gains compared to everything else that makes up the process of delivering software: analysis, design, development, third party integration, functional testing, user testing, deployment.

If we want to improve software delivery then tracking duration is what we want. Duration of that sequence includes, and therefore exposes, all the delays. If we aim to improve our tracked metric then one major gain is to eliminate those delays; eliminating the delays then exposes the inefficiencies in hand-offs between teams, which we can then work on. At the end we have improved our overall process, not just a single activity.

There are more…

There will be more reasons to track data, but I hope it’s clear that what we should track depends on what we want to achieve. Tracking cycle time is increasingly sexy (it’s lean, it’s kanban, it’s systems thinking… we’ll forget that it’s Six Sigma, too), and there are real advantages there, particularly when it comes to improving efficiency. But plain old tracking of effort isn’t entirely redundant yet.