Comments on: Re-estimating cards after they are played seems wrong http://www.fuzzylizard.com/archives/2009/02/08/1008/ Web development and design with a little VFX thrown in for fun Fri, 14 Jan 2011 22:45:58 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Darren Hobbs http://www.fuzzylizard.com/archives/2009/02/08/1008/comment-page-1/#comment-32936 Darren Hobbs Mon, 09 Feb 2009 13:21:01 +0000 http://www.fuzzylizard.com/?p=1008#comment-32936 A card's estimate cannot be updated after you've completed it. That's not an estimate, it's an 'actual'. The implication being that you probably misunderestimated it originally :) I've seen this happen as an attempt to get 'better' at estimating. The idea is that if you estimate 'build a foobar' as 2 but it was actually more like a 4, then you want to ensure that all similar tasks (build a barfoo) don't suffer the same misunderestimation. Estimates are for planning. What's the benefit of re-estimating finished work? You're not getting that time back. In order to plan effectively, a 2 should take half as long as a 4 and twice as long as a 1. As long as your units are internally consistent it matters not one whit if a 2 takes 5 days or 1 day. The velocity score will let you predict your progress. What is useful is to periodically reflect on past estimates and look for patterns. So if you find that the team is consistently over or under on certain types of task, you can use that feedback in your planning. Eg. I've seen projects where GUI related work was consistently underestimated so any iterations with lots of GUI tasks would reliably fall short of the predicted velocity. Once we realised that GUI work tended to soak up a lot of time we took account so that a 2 point GUI task really did take half as long as a 4 point domain-logic task. Recording actuals and adjusting story-by-story wrecks velocity as a mechanism for predicting progress because the units of measure are no longer internally consistent. A card’s estimate cannot be updated after you’ve completed it. That’s not an estimate, it’s an ‘actual’. The implication being that you probably misunderestimated it originally :)

I’ve seen this happen as an attempt to get ‘better’ at estimating. The idea is that if you estimate ‘build a foobar’ as 2 but it was actually more like a 4, then you want to ensure that all similar tasks (build a barfoo) don’t suffer the same misunderestimation.

Estimates are for planning. What’s the benefit of re-estimating finished work? You’re not getting that time back.

In order to plan effectively, a 2 should take half as long as a 4 and twice as long as a 1. As long as your units are internally consistent it matters not one whit if a 2 takes 5 days or 1 day. The velocity score will let you predict your progress.

What is useful is to periodically reflect on past estimates and look for patterns. So if you find that the team is consistently over or under on certain types of task, you can use that feedback in your planning. Eg. I’ve seen projects where GUI related work was consistently underestimated so any iterations with lots of GUI tasks would reliably fall short of the predicted velocity. Once we realised that GUI work tended to soak up a lot of time we took account so that a 2 point GUI task really did take half as long as a 4 point domain-logic task.

Recording actuals and adjusting story-by-story wrecks velocity as a mechanism for predicting progress because the units of measure are no longer internally consistent.

]]>