19862Re: [scrumdevelopment] Best Practices + Estimation Tool
- Mar 1, 2007On 3/1/07, srinivas chillara <ceezone@...> wrote:
>Do you have any evidence that keeping track of actuals really does
> 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.
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.
> 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: firstname.lastname@example.org
> > [mailto:email@example.com] On Behalf
> > Of Jeff Heinen
> > Sent: Wednesday, February 28, 2007 11:29 AM
> > To: firstname.lastname@example.org
> > 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
- << Previous post in topic Next post in topic >>