Ideal Time
From AgileBok.org
Ideal Time
Some teams ask programmers to include each non-programmming activity in their estimates. But, this is not easy to do. For a given agile project, long before the team has an accurate measurement of time they spend doing non-programming stuff, they can know the relative work required to get different features done, and can plan accordingly. That's why it is more typical of agile teams to focus their estimating on what can be most straightforwardly estimated and measured: actual programming. They focus on how much work each feature and each technical task will take, compared to other features and technical tasks. They allow the amount of time consumed by that non-programming stuff to become clear as actual velocity emerges after a few iterations. There are two main estimating units agile teams use to concentrate the focus on programming in this way:
- Work Units
- Ideal Time
Contents |
Work Units
A Work Unit is a relative measure that we hope cannot possibly be confused with actual time. Some such units:
- Points
- Gummi Bears
- Foot-Pounds
- NUTs (Nebulous Units of Time)
These represent the relative amount of work required to implement a feature (or task), compared to other features (or tasks). Only once the team has settled into a consistent velocity, usually over a few iterations, can they begin to map these work units to units of actual time. That is exactly the point of velocity: to describe how much work the team can do per unit of actual time.
Once the team or organization has agreed on an estimating unit, they should agree to make an effort to implement it consistently and stick to its original definition. Especially in the project's early iterations, everyone should resist the urge to try to map these units to time units with any exact precision.
Ideal Time
Like Work Units, Ideal Time excludes non-programming time. When a team uses Ideal Time for estimating, they are referring explicitly to only the programmer time required to get a feature or task done, compared to other features or tasks. Again, during the first few iterations, estimate history accumulates, a real velocity emerges, and Ideal Time can be mapped to real, elapsed time.
Many teams using Ideal Time have found that their ultimate effort exceeds initial programmer estimates by 1-2x, and that this stabilizes, within an acceptable range, over a few iterations. On a task by task basis the ratio will vary, but over an entire iteration, the ratios that teams develop have proven to remain pretty consistent. For a given team, a known historical ratio of Ideal Time to real time can be especially valuable in planning releases. A team may quickly look at the required functionality and provide a high level estimate of 200 ideal days. If the team's historical ratio of ideal to real is about 2.5, the team may feel fairly confident in submitting an estimate of 500 project days. In fixed-bid scenarios, this kind of estimate can be reliable.
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 we see it, there are two options:
- make one estimated hour equal to one real hour
- "train" everyone to treat the estimated hours as something completely unrelated to real time.
Th above point number 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 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.
Why use Ideal Time
We're often asked to estimate work before we get started and we have been doing something which we were unaware of.
- Ideal Time - The time we estimate it will take to complete a story uninterrupted (consider this an estimate of size).
- Elapsed Time - The actual amount of time it will take to complete the story.
The fact is we never really have an ideal day, where we have a full 8 hours to contribute to development. Why? Well pretty much any or all of the following: meetings, emails, peer reviews, application support, phone calls, training, being pulled off to another project, task switching, extra long lunches, etc. We estimate in Ideal Time because it's easier (we can't really guess what the interruptions will be from one day to another). But realistically, this isn't correct. Given that we estimate in Ideal Time, how do you account for these typical external project demands? Do you add a percentage to your estimates? Do you adjust your estimates during the story? Or do you just try and finish as much as possible?
Most of the times, we have been adding a small percentage to our estimates and it is seen in others developer as well.
