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

Re: [scrumdevelopment] Estimation of Bug Fixes

Expand Messages
  • Nicholas Cancelliere
    Yes. I actually had someone ask me that at a luncheon just this week. The question posed was How do you estimate how long a project is going to take at the
    Message 1 of 37 , Jan 29, 2008
    • 0 Attachment

      Yes.  I actually had someone ask me that at a luncheon just this week.  The question posed was "How do you estimate how long a project is going to take at the start of the project so you know how much to bill the client in the contract, when using Scrum?"  I asked some questions like, "Do you have a prioritized backlog defined with gross estimates? Are you working with a new team or existing team?"  I tried to tell him that with a backlog, and some gross estimates and a team's velocity you can take a guess -- better than you could with a team you never worked with before.  They acknowledged that "Yes, once you get going into a few sprints you'll know how long it'll take -- but how do you know at the start?"

      My reply ended up being -- "Well how do you estimate such things with a waterfall project?"  I mean regardless if it's Scrum or waterfall -- if you only know so much you can only guess with so much degree of accuracy.  The benefit of Scrum isn't in having better "up front" estimates but the knowledge of where you are much sooner than a waterfall project.  Are we going to make the release date?  Scrum can tell you this after a few sprints, while a waterfall project might still be in requirements analysis with no certain answers.

      I don't think Scrum tells you how to make contracts with your customers that end up being profitable for you in the end (any more than waterfall) ... at least last I checked that's not what Scrum is for.  That takes experience and some business savvy.

      Nicholas


      On Jan 28, 2008, at 5:34 PM, Roy Morien wrote:

      In my experience, the single most important stopper to the acceptance of agile development methods is this problem of 'up front' estimates. No matter how inaccurate that usually is, not matter how often that estimate has been wrong, people still ask 'But how can you give a correct estimate to the client at the start of the project of you don't know all the requirements at the start?'

      --
      Nicholas Cancelliere, CSM/CSP
      Austin, TX 

      Certified Scrum Practitioner
      Certified Scrum Master

      Over 10 years of web application development experience and an Agile nut!

    • Nicholas Cancelliere
      Yes. I actually had someone ask me that at a luncheon just this week. The question posed was How do you estimate how long a project is going to take at the
      Message 37 of 37 , Jan 29, 2008
      • 0 Attachment

        Yes.  I actually had someone ask me that at a luncheon just this week.  The question posed was "How do you estimate how long a project is going to take at the start of the project so you know how much to bill the client in the contract, when using Scrum?"  I asked some questions like, "Do you have a prioritized backlog defined with gross estimates? Are you working with a new team or existing team?"  I tried to tell him that with a backlog, and some gross estimates and a team's velocity you can take a guess -- better than you could with a team you never worked with before.  They acknowledged that "Yes, once you get going into a few sprints you'll know how long it'll take -- but how do you know at the start?"

        My reply ended up being -- "Well how do you estimate such things with a waterfall project?"  I mean regardless if it's Scrum or waterfall -- if you only know so much you can only guess with so much degree of accuracy.  The benefit of Scrum isn't in having better "up front" estimates but the knowledge of where you are much sooner than a waterfall project.  Are we going to make the release date?  Scrum can tell you this after a few sprints, while a waterfall project might still be in requirements analysis with no certain answers.

        I don't think Scrum tells you how to make contracts with your customers that end up being profitable for you in the end (any more than waterfall) ... at least last I checked that's not what Scrum is for.  That takes experience and some business savvy.

        Nicholas


        On Jan 28, 2008, at 5:34 PM, Roy Morien wrote:

        In my experience, the single most important stopper to the acceptance of agile development methods is this problem of 'up front' estimates. No matter how inaccurate that usually is, not matter how often that estimate has been wrong, people still ask 'But how can you give a correct estimate to the client at the start of the project of you don't know all the requirements at the start?'

        --
        Nicholas Cancelliere, CSM/CSP
        Austin, TX 

        Certified Scrum Practitioner
        Certified Scrum Master

        Over 10 years of web application development experience and an Agile nut!

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