41116Do not estimate time
- Sep 4, 2009Hi
This explains a lot. If youre using planning 1 for estimation, youre
doomed. There are several mistakes in this behaviour (my point of view)
--- In email@example.com, Andrew Wagner
> > Why are they several hours long?
> There are typically two planning meetings for each iteration (at least
> the two that we've done so far):high-level
> - In the first, we get an understanding of the story, and do a
> (planning-poker-based) story estimate. In this, we try to avoidtalking
> about implementation details completely, because it feels like thewrong
> level of abstraction.1. You're wasting time. The reason of this meeting is gettingcommitment,
not estimates. Just execute weekly estimation meetings ofone hour and
use THIS for first discussions. We had several magicmoments where big
tasks got small and small tasks grew big after we discussed the things
while estimating them. Estimating is a very hard work, most times people
are 100% wasted after 30 Minutes.
2. You are doing the wrong thing. The only sense of planning I (as
weexecute it) is to commit to some sort of result (how to reach
thesprint goal) and determine factors that define if something is done.
3. The estimation meetings are filled with a lot of discussions. How
should different persons come to an close estimate? We have
juniorprogrammers and seniors in the same meeting. Totally different
skillset, totally different point of views. But we stop estimating a
task only if we can find a estimation that is agreed on by everybody.
This means some estimation meetings only estimate one or two features
I guess your stategy of letting one person work on a task is not helping
good estimates either.
> - In the second, we break the story estimate into tasks, divvy outthe
> tasks, and whoever gets the task provides their estimate.4. Re-Estimating in Planning II, please NOT.
Focus should be on the details of implementation in terms of what kind
of steps have to be taken (right). You do not know who will work on a
task, remember, its pull, not push. Better work with 2 people, or 3 on
one task/subtask. It might seem as a waste of time. When you reach
sprint 10 you will see how the "magic" works. More people know how
things work, more piece of cake tasks arise, estimates get closer. All
> Both just tend to take several hours, I'm not sure how to answer
> that we are still (at this point) estimating in terms of hours, notpoints.
This could be a main reason of the described problems. Estimating in
hours makes people defensive because hours don't abstract from
sideeffects that arise in each sprint: people get ill, servers get
kernel panics, temperatures rise above 30 degrees celsius,
relationsships break up ... etc. life happens!
Following standard example explains a lot more what I am pointing out
Estimate travelling from Amsterdam/Holland to New York/Usa. It's easy to
estimate how far both places are away from each other: Several Thousand
Kilometers. It's harder to estimate how long you will need to reach NY,
depending on how you travel. Using a ship, Using a plane?
Senior programmer vs. Junior Programmer?
> > How do you imagine you could get good estimates withoutNever, if you estimate Time. If you estimate size, very easy because
> > understanding the design impact of the story?
design plays a lesser role.
> Agreed, and we do try to quickly get a grasp of the design when doing
> task-level estimates, but it seems like when we sit down to actuallydo the
> work, other things come up and things spin out of control. Part ofthis,
> too, is that it seems like any work that we do in estimating the workbefore
> we actually commit to doing it in an iteration is a liability, isn'tit?
We only estimate features, never the tasks at hand to finish a feature.
As long as you do not know the capacity of your team (Storypoints per
Iteration the ycan get done), commiting always is a liabillity.
But this will never fade away as long as you estimate hrs and not SP.
The SP estimates are for removing the liability.
- << Previous post in topic Next post in topic >>