We use a three-week “iteration”, into which the project is time-boxed. User stories were broken down into engineering tasks. If an engineering task appears to require more than one engineering week, it must be broken down further.

Engineers estimate their own tasks, in “perfect engineering days”. That is, they estimate the time it would take to do the task if everything went perfectly, they weren’t interrupted, and so on. We assume (and it has held up well under measurement) that there are two real days per perfect day. Therefore each engineer signs up for enough tasks to fill 7 or 8 days in each iteration.

programming, doesn’t that cancel out the factor of two?

  • You might think that this would happen, but it seems not to. We track how we do against the factor, and for some iterations we used a factor of 0.3 rather than 0.5. (We were doing a lot of necessary refactoring during those periods.)
  • Update: recent events make us suspect that pairing does impact the factor of two, but does not fully cancel out. We are presently using an overall performance ratio of 1 / 2.5, or 0.4 instead of 0.5. We can't fully explain why the ratio has changed, but it clearly has. We are working on reducing interruptions, and on producing more tests at the beginning of tasks. The main thing, however, is that we know the ratio has changed and we use the new ratio in our planning. That lets us predict progress most accurately (if not always popularly).

On the contrary, the ratio of 1 to 2 accounts for engineer’s errors in estimating how effective they are. Don’t different engineers have different ratios?

  • A refinement of our technique might be to maintain a separate factor for each engineer, but this would make estimating and managing the iterations quite difficult. So far, it hasn’t been necessary.