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

Re: [XP] Do You Estimate Tasks?

Expand Messages
  • John Goodsen
    On Dec 21, 2004, at 3:09 PM, wrote: [snip...] ... Hi Jim, We have settled on the following approach of estimating at both a Story level
    Message 1 of 5 , Jan 11, 2005
    • 0 Attachment
      On Dec 21, 2004, at 3:09 PM, <jim_long@...> wrote:

      [snip...]

      > My question: Who out there is stll breaking User Stories
      > into Tasks? Do you estimate Tasks independently of the
      > Stories? Do you simply ignore differences, or do you try
      > to reconcile them? And, how do you deal with a Customer
      > who wants to reduce Story estimates after Iteration Planning
      > if the sum of the Task estimates are lower? Do you just
      > hide the Task estimates?

      Hi Jim,

      We have settled on the following approach of estimating at both
      a Story level *and* at a Task level. I'll describe:

      Stories are estimated in points. A point reflects a relative amount
      of effort. A 2 point story has roughly twice the effort to implement as
      a 1-point story. All a project manager should ever need to see is
      story based estimates. All release planning is performed with story
      estimates and a notion of team velocity.

      Tasks are estimated in ideal time. The estimate is produced when a
      programmer
      signs up for the task. The reason for task estimates are
      *NOT* to reconcile with story units (using different units for stories
      helps this).
      The reason task estimates are in ideal time is so developers sign up
      for the right
      amount of work based upon yesterday's weather. If a developer was
      able to put in 35 ideal hours last iteration, they may come into the
      current
      iteration planning with a notion that they will sign up for another 35
      hours worth
      of tasks.

      Estimating tasks in ideal time units also helps drives better
      utilization of the business dollar.
      If one programmer signs up for a task and puts, say 10 hours on the
      estimate and another
      programmer says he can do it in less time, say 6 hours, that programmer
      gets the task and
      we ask the first programmer to pair up (and hopefully he will be able
      to do the work in 6 hours
      next time it shows up - sharing the knowledge).


      > And, how do you deal with a Customer
      > who wants to reduce Story estimates after Iteration Planning
      > if the sum of the Task estimates are lower? Do you just
      > hide the Task estimates?

      Estimate stories in points really helps alleviate this problem. Your
      team
      velocity (how many points can we implement in an iteration) is all you
      need
      to select the right amount of (stories) work in an iteration. The
      notion of velocity
      allows you to not change your (point-based) estimates every time you
      see yourself going
      faster - you just choose more points worth of stories the next
      iteration but leave
      the story estimates the same. As long as the "relative error" across
      story estimates is
      uniform, your point-based velocity will take into account the
      estimation inaccuracy.

      Have a conversation on what the word "estimate" means with your
      customer. Describe how you do not need to resolve task estimates
      to story estimates (estimate stories and tasks in different units as I
      described above really help them accept this). If they still don't get
      it,
      maybe it's time to fire your customer. :-)

      ----
      John Goodsen RADSoft / Better Software Faster
      jgoodsen@... Extreme Programmer and Coach
      http://www.radsoft.com Enterprise Java and .NET Solutions
    Your message has been successfully submitted and would be delivered to recipients shortly.