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

Re: Why points are lame...

Expand Messages
  • Andreas Axelsson
    ... Points are intended to give a relative measure of size for stories, not a valid estimate of duration. Mike Cohn (author of Agile Estimating and Planning)
    Message 1 of 185 , Sep 23, 2007
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "macdonald1976"
      <macdonald1976@...> wrote:
      > First of all, anything you can make up your own definition for is lame
      > and suspect to say the least. My CTO doesn't care to hear that my dev
      > team has 150 story points left. He wants to know how many hours they
      > have left. Hours are not subject to opinion. There are 60 minutes in
      > a hour and 24 hours in a day. My CTO can relate to this. My CTO
      > cannot relate to some story point with weights assigned arbitrarily
      > assigned. Sure, some of you will argue that it is not arbitrary and
      > you are entitled to your opinion just like you are entitled to your
      > opinion as to what constitutes a point. This opinion on a unit of
      > measure and the unscientific approach to defining it, no matter how
      > scientific you contend it is, is the reason it has no value in
      > defining remaining effort. Points = opinion and like the old saying
      > goes, 'opinions are like butt holes, everyone has one'.
      Points are intended to give a relative measure of size for stories,
      not a valid estimate of duration. Mike Cohn (author of Agile
      Estimating and Planning) says: "Estimate Size; Derive Duration". The
      rationale is that it's much more likely that a team can agree on the
      relative amount of work for a story compare to another, than on how
      many hours it'll take to implement it.

      Compare with two people running a track; The first person will insist
      it's a ten minute track, the other a five minute one. Who's right?
      They are much more likely to agree that it's a one mile track (or
      whatever one can run in five minutes, I honestly have no clue), and
      that a two mile track is twice as long. Any two people running the
      track are likely to get a different time, but it's still the same size.

      So, estimate in points, validate how many points you can complete in
      an iteration, using an average over a number of iterations, or
      historical numbers if you've got them, and use that to derive the
      total project duration. I.e. our velocity of the last three iterations
      was 27, then the remaining 189 points could be finished in 7
      iterations. You do need to add a range though. Or to quote "It's
      better to be roughly right, than precisely wrong". If you've got an
      experienced team on a known domain, you may want to adjust the
      estimate -10/+5%, if it's a fresh team learning a new domain the
      figure might be -50/+25%. (Values from Mike's book) Using the first
      figure that gives us a velocity of between 24-28 meaning our 189
      points could be done in between 7 and 8 iterations. The inexperienced
      newbie team would get an initial estimate of between 6 and 14
      iterations. (It's probably not likely that an inexperienced team would
      average the same initial velocity as the experienced team, but let's
      ignore that for this exercise, the issue here is the range) There's
      really no way to know very early in a project. Experience will tighten
      the range as the project moves along. So your estimate may narrow from
      "1st quarter" to "February" to "Last week of February", all the time
      giving the Product Owner an accurate estimate, just not a precise one.

      Something you shouldn't do, however, is to try to transform the hours
      of your completed iterations back onto the remaining stories.
      Estimates are pretty much bound to follow the normal distribution and
      thus you'll end up with "easy" fives and "hard" fives. Imagine the
      disappointment if you end up spending 76 hours on an "easy" five from
      your first iteration and then apply it to every five point story in
      the backlog. It just won't work and you're back at trying to estimate
      duration directly.

      Also, there's no promise that ten points for one team can be related
      to ten points for another. It's just a number, that makes sense to
      that particular team, and the CEO should not care about its meaning in
      relation to duration or any other unit. It's a unit-less relative
      measure of size for a given team. Period.

      So, you give your boss the date range, derived above, not the points
      themselves. The points are to be used by the PO to prioritize stories
      along with estimated ROI and any other factors that may contribute.

      I absolutely recommend Mike's book if you're interested in a more
      in-depth explanation of the above thoughts.

      Andreas Axelsson
    • Roy Morien
      I think getting into a controversy on whether or not we should have Sprint 0 or -1 or whatever (leading to discussion on Sprint -5 :)) is a bit sophistic.
      Message 185 of 185 , Nov 24, 2008
      • 0 Attachment
        I think getting into a controversy on whether or not we should have Sprint 0 or -1 or whatever (leading to discussion on Sprint -5 :)) is a bit sophistic.
        Whatever you care to call it, I think it is essential to have it, to ensure that the development team is ready, willing and able to go. To a great extent it is the Envision phase, I think, which includes ensuring that the development team is approproiate to the task, that the whole general picture is understood, that everyone is singing from the same hymn book, getting all the ducks in a row and so on. There has been some discussion in this group previously about whether or not this pre-project phase (that is, pre iteration phase) should include decisions about and the adoption of development tools and standards. Some say this should emerge during later iterations, but I disagree. 
        Having undertaken this phase, the project team is then able to competently and enthusiastically (one hopes) into the iteration cycle of the project proper.

        What Scott Ambler was talking about seems to me to be just this situation.

        Sprint 0, Sprint -1, Pre-Project Phase, Envision Phase ... what's in a name, a rose etc .....
        Roy Morien

        To: scrumdevelopment@yahoogroups.com
        From: andreas.schliep@...
        Date: Mon, 24 Nov 2008 11:42:54 +0000
        Subject: [scrumdevelopment] Re: Sprint Zero

        > > what he defines as "iteration -1" and "iteration 0"
        > I do hear this kind of thing a lot, but it smells like procrastination
        > to me.
        > What innovation is next, the 31 day Sprint?

        I have discussed the 'Sprint zero' matter a couple of times. The
        drawbacks seemed higher than the benefits:

        - Sprint zero does not produce working code
        - Sprint zero takes away the sense of urgency
        - Sprint zero leads to a misunderstanding of Scrum
        - Sprint zero disappoints stakeholders

        Whenever you need to set the stage before you can actually do Scrum,
        don't call it a Sprint or iteration. Once you are in a Sprint, you are
        doing Scrum - so the first Sprint is supposed to be Sprint One

        - deliver working code
        - refine backlog items / user stories
        - figure out the architecture outline
        - make stakeholders happy

        My regards to all the poor teams out there who are still in Sprint
        minus 5...


        Sign up for the Hotmail Road Trip today. Your dream beach house escape for summer!
      Your message has been successfully submitted and would be delivered to recipients shortly.