Time_estimates

I took the train home to Stockholm from Skövde yesterday. The train was to my very small surprise late, somehow Swedish trains have a hard time dealing with snow.

The more interesting thing was how Swedish train company SJ calculates when the late train will arrive at its destination. The train started in Gothenburg, and had continuously become more late as it approached Skövde. But according to SJ, from Skövde and on we would not only start going faster, we would actually be going faster than normal.

Thomas Looy: How Long is a Piece of String?: “- Use working software as the only measure of the progress on a project (no more 90% completed tasks);

• Measure using smaller sized tasks. Smaller tasks give you better measures than larger ones and will also give you a larger sampling of measures that can be used for meaningful statistical evaluations. Smaller tasks are also completed sooner and therefore give you measurements sooner that you can begin to use to extrapolate to a meaningful project complete date.”

(Via Planet TW.)

Joe is asking for ideas regarding time estimates.

First of all, read Planning Extreme Programming by Martin Fowler and Kent Beck. Even if you don’t want to do XP it provides excellent ideas for planning.

The book promotes “the gummi bears principle” meaning that estimates should not translate to calendar time. Instead stories should be measured relatively to each other. So if story A is a 2 and story B is slightly harder, then it is a 3. This requires an upstart period where you “calibrate” your measures. But after a while you get quite good at it.