Do Not Use Ideal Time For Tracking
In XP tracking, ideal time is used (among other units):
Position Statement for the Experience Exchange workshop at XP2001
Ideal time is time without interruption where you can concentrate
on your work and feel fully productive [PXP,
The velocity is calculated as sum of the estimations:
To measure the project velocity you simply count up how many user
stories, or how many programming tasks were finished during the iteration.
Total up the estimates that these stories or tasks received [XPDW,
seems to understand velocity as the ideal time measured in the last iteration
In tracking a small project that contained most of the XP practices, I
had a problem. In one iteration, we got more work done than in the iteration
before. I had tracked our ideal time very accurate. There was approximately
the same ideal time used for the stories than in the iteration before.
So we perceived that we were faster. Now I had two possibilities to calculate
If I use (1.) as velocity, our velocity would not change. This contradicts
the actual situation (as we were actually faster), so we used (2.) for
as sum of the measured ideal times
as sum of the estimated ideal times
But then I had no idea how we could estimate by comparison:
We could not use the measured ideal times: Our velocity already contained
our speeding up.
We could not use the estimated ideal times: This would contradict the definition
of ideal time.
The problem was related to measuring the size of stories with a time related
unit. So speeding up or slowing down leads to different values for the
same story size. My solution was simple: We have switched to using points
as proposed in [XPI]
instead of ideal days. Our velocity is now the number of points that we
have finished in the last iteration. By avoiding a time related unit we
do not have problems with comparing tasks after speeding up. So my position
You should never use ideal time for estimation and tracking, but
a unit that is not time related.
26129 Oldenburg, Germany