Lately I've been discussing estimation a lot with both colleagues and friends so I guess it is time to go at it again. As I've mentioned several times before; I'm not a believer in estimates. The process of estimating is good in order to understand and break down complex problems but the estimate itself as limited (if any) value in my opinion.
For a long time I have been using three types of estimates to achieve three different goals. For long term planning (6-12 months or even longer) I typically advocate the use of man-month or even team-month estimates created by a small group of experts. This is a fast way to get good enough estimates to make really long term release or budget planning when needed. I make sure the team never sees these numbers...
For user stories I've used both story points and other things like t-shirt sizes. Most organizations I've worked in have been obsessed with velocity-based planning so even while I can often prove that planning based on just the number of user stories is just as good I can accept working with abstract units if it make people happy.
For individual tasks and bugs that the team work on I only ask the team to keep the tasks no larger than one days worth of work. But I don't care about the estimate itself. Just the number of tasks is good enough for me.
Those three different ways of estimating have been my default for probably too long. Until recently when a discussion with a friend as well as another discussion with colleagues recently unearthed and interesting stand point. If your iterations are short enough you don't need velocity to track progress. In that statement there is an assumption that each iteration delivers some value. And short enough is probably a single week.
I think it is definitely true that the shorter your iteration is the less data you need to see if you are tracking towards the goal because at some point it becomes almost a binary thing; either you did it or you did not. There are no partial results...
No comments:
Post a Comment