23   Measure Real Progress

“Please use your time sheets to report your progress. We’ll use these for project planning. Always fill in 40 hours each week, regardless of how much you really worked.”

The passage of time (which is usually way too fast) provides great feedback: what better way to determine whether you’re on schedule than to see how long it’s actually taking you, as opposed to what you had estimated?

Ah, but you say you’re already tracking that, using time sheets. Unfortunately, in most corporations, time sheets are intended for payroll accounting and are not really meant to measure progress of work in software projects. If you worked sixty hours, for example, your boss probably asked you to fill in only forty hours in the time sheet—that’s what accounting wants to see. Time sheets rarely represent the reality of work completed and therefore aren’t useful for project planning, estimation, or measuring performance.

Even without time sheets, some developers have difficulties focusing on reality. Have you ever heard a developer report that he’s 80% on a task? Day after day and week after week, still 80% done? That’s not a useful measure at any rate; it’s like being 80% true (unless you’re a politician, true and false are boolean conditions). Instead of trying to calculate some bogus percentage of “doneness,” try to determine how much work you have left. If you initially estimated the task to be 40 hours and after 35 hours you think there’s another 30 hours of work, then that’s the important measurement (honesty is important here; there’s no sense in trying to hide the obvious).

When you do finally finish the task, keep track of how long it really took. Odds are, it probably took longer than you originally estimated. That’s OK; just make a note of it for next time. For the next task you have to estimate, adjust your estimate based on this experience. If you underestimated a two-day task, and it took six, you were short by a factor of three. Unless there were unusual circumstances, maybe you should multiply your next estimate by three. You’ll zig-zag around for awhile, under- and overestimating your effort, but over time, your estimates will converge, and you’ll get a better sense of how long a given task will take.

It’s also helpful to measure progress by keeping the road ahead very visible. The best way to do that is by using a backlog.

Andy says:

Accounting for Time

My sister-in-law once worked for a large, international consultancy. They had to account for their time in six-minute increments throughout the day, every day.

They even had a code to track the time spent filling in the form to track your time. But instead of being 0, 9999, or some easy-to-remember code, it was the very convenient 948247401299-44b.

This is why you don’t want the accounting department’s rules and constraints to leak out and spill over into the project.

A backlog is just a list of tasks that still need to be completed. When a task is completed, it’s removed from the backlog (logically; physically you might just cross it off or mark it as done to leave a list of accomplishments). As new tasks are introduced, they are prioritized and added to the backlog. You can have a personal backlog, a backlog for the current iteration, and a backlog for the project as a whole.^[24]

With the backlog, you always know the next most important thing on which to work. As your estimation skill improves over time, you’ll get a better and better idea of how long it might take as well.

It’s a powerful technique to keep track of your real progress.

Measure how much work is left. Don’t kid yourself—or your team—with irrelevant metrics. Measure the backlog of work to do.

What It Feels Like

You feel comfortable that you know what has been done, what’s left, and what your priorities are.

Keeping Your Balance

• Six-minute units are too fine-grained and aren’t agile.

• Week-long or month-long units are too coarse-grained and aren’t agile either.

• Focus on functionality, not the calendar.

• If you’re spending so much time keeping track of how much time you’re spending that you aren’t spending enough time working on the project, then you’re spending too much time keeping track of how much time you’re spending. Get it?

• In a forty-hour work week, not all forty hours are available for you to write code for the project. Meetings, phone calls, email, and other related activities can take a substantial amount of time.