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

Re: [scrumdevelopment] Why points are lame...

Expand Messages
  • Nicholas Cancelliere
    I do not disagree with you. This thread originally started out with the idea that story points are lame, which I disagreed with. Next some compared points
    Message 1 of 185 , Oct 1, 2007
    • 0 Attachment
      I do not disagree with you.  This thread 
      originally started out with the idea that
      "story points are lame," which I disagreed
      with.  

      Next some compared points to hour est
      just not callin them that.

      Then even further people were saying you
      could have, in the same sprint, two
      stories of the same size in story points
      be estimated days apart.

      Then one wonders how the CTO is
      frustrated and confused.

      See my earlier posts for my thoughts
      on the thread.

      Nicholas

      --
      Nicholas Cancelliere
      Austin, TX

      Sent from my Apple iPhone



      On Oct 1, 2007, at 2:24 AM, Roy Morien <roymorien@...> wrote:

      I am troubled by this discussion. Personally, I am just as cynical about estimating accuracy as anybody, and indeed there is always a learning experience to be had whenever we do anything. But I am uncomfortable with the notion that "it's just that the guesses proved to be wrong in hindsight. To say they were mis-estimated gives the impression that we want them to be more accurate" ... well, YES, I would like to think that our estimates can be somewhat more accurate, without, of course, always being seen as concrete quotes. Yes, our 'guesses', more usually termed estimates, maybe be proved wrong in hindsight, but that happens all the time .. hindsight being the time when we can have reasonable certainty, especially about the past.

      I do agree that often a lot of detailed analysis can be put into estimating, and in the big picture that time and effort is wasted, or provides little real value.

      But we cannot escape the reality that at an early stage of the system development project, clients WILL WANT a reasonably accurate estimate of Time and Cost for the project. This is a major input into the decision making process on a GO-NO GO decision for the project, and calculations on ROI and business value of the project.
       
      The fact is that while we continue to try to box organisational system development into neat parcels called projects, we will have this requirement.
       
      As a one-time practicing accountant, I have always wondered why this project emphasis even came into place in the first place. I wonder how the Financial Accountant could function if his work was always packaged into 'projects'. Maybe things like 'payment of at least 20 invoices plus banking of at least 25 cheques' ... something like that. This is of course an absurdity, and the organisations accounting function is seen as an ongoing activity, with, of course, certain necessary deadlines. These deadlines are known, and readily achieved, partly because of the experience of the accounting functionaries on many previous occasions. But even then, the financial accountant has the luxury of 'closing off' and then a period of time after that to get everything of relevance before the 'closing off' time up to date and processed.
       
      So why can't the system development activity be seen as a continuing activity? Every 2 weeks some additional functionality is delivered, either as new features, or updated and enhanced features, with significant deadlines stated, which we might call, hmmm, Releases.
       
      This might acknowledge the software development process as being quite unstructured and prone to being uncertain. This uncertainty may be caused by incompetent, lazy and irresponsible development personnel, but usually is not. It is usually caused by all sorts of other development and technical matters.
       
      It's actually a bit like a lawyer preparing a case. It is not expected that the lawyer have the entire coda of Law fully understood and known. Time is usually taken to research the Law to see what is appropriate to the specific case ... and the Client is charged for that legal 'ignorance'. Apparently system developers are not allowed to have any technical or developmental 'ignorance' that might disrupt the continuous 'production line' nature of software development.
       
      hmmm .. sorry ... just ranting a bit here.
       
      Regards,
      Roy Morien


      To: scrumdevelopment@yahoogroups.com
      From: dan.rawsthorne@...
      Date: Sun, 30 Sep 2007 18:55:07 -0700
      Subject: Re: [scrumdevelopment] Why points are lame...

      Exactly, and I'm agreeing with you. For planning they were both 5 point stories. They were not necessarily mis-estimated, it's just that the guesses proved to be wrong in hindsight. To say they were mis-estimated gives the impression that we want them to be more accurate, right?

      I don't like to make this value judgement because putting it usually provides a force for evil; namely, the team will want to do enough work on stories to get the estimated correct *before* we decide their priority. Yes, after we choose them for the Sprint Backlog we would expect their *task* estimates to be a little closer, but not before -- this leads to premature analysis and design, IMHO.

      Now, if  you want to do this premature analysis and design, write a (spike) story for it -- just make sure it's accounted for in some Sprint Backlog so that the team gets credit for it.
      Dan Rawsthorne, PhD, CST
      Senior Coach, Danube Technologies
      dan@..., 425-269-8628


      Nicholas Cancelliere wrote:



      You're talking about the duration they took after the fact.  I would just say in your case you grossly misestimated, and chalk it up as a learning experience.

      What I am talking about is in planning.

      Nicholas


      On Sep 28, 2007, at 7:57 PM, Dan Rawsthorne wrote:

      I don't think you could say that. However, you could easily say that one 
      5-point story took 1 day and another 5-point story took 10 days - it's 
      all about what you find when you get there.

      Dan Rawsthorne, PhD, CST
      Senior Coach, Danube Technologies
      dan@..., 425-269-8628



      Nicholas Cancelliere wrote:


      I don't think you can -- not in the same iteration.  That wouldn't 
      make sense to me either and I would rightfully question that.  Can you 
      explain to me how you have 2 different 5 point stories?

      Nicholas




      On Sep 27, 2007, at 8:20 PM, Roy Morien wrote:

      A situation that becomes very hard for the uninitiated to swallow ... 
      how can you say that one feature is measured at 5 story points and 
      can be completed in a day, but another '5 pointer' will take 4 days?



          ------------ --------- --------- --------- --------- --------- --------- ------
          Date: Thu, 27 Sep 2007 14:40:39 -0500
          Subject: RE: [scrumdevelopment] Why points are lame...

          I have educated him and he understands the concept.  He just
          tries to break it down too far.  He assumes if we average 35
          points per 2 week iteration, that means we can do 3.5 points per
          day.  In reality, we may have 2 different 5 point stories and one
          of them takes 1 day and the other takes 4 days.



          [mailto:scrumdevelop ment@yahoogroups .com ] *On Behalf Of *Nicholas
          Cancelliere
          *Sent:* Wednesday, September 26, 2007 9:27 PM
          *Subject:* Re: [scrumdevelopment] Why points are lame...





          He can assume that if all things were the same, but rarely are they.



          The point is that as time goes on people are more experienced,
          the system changes (sometimes making things easier, sometimes
          harder), etc.  You might try to educate him on what team velocity
          is and how he can use that to gauge how much work can be done.



          Nicholas





          On Sep 25, 2007, at 8:46 AM, Jeff Martin wrote:


          This is the issue I’m having the most trouble communicating to my
          CFO.  He thinks that if Story A was 5 points and took 20 hours
          then if Story B is also 5 points, it will take 20 hours.  I’ve
          tried to explain that, over time, it may equal out that way, but
          you can depend on it being a direct correlation.   I’m
          considering just switching to “perfect man (or team) days”
          because we end up just going back and forth on what a point “is”
          and not moving forward on the project.



          Of *Nicholas Cancelliere
          *Sent:* Monday, September 24, 2007 8:11 AM
          *To:* scrumdevelopment@
          *Subject:* Re: [scrumdevelopment] Why points are lame...





          I don't agree with the statement about "if you're using hours
          then you're already using story points."  This confusion between
          story points = duration is how this thread was even started.  You
          cannot equate Story Points to a duration, if you are then you're
          really just calling an "hour" by some other name, which misses
          the concept completely.



          Story Points are an estimate of size and complexity -- they don't
          communicate duration.  



          When you use hours for estimating you're estimating the duration,
          how long it'll take to get done.  That could change based on
          the experience of the team.



          Nicholas







          On Sep 24, 2007, at 6:45 AM, mpkirby wrote:



          But if your estimation accuracy is variable (like it is for most
          of us), 
          then you are already using story points.  You just call them hours. 



          And I think that's the point.  When you tell your CTO that you
          have a 
          story that takes 60 hours, and that there are only 40 hours left
          in your 
          iteration (from a planning point), and he goes around the room
          adding up 
          people/weeks, and says.  Oh no.  I see at least 100 hours left.







          --
          Nicholas Cancelliere, CSM/CSP
          Business Analyst, InCircuit Development
          512-347-7400 x123 -- http://www.incircui t.com



          For support on InCircuit products contact support@incircuit. com
          <mailto:support@ incircuit. com > or call 800-963-1950 ext 2.



          P     Before printing this, think about the environment.





          ---
          Nicholas Cancelliere
          Austin, TX



          P     Before printing this, think about the environment.





          --
          Nicholas Cancelliere, CSM/CSP
          Business Analyst, InCircuit Development
          512-347-7400 x123 -- http://www.incircui t.com



          For support on InCircuit products contact support@incircuit. com
          <mailto:support@ incircuit. com > or call 800-963-1950 ext 2.



          P     Before printing this, think about the environment.




          ---
          Nicholas Cancelliere
          Austin, TX



          Got *sugu on the brain* <http://ozmox. stikipad. com/ >?



          P     Before printing this, think about the environment.





      ------------ --------- --------- --------- --------- --------- --------- ------
      Enter here. Win tix to see Crowded House live at the Greek Theatre, 
      LA! 

      ---
      Nicholas Cancelliere
      Austin, TX

      Got *sugu on the brain* <http://ozmox. stikipad. com/ >?

      P     Before printing this, think about the environment.




      To Post a message, send it to:   scrumdevelopment@ eGroups.com
      To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.com 
      Yahoo! Groups Links

      <*> To visit your group on the web, go to:

      <*> Your email settings:
          Individual Email | Traditional

      <*> To change settings online go to:
          (Yahoo! ID required)

      <*> To change settings via email:

      <*> To unsubscribe from this group, send an email to:

      <*> Your use of Yahoo! Groups is subject to:


      --
      Nicholas Cancelliere, CSM/CSP
      Business Analyst, InCircuit Development
      512-347-7400 x123 -- http://www.incircui t.com

      For support on InCircuit products contact support@incircuit. com or call 800-963-1950 ext 2.

      P     Before printing this, think about the environment.


      ---
      Nicholas Cancelliere
      Austin, TX


      P     Before printing this, think about the environment.




      Find thousands of jobs online now! NEW jobsjobsjobs.com.au.
    • 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.