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

Re: [scrumdevelopment] Tips for moving away from (or improving) estimation, when customer requires estimate before deciding to commit.

Expand Messages
  • Adam Sroka
    Dropping story points won t damage the tools. Treat every story as if it were one point. I have done this with clients who used both Version One and Rally.
    Message 1 of 98 , Oct 21, 2012
      Dropping story points won't damage the tools. Treat every story as if it were one point. I have done this with clients who used both Version One and Rally. Works just fine, very few complaints (A few by people who had invested a lot in learning how to use them.) 

      However, release planning is mostly a waste of time. The backlog should be changing because people should be learning things. If the backlog is changing the forecasts will be wrong. If the backlog is not changing something else is broken in your process. 

      I am a strong advocate of story planning. However, what has always worked best for me in a software context is to very quickly create a rough sketch, discuss it with my team, throw it in the recycle bin, and then go back to writing the software. 

      Also, the most important releases are the one I just did and the one I'll do before beers tonight. Make your releases smaller. It is the best change you could possibly make to any software product. 

      On Sun, Oct 21, 2012 at 8:49 AM, Jean Richardson <jean@...> wrote:
       

      Ron –

       

      This is not specific to a particular situation but to a particular practice.  Enterprises use story pointing to plan releases and through the release planning process coordinate across the enterprise regarding delivery and possible impediments to delivery at the enterprise level.  Tools such as Rally and Version One not only support but seem to encourage this.

       

      Story pointing has been broadly applied for release planning.  You noted earlier that you invented them and no longer recommend them.  I’m interested to know what you suggest as an alternative to story pointing as a means of doing release planning or even in helping the Product Owner determine how much of the backlog is it reasonable to request that the Team consume in the next sprint.

       

      --- Jean

       

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of RonJeffries
      Sent: Friday, October 19, 2012 5:59 PM


      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Tips for moving away from (or improving) estimation, when customer requires estimate before deciding to commit.

       

       

       

      On Oct 19, 2012, at 8:11 PM, "Jean Richardson" <jean@...> wrote:



      Seems to sidestep the question. 

       

      No. I need to know what you are getting before I can tell you how I'd get it. (Or, as is possible, explain why that's not something I'd recommend trying to get.)


      Assume the model described in Cohn's /User Stories Applied/ for the purposes of this discussion. 

       

      I'm happy to answer your question, but not to dig Mike's book off the shelf and reread that section. If you'd like to know what I'd do in your situation, I need to understand your situation.


      Ron Jeffries

      www.XProgramming.com

      It's true hard work never killed anybody, but I figure, why take the chance?

      -- Ronald Reagan

       

       

       


    • Adam Sroka
      Dropping story points won t damage the tools. Treat every story as if it were one point. I have done this with clients who used both Version One and Rally.
      Message 98 of 98 , Oct 21, 2012
        Dropping story points won't damage the tools. Treat every story as if it were one point. I have done this with clients who used both Version One and Rally. Works just fine, very few complaints (A few by people who had invested a lot in learning how to use them.) 

        However, release planning is mostly a waste of time. The backlog should be changing because people should be learning things. If the backlog is changing the forecasts will be wrong. If the backlog is not changing something else is broken in your process. 

        I am a strong advocate of story planning. However, what has always worked best for me in a software context is to very quickly create a rough sketch, discuss it with my team, throw it in the recycle bin, and then go back to writing the software. 

        Also, the most important releases are the one I just did and the one I'll do before beers tonight. Make your releases smaller. It is the best change you could possibly make to any software product. 

        On Sun, Oct 21, 2012 at 8:49 AM, Jean Richardson <jean@...> wrote:
         

        Ron –

         

        This is not specific to a particular situation but to a particular practice.  Enterprises use story pointing to plan releases and through the release planning process coordinate across the enterprise regarding delivery and possible impediments to delivery at the enterprise level.  Tools such as Rally and Version One not only support but seem to encourage this.

         

        Story pointing has been broadly applied for release planning.  You noted earlier that you invented them and no longer recommend them.  I’m interested to know what you suggest as an alternative to story pointing as a means of doing release planning or even in helping the Product Owner determine how much of the backlog is it reasonable to request that the Team consume in the next sprint.

         

        --- Jean

         

        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of RonJeffries
        Sent: Friday, October 19, 2012 5:59 PM


        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] Tips for moving away from (or improving) estimation, when customer requires estimate before deciding to commit.

         

         

         

        On Oct 19, 2012, at 8:11 PM, "Jean Richardson" <jean@...> wrote:



        Seems to sidestep the question. 

         

        No. I need to know what you are getting before I can tell you how I'd get it. (Or, as is possible, explain why that's not something I'd recommend trying to get.)


        Assume the model described in Cohn's /User Stories Applied/ for the purposes of this discussion. 

         

        I'm happy to answer your question, but not to dig Mike's book off the shelf and reread that section. If you'd like to know what I'd do in your situation, I need to understand your situation.


        Ron Jeffries

        www.XProgramming.com

        It's true hard work never killed anybody, but I figure, why take the chance?

        -- Ronald Reagan

         

         

         


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