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

19862Re: [scrumdevelopment] Best Practices + Estimation Tool

Expand Messages
  • Steven Gordon
    Mar 1, 2007
    • 0 Attachment
      On 3/1/07, srinivas chillara <ceezone@...> wrote:
      >
      > Hello All,
      > While I agree with all that has been said, maybe we
      > are missing a trick here. A tool (maybe even a simple
      > spread-sheet) can help is keeping track of these gut
      > estimates, re-estimates, and also the actual time
      > taken. Then this data can be distilled so as to have
      > historical data, based on that team's estimations and
      > actuals, which can be extremely useful going forward.
      > One of the reasons we mess up estimates is we often
      > don't keep a record.

      Do you have any evidence that keeping track of actuals really does
      increase the accuracy of estimates in the context of Scrum
      Development? I have only seen studies on this in the context of
      waterfall-style development, where the project is being driven by the
      up front plan instead of short feedback loops.

      What I have noticed in practice is that keeping track of actuals on
      the Scrum Task Board tends to bias the revised estimations of the time
      remaining to complete tasks. This bias towards revising time left to
      completion by just subtracting the actual time spent already then
      interferes with the team successfully self organizing around meeting
      their sprint commitments by putting off all the unpleasant surprises
      until the last few days of the sprint.

      BTW, Mike Cohn's latest book, Agile Estimation and Planning (
      http://www.mountaingoatsoftware.com/book/1) has much more to say on
      this topic than User Stories Applied.

      Steve
      >
      > cheers
      > Srinivas (aka cheenie)
      >
      > > What Jeff is saying is absolutely right.
      > > On a Agile Project if we are following the practice
      > > first time then the
      > > estimation for the backlog items is usually done
      > > based on
      > > Gut Feelings or Historical Data or Based on
      > > method used in Previous
      > > Projects .
      > >
      > > Once we have completed one or two sprints, then the
      > > Story Point
      > > Estimation will comes into play.
      > >
      > > Mike Cohn book as pointed out by Jeff, has few
      > > detailed few chapters on
      > > Estimation.
      > > I highly recommend reading Mike Cohn book 'User
      > > Stories Applies' for
      > > Agile Development", particularly the below mentioned
      > > chapters
      > >
      > > Estimating and Planning
      > > Planning Release
      > > Measuring and Monitoring Velocity
      > >
      > >
      > > Good Luck
      > > Basharat
      > >
      > >
      > > ________________________________
      > >
      > > From: scrumdevelopment@yahoogroups.com
      > > [mailto:scrumdevelopment@yahoogroups.com] On Behalf
      > > Of Jeff Heinen
      > > Sent: Wednesday, February 28, 2007 11:29 AM
      > > To: scrumdevelopment@yahoogroups.com
      > > Subject: RE: [scrumdevelopment] Best Practices +
      > > Estimation Tool
      > >
      > >
      > >
      > > You might want to take a look at Mike Cohn's "User
      > > Stories Applied" for
      > > a good treatment of agile estimation. In general, on
      > > an agile project
      > > you typically don't spend a lot of effort coming up
      > > with detailed
      > > estimates. Often we estimate using "story points,"
      > > which are unit-less
      > > measures of relative size. Each backlog item is
      > > compared to others and
      > > given a value based on how "big" it is in comparison
      > > to the others.
      > > These estimates encompass all the work required to
      > > deliver the item
      > > (design, development, testing, documentation, etc.).
      > > Such estimates are
      > > arrived at quickly (usually with no more than a few
      > > minutes of
      > > discussion) and the whole team participates in
      > > estimating. Story point
      > > estimates do not equate to duration, rather duration
      > > is derived from the
      > > velocity of the team (velocity = number of story
      > > points the team can
      > > complete in an iteration). So say, for example, the
      > > project has 100
      > > points worth of work, and the team's velocity is ~10
      > > points per two-week
      > > iteration. That means the duration of the project is
      > > about 10
      > > iterations, or 20 weeks.
      > >
      > > I am not aware of any tools for agile estimation,
      > > nor can I see much
      > > value in having them if such things did exist. They
      > > would only serve to
      > > complicate something that we purposely try to keep
      > > simple.
      > >
      > > Jeff Heinen
    • Show all 7 messages in this topic