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

Re: Why points are lame...

Expand Messages
  • Mike Sutton
    Nicholas, I m hoping you mean consistently mis-estimated in ONE estimating session and NOT in consecutive product planning sessions. On the off chance you
    Message 1 of 185 , Oct 3, 2007
    • 0 Attachment
      Nicholas,

      I'm hoping you mean consistently mis-estimated in ONE estimating
      session and NOT in consecutive product planning sessions. On the off
      chance you didn't mean that, here is what I thought:

      I'm sure your experience is well informed, but I personally would have
      little faith in a team that consistently mis-estimated. It indicates
      to me that so many things are wrong.

      Estimates ARE supposed to get better with time, the more stuff you do,
      the more historicals you have to feed into future estimates. Now if a
      team is consistently mis-estimating, then it appears to me that
      they're not learning. If they are not learning, what else aren't they
      doing. Trust begins to get eroded somewhat when I have to doubt what
      else a team isn't doing. This is not good. Its bad.


      Part of the reason , I think, that this seems so emotive is that
      customers forget that estimates are just that, a guess. Might be
      educated, well informed, methodical and the rest, just a guess. Then
      somehow, it becomes something that vast amounts of time and money get
      spent trying to achieve. Its crazy.


      mike
      csm. certified.certifiable.

      --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
      <nickaustin74@...> wrote:
      >
      >
      > Accuracy is nice, but consistency is just as good.
      >
      > We all know it's difficult to be accurate with estimates, but what we
      > can hope for is consistent "mis-estimates." You can still plan a
      > project even if the estimates are not as accurate as you wished, so
      > long as they're consistently so.
      >
      > I don't see how accuracy enters the thread on hours vs story point
      > estimates. Both estimates can be equally accurate or not. Neither
      > method affords better accuracy by itself, imho.
      >
      > The reason I would use story points are in my earlier posts in this
      > thread, but basically: a) an easier estimate you can get everyone to
      > agree on, b) have long shelf life (don't require a lot of re-estimating)
      >
      > Nicholas
      >
      >
      >
      > On Oct 3, 2007, at 2:31 PM, Malcolm Anderson wrote:
      >
      > > Hi Mike
      > >
      > > I'm going to pick one nit in your otherwise outstanding post.
      > >
      > > You make the statement, "Remembering that accuracy is the goal." and I
      > > have to provisionally disagree with you.
      > >
      >
      > ---
      > Nicholas Cancelliere
      > Austin, TX
      >
      > Got sugu on the brain?
      >
      > P Before printing this, think about the environment.
      >
    • 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 .....
         
        Regards,
        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...

        Andreas




        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.