Loading ...
Sorry, an error occurred while loading the content.

41116Do not estimate time

Expand Messages
  • sschuermann303
    Sep 4, 2009

      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 scrumdevelopment@yahoogroups.com, Andrew Wagner
      <wagner.andrew@...> wrote:
      > >
      > > 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):
      > - In the first, we get an understanding of the story, and do a
      > (planning-poker-based) story estimate. In this, we try to avoid
      > about implementation details completely, because it feels like the
      > 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 out
      > 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
      gets easier.

      > Both just tend to take several hours, I'm not sure how to answer
      "why". Note
      > that we are still (at this point) estimating in terms of hours, not

      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 without
      > > understanding the design impact of the story?
      > >
      Never, if you estimate Time. If you estimate size, very easy because
      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 actually
      do the
      > work, other things come up and things spin out of control. Part of
      > too, is that it seems like any work that we do in estimating the work
      > we actually commit to doing it in an iteration is a liability, isn't

      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.

    • Show all 17 messages in this topic