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.

Agile adventures – How fast am I going?

XP uses a nice technique, called “yesterday’s weather”, for the amount of work that each programmer can sign up for in an iteration. The name for this comes from an experiment some weather guys did somewhere that consisted in predicting that today’s weather will be the same as yesterday’s. If I recall correctly they got an accuracy rate grater than the one they had using the traditional weather forecasting methods they were using.

How does this work in XP? You allow a programmer to sign up for the same amount of estimated work that he successfully completed on the previous iteration. Sounds simple, but you have to deal with two facts that are not entirely under your control:

• the programmer has to be consistent in his/hers estimations
• the programmers have tasks that are not finished (the acceptance tests do not pass yet)