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

Re: [scrumdevelopment] Best Practices + Estimation Tool

Expand Messages
  • Niklas Koponen
    ... Have you read this one yet? http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf -Niklas -- Niklas Koponen | +358 40 757 1459 | Antbackantie 4
    Message 1 of 7 , Feb 28, 2007
      On Wed, Feb 28, 2007 at 03:00:04PM -0000, sasktel.trevormcgugan wrote:
      > Any best practices posted somewhere on scrum? How about any testing
      > estimation tool that you would recommend?

      Have you read this one yet?

      http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

      -Niklas
      --
      Niklas Koponen | +358 40 757 1459 | Antbackantie 4 B 11, FIN-02400 KIRKKONUMMI
    • srinivas chillara
      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
      Message 2 of 7 , Mar 1, 2007
        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.

        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
        >
        >
        >
        > ________________________________
        >
        > From: scrumdevelopment@yahoogroups.com
        > [mailto:scrumdevelopment@yahoogroups.com] On Behalf
        > Of
        > sasktel.trevormcgugan
        > Sent: Wednesday, February 28, 2007 7:00 AM
        > To: scrumdevelopment@yahoogroups.com
        > Subject: [scrumdevelopment] Best Practices +
        > Estimation Tool
        >
        >
        >
        > Any best practices posted somewhere on scrum? How
        > about any testing
        > estimation tool that you would recommend?
        >
        >
        >
        >
        >




        __________________________________________________________
        Yahoo! India Answers: Share what you know. Learn something new
        http://in.answers.yahoo.com/
      • Steven Gordon
        ... 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
        Message 3 of 7 , Mar 1, 2007
          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
        • ceezone
          Steve, Well, a record helps us remember our mistakes, so as not to repeat them, and be wildly optimistic. I don t mean that this should improve estimation
          Message 4 of 7 , Mar 2, 2007
            Steve,

            Well, a record helps us remember our mistakes, so as not to repeat
            them, and be wildly optimistic. I don't mean that this should improve
            estimation capability of the whole organisation, only for the current
            team for teh current project. In which case I've seen the benefits of
            there.
            When there are glaring differences in original_estimates.vs.actuals
            we insert a short comment (less than 6 words).


            > 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.
            >

            Afraid, I haven't read this. Thanks for the tip.

            cheenie
          Your message has been successfully submitted and would be delivered to recipients shortly.