Agile adventures – Ideal time vs. Real time

When programmers estimate their tasks, they normally use “ideal time” – time spent exclusively on the task, with no interruptions and in a good work disposition. When you bill the client, you have to take into account the real time the programmers use to get the job done – we billed by the hour so we also delivered a detailed log on how each hour was used.

One of the confusing aspects of XP is that you have the programmers estimating their tasks with the client present. So if the client pays for 40 hours / week of programmer work, he’ll have a tough time understanding why the programmer only signs up for 15 or (if you bill by the hour) why he is billed 6 hours for something that was estimated as 2 hours.

As I see it, there are two options:

1. make one estimated hour equal to one real hour
2. “train” everyone to treat the estimated hours as something completely unrelated to real time.

(1) has the advantage that the communication with the client is clearer. Also, the programmers can use the real time they needed to complete a similar task for their estimation. The down side is that if they work on several tasks in the same time segment they’ll have troubles keeping count on how much time they needed for each one. And there will still be inconsistencies between the estimated times and the real ones.

But I think the biggest disadvantage is the fact that the “ideal hours” you use in your head for estimating have different “weights” from one iteration to the next, in order to keep up with the real time.

Although it seems more complicated, because it involves “training” the programmers and the client, option (2) yielded better results for us. The trick was to use something totally unrelated to time as a measure for the “ideal hours”. We called them “bolitas”. After a few iterations we were so used to dealing with “bolitas” that we didn’t need the estimated / real ratio anymore. We weighed individual tasks according to experience in “bolitas” and used the number of finished “bolitas” from the last iteration as the upper limit for signing up. It is easier, because they are more or less of the same value from one iteration to the next.

Because the client participated in the iteration meetings, he became accustomed to this and saw it more as a way to keep track of our velocities than as a way to establish (binding) deadlines.