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

Story point estimating - ideal time vs relative scale

Expand Messages
  • Michael Jones
    Hi, We re rolling out an agile process in my company, where waterfall processes have been used up to now. I ve been involved in a couple of discussions/debates
    Message 1 of 25 , Sep 27, 2011
    • 0 Attachment
      Hi,

      We're rolling out an agile process in my company, where waterfall processes have been used up to now.

      I've been involved in a couple of discussions/debates with various folk here (a product manager and a fellow PM) about the units developers should use to estimate user stories in the sprint planning meeting. Specifically whether to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the same as that registration form we did").

      I have my own views, but what are your thoughts? Are there any stand-out benefits of either in your experience? Should we throw it as an open question to our developers?

      Thanks,
      Michael
    • Lukasz Szyrmer
      Michael, While it takes some time to get used to story points, it s easier to be honest with them. By honest, I mean that they are better at forcing
      Message 2 of 25 , Sep 27, 2011
      • 0 Attachment

        Michael,

         

        While it takes some time to get used to story points, it’s easier to be “honest” with them. By honest, I mean that they are better at forcing discussion in the group so that all potential problems known about up front are discussed. Also, with time units it’s hard to remember that these are supposed to be estimates, and not contracts to deliver within a certain time frame.

         

        Luke


         
        Linedata Limited
        Registered Office: 85 Gracechurch St., London, EC3V 0AA
        Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
         

         

         

        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael Jones
        Sent: 27 September 2011 14:34
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Story point estimating - ideal time vs relative scale
        Importance: High

         

         

        Hi,

        We're rolling out an agile process in my company, where waterfall processes have been used up to now.

        I've been involved in a couple of discussions/debates with various folk here (a product manager and a fellow PM) about the units developers should use to estimate user stories in the sprint planning meeting. Specifically whether to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the same as that registration form we did").

        I have my own views, but what are your thoughts? Are there any stand-out benefits of either in your experience? Should we throw it as an open question to our developers?

        Thanks,
        Michael

      • RonJeffries
        Hello, Michael, ... Why do you want to estimate user stories in the sprint planning meeting ? Ron Jeffries www.XProgramming.com I m really pissed off by what
        Message 3 of 25 , Sep 27, 2011
        • 0 Attachment
          Hello, Michael,

          On Sep 27, 2011, at 9:34 AM, Michael Jones wrote:

          We're rolling out an agile process in my company, where waterfall processes have been used up to now. 

          I've been involved in a couple of discussions/debates with various folk here (a product manager and a fellow PM) about the units developers should use to estimate user stories in the sprint planning meeting. Specifically whether to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the same as that registration form we did"). 

          I have my own views, but what are your thoughts? Are there any stand-out benefits of either in your experience? Should we throw it as an open question to our developers? 

          Why do you want to "estimate user stories in the sprint planning meeting"?

          Ron Jeffries
          I'm really pissed off by what people are passing off as "agile" these days.
          You may have a red car, but that does not make it a Ferrari.
            -- Steve Hayes

        • Michael Jones
          Hi Ron, Ah - I mean development items - the user stories are ballpark-estimated as they re added to the product backlog; then in the sprint planning meeting,
          Message 4 of 25 , Sep 27, 2011
          • 0 Attachment
            Hi Ron,

            Ah - I mean development items - the user stories are ballpark-estimated as they're added to the product backlog; then in the sprint planning meeting, they're decomposed by the developers into development items that make sense to them, and estimated by the developers at the same time.

            Is that nearer the mark?

            Thanks,
            Michael


            On Tue, Sep 27, 2011 at 2:39 PM, RonJeffries <ronjeffries@...> wrote:
             

            Hello, Michael,


            On Sep 27, 2011, at 9:34 AM, Michael Jones wrote:

            We're rolling out an agile process in my company, where waterfall processes have been used up to now. 

            I've been involved in a couple of discussions/debates with various folk here (a product manager and a fellow PM) about the units developers should use to estimate user stories in the sprint planning meeting. Specifically whether to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the same as that registration form we did"). 

            I have my own views, but what are your thoughts? Are there any stand-out benefits of either in your experience? Should we throw it as an open question to our developers? 

            Why do you want to "estimate user stories in the sprint planning meeting"?

            Ron Jeffries
            I'm really pissed off by what people are passing off as "agile" these days.
            You may have a red car, but that does not make it a Ferrari.
              -- Steve Hayes


          • Michael Jones
            Hi Ron, Ah - I mean development items - the user stories are ballpark-estimated as they re added to the product backlog; then in the sprint planning meeting,
            Message 5 of 25 , Sep 27, 2011
            • 0 Attachment
              Hi Ron,

              Ah - I mean development items - the user stories are ballpark-estimated as they're added to the product backlog; then in the sprint planning meeting, they're decomposed by the developers into development items that make sense to them, and estimated by the developers at the same time.

              Is that nearer the mark?

              Thanks,
              Michael


              On Tue, Sep 27, 2011 at 2:39 PM, RonJeffries <ronjeffries@...> wrote:
               

              Hello, Michael,


              On Sep 27, 2011, at 9:34 AM, Michael Jones wrote:

              We're rolling out an agile process in my company, where waterfall processes have been used up to now. 

              I've been involved in a couple of discussions/debates with various folk here (a product manager and a fellow PM) about the units developers should use to estimate user stories in the sprint planning meeting. Specifically whether to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the same as that registration form we did"). 

              I have my own views, but what are your thoughts? Are there any stand-out benefits of either in your experience? Should we throw it as an open question to our developers? 

              Why do you want to "estimate user stories in the sprint planning meeting"?

              Ron Jeffries
              I'm really pissed off by what people are passing off as "agile" these days.
              You may have a red car, but that does not make it a Ferrari.
                -- Steve Hayes


            • RonJeffries
              Hi Michael, ... I m wondering why you want to assign estimates to the items. What will those estimates give you? What would you lose if you didn t estimate
              Message 6 of 25 , Sep 27, 2011
              • 0 Attachment
                Hi Michael,

                On Sep 27, 2011, at 9:48 AM, Michael Jones wrote:

                Ah - I mean development items - the user stories are ballpark-estimated as they're added to the product backlog; then in the sprint planning meeting, they're decomposed by the developers into development items that make sense to them, and estimated by the developers at the same time. 

                Is that nearer the mark? 

                I'm wondering why you want to assign estimates to the items. What will those estimates give you? What would you lose if you didn't estimate them?

                Ron Jeffries
                If it is more than you need, it is waste. -- Andy Seidl

              • Michael Jones
                Hi Ron, Well, prior to being tempted to reconsider by your questions, I would have said: The estimates are needed - to know which development items (and
                Message 7 of 25 , Sep 27, 2011
                • 0 Attachment
                  Hi Ron,

                  Well, prior to being tempted to reconsider by your questions, I would have said:

                  The estimates are needed
                  - to know which development items (and therefore which features) we can commit to delivering in the sprint.
                  - to give a velocity for the sprint (at the end of the sprint). 

                  I guess the thinking is that the user stories are ball-park estimated, but when we decompose them in the meeting, more will be known about the specific approach so we can estimate with more accuracy. But maybe the ballpark accuracy is enough?

                  Thanks again,
                  Michael


                  On Tue, Sep 27, 2011 at 3:13 PM, RonJeffries <ronjeffries@...> wrote:
                   

                  Hi Michael,


                  On Sep 27, 2011, at 9:48 AM, Michael Jones wrote:

                  Ah - I mean development items - the user stories are ballpark-estimated as they're added to the product backlog; then in the sprint planning meeting, they're decomposed by the developers into development items that make sense to them, and estimated by the developers at the same time. 

                  Is that nearer the mark? 

                  I'm wondering why you want to assign estimates to the items. What will those estimates give you? What would you lose if you didn't estimate them?
                  If it is more than you need, it is waste. -- Andy Seidl


                • Michael Jones
                  (just answering the second part of the question) So I guess by not having them we lose a sense of what and how much we can do in the coming sprint, and in our
                  Message 8 of 25 , Sep 27, 2011
                  • 0 Attachment
                    (just answering the second part of the question)

                    So I guess by not having them we lose a sense of what and how much we can do in the coming sprint, and in our sprints in general.

                    On Tue, Sep 27, 2011 at 3:48 PM, Michael Jones <michaelhardwinjones@...> wrote:
                    Hi Ron,

                    Well, prior to being tempted to reconsider by your questions, I would have said:

                    The estimates are needed
                    - to know which development items (and therefore which features) we can commit to delivering in the sprint.
                    - to give a velocity for the sprint (at the end of the sprint). 

                    I guess the thinking is that the user stories are ball-park estimated, but when we decompose them in the meeting, more will be known about the specific approach so we can estimate with more accuracy. But maybe the ballpark accuracy is enough?

                    Thanks again,
                    Michael


                    On Tue, Sep 27, 2011 at 3:13 PM, RonJeffries <ronjeffries@...> wrote:
                     

                    Hi Michael,


                    On Sep 27, 2011, at 9:48 AM, Michael Jones wrote:

                    Ah - I mean development items - the user stories are ballpark-estimated as they're added to the product backlog; then in the sprint planning meeting, they're decomposed by the developers into development items that make sense to them, and estimated by the developers at the same time. 

                    Is that nearer the mark? 

                    I'm wondering why you want to assign estimates to the items. What will those estimates give you? What would you lose if you didn't estimate them?
                    If it is more than you need, it is waste. -- Andy Seidl



                  • RonJeffries
                    Hi Michael, ... Is there some other way to have that sense ? Ron Jeffries www.XProgramming.com I m not bad, I m just drawn that way. -- Jessica Rabbit
                    Message 9 of 25 , Sep 27, 2011
                    • 0 Attachment
                      Hi Michael,

                      On Sep 27, 2011, at 10:49 AM, Michael Jones wrote:

                      So I guess by not having them we lose a sense of what and how much we can do in the coming sprint, and in our sprints in general. 

                      Is there some other way to have that "sense"?

                      Ron Jeffries
                      I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

                    • Michael Jones
                      Hi Ron, I suppose over time, as a team, we would get a sense of how much work the team can do in a sprint, at a very high level - for example 2 medium-weight
                      Message 10 of 25 , Sep 27, 2011
                      • 0 Attachment
                        Hi Ron,

                        I suppose over time, as a team, we would get a sense of how much work the team can do in a sprint, at a very high level - for example "2 medium-weight new features and 8 bug fixes". That's probably just as accurate as meticulously adding up the micro-estimates for all the development items. Is that what you're getting at? But by keeping things at such a high level we may lose the ability to understand the rate at which the work is being done during the sprint. And we also don't have a commonly-agreed measure of average performance (or velocity) between sprints (just a notion in our heads of what's reasonable, which may vary between team members).

                        So the inclusion of x amount of work in a sprint may feel too arbitrary if not backed up by numbers (i.e. that x bundle of work equates to e.g. 20 ideal hours, or to 20 story points etc). I do get the point though that those estimates are ultimately arbitrary themselves.

                        Look forward to your thoughts,
                        Michael


                        On Tue, Sep 27, 2011 at 3:53 PM, RonJeffries <ronjeffries@...> wrote:
                         

                        Hi Michael,


                        On Sep 27, 2011, at 10:49 AM, Michael Jones wrote:

                        So I guess by not having them we lose a sense of what and how much we can do in the coming sprint, and in our sprints in general. 

                        Is there some other way to have that "sense"?
                        I'm not bad, I'm just drawn that way.  -- Jessica Rabbit


                      • woynam
                        The velocity based on story estimates should be enough. If you re consistent with your approach to estimating story size, then it won t matter if a 2 point
                        Message 11 of 25 , Sep 27, 2011
                        • 0 Attachment
                          The velocity based on story estimates should be enough. If you're consistent with your approach to estimating story size, then it won't matter if a 2 point story equates to 16 hours of estimates tasks, or 64 hours.

                          After a handful of Sprints, you'll know how many points you can tackle for each Sprint.

                          Mark

                          --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
                          >
                          > Hi Ron,
                          >
                          > I suppose over time, as a team, we would get a sense of how much work the
                          > team can do in a sprint, at a very high level - for example "2 medium-weight
                          > new features and 8 bug fixes". That's probably just as accurate as
                          > meticulously adding up the micro-estimates for all the development items. Is
                          > that what you're getting at? But by keeping things at such a high level we
                          > may lose the ability to understand the rate at which the work is being done
                          > during the sprint. And we also don't have a commonly-agreed measure of
                          > average performance (or velocity) between sprints (just a notion in our
                          > heads of what's reasonable, which may vary between team members).
                          >
                          > So the inclusion of *x *amount of work in a sprint may feel too arbitrary if
                          > not backed up by numbers (i.e. that *x *bundle of work equates to e.g. 20
                          > ideal hours, or to 20 story points etc). I do get the point though that
                          > those estimates are ultimately arbitrary themselves.
                          >
                          > Look forward to your thoughts,
                          > Michael
                          >
                          >
                          > On Tue, Sep 27, 2011 at 3:53 PM, RonJeffries <ronjeffries@...> wrote:
                          >
                          > > **
                          > >
                          > >
                          > > Hi Michael,
                          > >
                          > > On Sep 27, 2011, at 10:49 AM, Michael Jones wrote:
                          > >
                          > > So I guess by not having them we lose a sense of what and how much we can
                          > > do in the coming sprint, and in our sprints in general.
                          > >
                          > >
                          > > Is there some other way to have that "sense"?
                          > >
                          > > Ron Jeffries
                          > > www.XProgramming.com <http://www.xprogramming.com>
                          > > I'm not bad, I'm just drawn that way. -- Jessica Rabbit
                          > >
                          > >
                          > >
                          >
                        • Steve
                          Hi Michael You wrote ... we also don t have a commonly-agreed measure of average performance (or velocity) between sprints (just a notion in our heads of
                          Message 12 of 25 , Sep 27, 2011
                          • 0 Attachment
                            Hi Michael

                            You wrote "... we also don't have a commonly-agreed measure of average performance (or velocity) between sprints (just a notion in our heads of what's reasonable, which may vary between team members"

                            If the Team consistently complete stories that represent planning points that add up to a small variation about a mean number, how can it be possible that individual Tream memebers have differing views about what the velocity is?!!

                            What units are you using for estimating the PBI?

                            --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
                            >
                            > Hi Ron,
                            >
                            > I suppose over time, as a team, we would get a sense of how much work the
                            > team can do in a sprint, at a very high level - for example "2 medium-weight
                            > new features and 8 bug fixes". That's probably just as accurate as
                            > meticulously adding up the micro-estimates for all the development items. Is
                            > that what you're getting at? But by keeping things at such a high level we
                            > may lose the ability to understand the rate at which the work is being done
                            > during the sprint. And we also don't have a commonly-agreed measure of
                            > average performance (or velocity) between sprints (just a notion in our
                            > heads of what's reasonable, which may vary between team members).
                            >
                            > So the inclusion of *x *amount of work in a sprint may feel too arbitrary if
                            > not backed up by numbers (i.e. that *x *bundle of work equates to e.g. 20
                            > ideal hours, or to 20 story points etc). I do get the point though that
                            > those estimates are ultimately arbitrary themselves.
                            >
                            > Look forward to your thoughts,
                            > Michael
                            >
                            >
                            > On Tue, Sep 27, 2011 at 3:53 PM, RonJeffries <ronjeffries@...> wrote:
                            >
                            > > **
                            > >
                            > >
                            > > Hi Michael,
                            > >
                            > > On Sep 27, 2011, at 10:49 AM, Michael Jones wrote:
                            > >
                            > > So I guess by not having them we lose a sense of what and how much we can
                            > > do in the coming sprint, and in our sprints in general.
                            > >
                            > >
                            > > Is there some other way to have that "sense"?
                            > >
                            > > Ron Jeffries
                            > > www.XProgramming.com <http://www.xprogramming.com>
                            > > I'm not bad, I'm just drawn that way. -- Jessica Rabbit
                            > >
                            > >
                            > >
                            >
                          • Dan Rawsthorne
                            Just to make it more interesting, that s only half the question. The other half is: what kind of size are we estimating, anyway? Is it effort, or size? where
                            Message 13 of 25 , Sep 27, 2011
                            • 0 Attachment
                              Just to make it more interesting, that's only half the question. The other half is: "what kind of size are we estimating, anyway?" Is it effort, or size? where size is quantity of product... like # of passing tests, Function Points, Use Case Points, etc. Personally, I prefer relative size, and I think that actual idealized effort is the worst one to use. (see chapter 3.7)

                              Dan  ;-)

                              Dan Rawsthorne, PhD, PMP, CST

                              Author of Exploring Scrum: the Fundamentals,

                                   http://www.amazon.com/dp/1461160286



                              On Tue, Sep 27, 2011 at 6:34 AM, Michael Jones <michaelhardwinjones@...> wrote:
                               

                              Hi,

                              We're rolling out an agile process in my company, where waterfall processes have been used up to now.

                              I've been involved in a couple of discussions/debates with various folk here (a product manager and a fellow PM) about the units developers should use to estimate user stories in the sprint planning meeting. Specifically whether to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the same as that registration form we did").

                              I have my own views, but what are your thoughts? Are there any stand-out benefits of either in your experience? Should we throw it as an open question to our developers?

                              Thanks,
                              Michael


                            • woynam
                              There s no reason why ideal hours can t be used in the estimation process, as long as everyone understands and agrees that an ideal hour != real hour. We
                              Message 14 of 25 , Sep 28, 2011
                              • 0 Attachment
                                There's no reason why "ideal" hours can't be used in the estimation process, as long as everyone understands and agrees that an "ideal" hour != real hour.

                                We used ideal hours for years, and our velocity was consistently at ~60% of real hours. A handful of managers would always ask where we were "losing" productivity, and I'd basically say "everywhere", which was a nice way of saying that "sh&t happens".

                                Fundamentally, it doesn't matter what unit of measurement you use to estimate a PBI, as long as you apply it consistently. Your velocity will be your guide to how much stuff to pull off the backlog each Sprint.

                                If you take a single story, and have two relatively teams estimate it, then you just might get to very different answers. That's OK, because the team with the higher number will appear to have a higher velocity, but the fact remains that they'll both get the same amount of real work done.

                                I always believed that the U.S. should have switched to the metric system, so I can travel 100 on the highways. :-)

                                Mark


                                --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
                                >
                                > Hi Ron,
                                >
                                > I suppose over time, as a team, we would get a sense of how much work the
                                > team can do in a sprint, at a very high level - for example "2 medium-weight
                                > new features and 8 bug fixes". That's probably just as accurate as
                                > meticulously adding up the micro-estimates for all the development items. Is
                                > that what you're getting at? But by keeping things at such a high level we
                                > may lose the ability to understand the rate at which the work is being done
                                > during the sprint. And we also don't have a commonly-agreed measure of
                                > average performance (or velocity) between sprints (just a notion in our
                                > heads of what's reasonable, which may vary between team members).
                                >
                                > So the inclusion of *x *amount of work in a sprint may feel too arbitrary if
                                > not backed up by numbers (i.e. that *x *bundle of work equates to e.g. 20
                                > ideal hours, or to 20 story points etc). I do get the point though that
                                > those estimates are ultimately arbitrary themselves.
                                >
                                > Look forward to your thoughts,
                                > Michael
                                >
                                >
                                > On Tue, Sep 27, 2011 at 3:53 PM, RonJeffries <ronjeffries@...> wrote:
                                >
                                > > **
                                > >
                                > >
                                > > Hi Michael,
                                > >
                                > > On Sep 27, 2011, at 10:49 AM, Michael Jones wrote:
                                > >
                                > > So I guess by not having them we lose a sense of what and how much we can
                                > > do in the coming sprint, and in our sprints in general.
                                > >
                                > >
                                > > Is there some other way to have that "sense"?
                                > >
                                > > Ron Jeffries
                                > > www.XProgramming.com <http://www.xprogramming.com>
                                > > I'm not bad, I'm just drawn that way. -- Jessica Rabbit
                                > >
                                > >
                                > >
                                >
                              • Reinert
                                Hi, There are a lot of advantages if you go for using only story points in your estimation of user stories. I.e. abondoning hours / time totally in all your
                                Message 15 of 25 , Oct 7, 2011
                                • 0 Attachment
                                  Hi,

                                  There are a lot of advantages if you go for using only story points in your estimation of user stories. I.e. abondoning hours / time totally in all your estimates including (developer) tasks. If you are interested in more information, please check out www.rapidscrum.com. The link "AgileIndy Presentation: Hours are Dead" under "RESOURCES" gives you some more information. I've used many of the techniques he is describing and though they are quite unfamiliar, they are very powerful.

                                  Reinert

                                  --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
                                  >
                                  > Hi,
                                  >
                                  > We're rolling out an agile process in my company, where waterfall processes
                                  > have been used up to now.
                                  >
                                  > I've been involved in a couple of discussions/debates with various folk here
                                  > (a product manager and a fellow PM) about the units developers should use to
                                  > estimate user stories in the sprint planning meeting. Specifically whether
                                  > to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the
                                  > same as that registration form we did").
                                  >
                                  > I have my own views, but what are your thoughts? Are there any stand-out
                                  > benefits of either in your experience? Should we throw it as an open
                                  > question to our developers?
                                  >
                                  > Thanks,
                                  > Michael
                                  >
                                • m.babrawala@yahoo.com
                                  ... From: Reinert Sent: 07/10/2011, 1:38 PM To: scrumdevelopment@yahoogroups.com Subject: [scrumdevelopment] Re: Story point estimating - ideal time vs
                                  Message 16 of 25 , Oct 7, 2011
                                  • 0 Attachment
                                    -----Original Message-----
                                    From: Reinert
                                    Sent: 07/10/2011, 1:38 PM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: [scrumdevelopment] Re: Story point estimating - ideal time vs relative scale




                                    Hi,

                                    There are a lot of advantages if you go for using only story points in your estimation of user stories. I.e. abondoning hours / time totally in all your estimates including (developer) tasks. If you are interested in more information, please check out www.rapidscrum.com. The link "AgileIndy Presentation: Hours are Dead" under "RESOURCES" gives you some more information. I've used many of the techniques he is describing and though they are quite unfamiliar, they are very powerful.

                                    Reinert

                                    --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
                                    >
                                    > Hi,
                                    >
                                    > We're rolling out an agile process in my company, where waterfall processes
                                    > have been used up to now.
                                    >
                                    > I've been involved in a couple of discussions/debates with various folk here
                                    > (a product manager and a fellow PM) about the units developers should use to
                                    > estimate user stories in the sprint planning meeting. Specifically whether
                                    > to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the
                                    > same as that registration form we did").
                                    >
                                    > I have my own views, but what are your thoughts? Are there any stand-out
                                    > benefits of either in your experience? Should we throw it as an open
                                    > question to our developers?
                                    >
                                    > Thanks,
                                    > Michael
                                    >
                                  • Joe
                                    Hi Michael, I would DEFINITELY do story points. Ideal hours do not actually communicate effort well (people won t agree what an ideal hour really means).
                                    Message 17 of 25 , Oct 7, 2011
                                    • 0 Attachment
                                      Hi Michael,

                                      I would DEFINITELY do story points.

                                      Ideal hours do not actually communicate effort well (people won't agree what an ideal hour really means).
                                      People are terrible at estimating time. Relative size/complexity gets estimated much better, and is much less likely to be skewed (usually under or over estimated).
                                      Story points comes back to time as soon as you declare "this team can do about 20 story points per 2-week sprint".
                                      Only the output of the team is meaningful...THAT's what we need to know, and then we need to know how to fill (but not over-fill) that capacity of the team, each sprint.
                                      QED: Story points. (Well, the short version of the case.)

                                      Don't ask them to agree to do story points. They have no experience, their answer is not meaningful...at least until they have experience. Say, "we're gonna do this new well-established technique." And give it at least 4 sprints. You can tell them it's an experiment and if is terrible after 4 sprints, we'll change it. (It won't be if anyone is professional around there.)

                                      You might need a good coach to have the authority and the detailed experience to make it work better from Day 1. Seems expensive, but it is not compared to the alternative.

                                      Regards,
                                      Joe

                                      LeanAgileTraining.com


                                      --- In scrumdevelopment@yahoogroups.com, "Reinert" <rekahm@...> wrote:
                                      >
                                      >
                                      >
                                      > Hi,
                                      >
                                      > There are a lot of advantages if you go for using only story points in your estimation of user stories. I.e. abondoning hours / time totally in all your estimates including (developer) tasks. If you are interested in more information, please check out www.rapidscrum.com. The link "AgileIndy Presentation: Hours are Dead" under "RESOURCES" gives you some more information. I've used many of the techniques he is describing and though they are quite unfamiliar, they are very powerful.
                                      >
                                      > Reinert
                                      >
                                      > --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@> wrote:
                                      > >
                                      > > Hi,
                                      > >
                                      > > We're rolling out an agile process in my company, where waterfall processes
                                      > > have been used up to now.
                                      > >
                                      > > I've been involved in a couple of discussions/debates with various folk here
                                      > > (a product manager and a fellow PM) about the units developers should use to
                                      > > estimate user stories in the sprint planning meeting. Specifically whether
                                      > > to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the
                                      > > same as that registration form we did").
                                      > >
                                      > > I have my own views, but what are your thoughts? Are there any stand-out
                                      > > benefits of either in your experience? Should we throw it as an open
                                      > > question to our developers?
                                      > >
                                      > > Thanks,
                                      > > Michael
                                      > >
                                      >
                                    • Michael Jones
                                      Hi all, Now this is getting interesting - the consensus I think until Reinert and Joe s posts was that (summed up by Mark) Fundamentally, it doesn t matter
                                      Message 18 of 25 , Oct 7, 2011
                                      • 0 Attachment
                                        Hi all,

                                        Now this is getting interesting - the consensus I think until Reinert and Joe's posts was that (summed up by Mark) "Fundamentally, it doesn't matter what unit of measurement you use to estimate a PBI, as long as you apply it consistently."

                                        I completely agree with that.

                                        I understand where relative scale story points (instead of ideal hours story points) might have value on a psychological level, because they obfuscate the fact that we're actually talking about time, allowing developers to relax and give estimates free from the feeling that they're going to be tied to some time measure. (even though they wouldn't be if we were using ideal hours, because everyone should know ideal hours != real hours).

                                        My problem comes when people try to make claims for relative scale story points that are bigger than that, because as you admit Joe an RSSP always resolves to time - e.g. "this team can do about 20 story points per 2-week sprint"; so if there are 120 person hours in the sprint, each story point is 6 hours.

                                        When someone imagines the effort involved in building a registration form, for example, they're doing it in terms of time (or if there's any other variable, we're probably not interested in it). Whatever scale they decide for 1 point resolves to some measure of time.

                                        So it's essentially the same thing, but with RSSP you're just not admitting the underlying "exchange rate", which is there nonetheless. So there's no advantage of RSSP except for that psychological mechanism (which only prevails for those developers who don't get around to making the conversion in their own heads).

                                        All the advantages and disadvantages of RSSP are the same with ideal hours - e.g.:
                                        - "people won't agree what an ideal hour really means" - people also won't agree on "how long it takes to build x"
                                        - from the rapidscrum slideshow: While Accuracy with Precision is desirable, Accuracy is the more valuable of the two. - Ideal time story points can be just as imprecise and accurate (especially if used on an exponential scale for estimating the product backlog)

                                        I realise this is all a bit philosophical. I'm happy to try RSSPs out on the basis that hiding the fact we're really talking in the end about ideal time, is helpful for people's frame of mind when estimating, and perhaps when working too ... I just don't like it when claims are made for them, that are just as apt for ideal time, and when the fact that they're really the same thing (except perhaps on that psychological level) isn't acknowledged.

                                        Cheers and have a great weekend... :)
                                        Michael

                                        Footnotes:
                                        Mike Cohn on ideal time story points:

                                        My preference is to treat a story point as an ideal day of work. We rarely have these ideal days, but thinking
                                        about stories in ideal time offers two advantages. First, it is easier than estimating in elapsed time. Estimating
                                        in elapsed time forces us to consider all other possible impacts on our time, such as the all-company meeting
                                        on Tuesday, my dentist appointment on Wednesday, a few hours a day for answering email, and so on.
                                        Second, estimating story points in ideal time gives our estimates a slightly better foundation than when they
                                        are estimated in entirely nebulous units.

                                        Henryk Kniberg:
                                        We use man-days as a basis for all time estimates (although we
                                        call it story points). Our lowest value is 0.5, i.e. any task that is smaller
                                        than 0.5 is either removed, combined with some other task, or just left
                                        with a 0.5 estimate (no great harm in overestimating slightly). Nice and
                                        simple.


                                        On Fri, Oct 7, 2011 at 4:50 PM, Joe <jhlittle@...> wrote:
                                         

                                        Hi Michael,

                                        I would DEFINITELY do story points.

                                        Ideal hours do not actually communicate effort well (people won't agree what an ideal hour really means).
                                        People are terrible at estimating time. Relative size/complexity gets estimated much better, and is much less likely to be skewed (usually under or over estimated).
                                        Story points comes back to time as soon as you declare "this team can do about 20 story points per 2-week sprint".
                                        Only the output of the team is meaningful...THAT's what we need to know, and then we need to know how to fill (but not over-fill) that capacity of the team, each sprint.
                                        QED: Story points. (Well, the short version of the case.)

                                        Don't ask them to agree to do story points. They have no experience, their answer is not meaningful...at least until they have experience. Say, "we're gonna do this new well-established technique." And give it at least 4 sprints. You can tell them it's an experiment and if is terrible after 4 sprints, we'll change it. (It won't be if anyone is professional around there.)

                                        You might need a good coach to have the authority and the detailed experience to make it work better from Day 1. Seems expensive, but it is not compared to the alternative.

                                        Regards,
                                        Joe

                                        LeanAgileTraining.com



                                        --- In scrumdevelopment@yahoogroups.com, "Reinert" <rekahm@...> wrote:
                                        >
                                        >
                                        >
                                        > Hi,
                                        >
                                        > There are a lot of advantages if you go for using only story points in your estimation of user stories. I.e. abondoning hours / time totally in all your estimates including (developer) tasks. If you are interested in more information, please check out www.rapidscrum.com. The link "AgileIndy Presentation: Hours are Dead" under "RESOURCES" gives you some more information. I've used many of the techniques he is describing and though they are quite unfamiliar, they are very powerful.
                                        >
                                        > Reinert
                                        >
                                        > --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@> wrote:
                                        > >
                                        > > Hi,
                                        > >
                                        > > We're rolling out an agile process in my company, where waterfall processes
                                        > > have been used up to now.
                                        > >
                                        > > I've been involved in a couple of discussions/debates with various folk here
                                        > > (a product manager and a fellow PM) about the units developers should use to
                                        > > estimate user stories in the sprint planning meeting. Specifically whether
                                        > > to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the
                                        > > same as that registration form we did").
                                        > >
                                        > > I have my own views, but what are your thoughts? Are there any stand-out
                                        > > benefits of either in your experience? Should we throw it as an open
                                        > > question to our developers?
                                        > >
                                        > > Thanks,
                                        > > Michael
                                        > >
                                        >


                                      • Michael Jones
                                        Just to add - what I don t like actually is when the claim is made (not saying anyone here has said this, but I think it has found its way into London Scrum
                                        Message 19 of 25 , Oct 7, 2011
                                        • 0 Attachment
                                          Just to add - what I don't like actually is when the claim is made (not saying anyone here has said this, but I think it has found its way into London Scrum culture ;), that relative scale story points are a fundamental part of true Scrum, and ideal hours aren't really Scrum. That you're "less Scrum" if you're using the latter... I think that should be challenged.

                                          On Fri, Oct 7, 2011 at 5:20 PM, Michael Jones <michaelhardwinjones@...> wrote:
                                          Hi all,

                                          Now this is getting interesting - the consensus I think until Reinert and Joe's posts was that (summed up by Mark) "Fundamentally, it doesn't matter what unit of measurement you use to estimate a PBI, as long as you apply it consistently."

                                          I completely agree with that.

                                          I understand where relative scale story points (instead of ideal hours story points) might have value on a psychological level, because they obfuscate the fact that we're actually talking about time, allowing developers to relax and give estimates free from the feeling that they're going to be tied to some time measure. (even though they wouldn't be if we were using ideal hours, because everyone should know ideal hours != real hours).

                                          My problem comes when people try to make claims for relative scale story points that are bigger than that, because as you admit Joe an RSSP always resolves to time - e.g. "this team can do about 20 story points per 2-week sprint"; so if there are 120 person hours in the sprint, each story point is 6 hours.

                                          When someone imagines the effort involved in building a registration form, for example, they're doing it in terms of time (or if there's any other variable, we're probably not interested in it). Whatever scale they decide for 1 point resolves to some measure of time.

                                          So it's essentially the same thing, but with RSSP you're just not admitting the underlying "exchange rate", which is there nonetheless. So there's no advantage of RSSP except for that psychological mechanism (which only prevails for those developers who don't get around to making the conversion in their own heads).

                                          All the advantages and disadvantages of RSSP are the same with ideal hours - e.g.:
                                          - "people won't agree what an ideal hour really means" - people also won't agree on "how long it takes to build x"
                                          - from the rapidscrum slideshow: While Accuracy with Precision is desirable, Accuracy is the more valuable of the two. - Ideal time story points can be just as imprecise and accurate (especially if used on an exponential scale for estimating the product backlog)

                                          I realise this is all a bit philosophical. I'm happy to try RSSPs out on the basis that hiding the fact we're really talking in the end about ideal time, is helpful for people's frame of mind when estimating, and perhaps when working too ... I just don't like it when claims are made for them, that are just as apt for ideal time, and when the fact that they're really the same thing (except perhaps on that psychological level) isn't acknowledged.

                                          Cheers and have a great weekend... :)
                                          Michael

                                          Footnotes:
                                          Mike Cohn on ideal time story points:

                                          My preference is to treat a story point as an ideal day of work. We rarely have these ideal days, but thinking
                                          about stories in ideal time offers two advantages. First, it is easier than estimating in elapsed time. Estimating
                                          in elapsed time forces us to consider all other possible impacts on our time, such as the all-company meeting
                                          on Tuesday, my dentist appointment on Wednesday, a few hours a day for answering email, and so on.
                                          Second, estimating story points in ideal time gives our estimates a slightly better foundation than when they
                                          are estimated in entirely nebulous units.

                                          Henryk Kniberg:
                                          We use man-days as a basis for all time estimates (although we
                                          call it story points). Our lowest value is 0.5, i.e. any task that is smaller
                                          than 0.5 is either removed, combined with some other task, or just left
                                          with a 0.5 estimate (no great harm in overestimating slightly). Nice and
                                          simple.



                                          On Fri, Oct 7, 2011 at 4:50 PM, Joe <jhlittle@...> wrote:
                                           

                                          Hi Michael,

                                          I would DEFINITELY do story points.

                                          Ideal hours do not actually communicate effort well (people won't agree what an ideal hour really means).
                                          People are terrible at estimating time. Relative size/complexity gets estimated much better, and is much less likely to be skewed (usually under or over estimated).
                                          Story points comes back to time as soon as you declare "this team can do about 20 story points per 2-week sprint".
                                          Only the output of the team is meaningful...THAT's what we need to know, and then we need to know how to fill (but not over-fill) that capacity of the team, each sprint.
                                          QED: Story points. (Well, the short version of the case.)

                                          Don't ask them to agree to do story points. They have no experience, their answer is not meaningful...at least until they have experience. Say, "we're gonna do this new well-established technique." And give it at least 4 sprints. You can tell them it's an experiment and if is terrible after 4 sprints, we'll change it. (It won't be if anyone is professional around there.)

                                          You might need a good coach to have the authority and the detailed experience to make it work better from Day 1. Seems expensive, but it is not compared to the alternative.

                                          Regards,
                                          Joe

                                          LeanAgileTraining.com



                                          --- In scrumdevelopment@yahoogroups.com, "Reinert" <rekahm@...> wrote:
                                          >
                                          >
                                          >
                                          > Hi,
                                          >
                                          > There are a lot of advantages if you go for using only story points in your estimation of user stories. I.e. abondoning hours / time totally in all your estimates including (developer) tasks. If you are interested in more information, please check out www.rapidscrum.com. The link "AgileIndy Presentation: Hours are Dead" under "RESOURCES" gives you some more information. I've used many of the techniques he is describing and though they are quite unfamiliar, they are very powerful.
                                          >
                                          > Reinert
                                          >
                                          > --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@> wrote:
                                          > >
                                          > > Hi,
                                          > >
                                          > > We're rolling out an agile process in my company, where waterfall processes
                                          > > have been used up to now.
                                          > >
                                          > > I've been involved in a couple of discussions/debates with various folk here
                                          > > (a product manager and a fellow PM) about the units developers should use to
                                          > > estimate user stories in the sprint planning meeting. Specifically whether
                                          > > to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the
                                          > > same as that registration form we did").
                                          > >
                                          > > I have my own views, but what are your thoughts? Are there any stand-out
                                          > > benefits of either in your experience? Should we throw it as an open
                                          > > question to our developers?
                                          > >
                                          > > Thanks,
                                          > > Michael
                                          > >
                                          >



                                        • Peter Stevens
                                          On 07.10.11 17:50, Joe wrote: I would DEFINITELY do story points. Ideal hours do not actually communicate effort well (people won t agree what an ideal hour
                                          Message 20 of 25 , Oct 7, 2011
                                          • 0 Attachment
                                            On 07.10.11 17:50, Joe wrote:
                                             


                                            I would DEFINITELY do story points.

                                            Ideal hours do not actually communicate effort well (people won't agree what an ideal hour really means)..


                                            Hi Joe,

                                            I would too. My first Product Owner was a paying customer. And I really did not want him to get the idea in his head that he should pay for 'Ideal hours' instead of 'elapsed hours'. Could be embarrassing. ;-)

                                            Cheers,

                                            Peter


                                            -- 
                                            Peter Stevens
                                            Scrum Trainer & Coach
                                            
                                            Switzerland: direct: +41 44 586 6450     cell: +41 79 422 6722
                                            USA:         direct: +1 202 657 6450 
                                            World:       skype:  peterstev
                                            
                                            blog:        http://scrum-breakfast.com
                                            
                                          • brendabao321
                                            Hi, Michael. I like your summery. I ve struggled with story points and real hours too. But after trying both, I realized that the real trouble comes from the
                                            Message 21 of 25 , Oct 8, 2011
                                            • 0 Attachment
                                              Hi, Michael.

                                              I like your summery. I've struggled with story points and real hours too. But after trying both, I realized that the real trouble comes from the usage of the numbers. If some one else outside the team is trying to use this number for micromanagement, it would be a trouble in either ways. But if the number is just viewed as some facts based on which team can improve themselves, it would work in both ways.

                                              So, as a Scrum Master at that time, I tried to make the story points difficult to understand outside the team. For example, make a very complex explanation when someone try to map points to hours. And show them the release burndown instead, which is much simpler to understand. Some things I've done may not seem decent, but only in this way can the team be honest about the estimation.

                                              --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
                                              >
                                              > Hi all,
                                              >
                                              > Now this is getting interesting - the consensus I think until Reinert and
                                              > Joe's posts was that (summed up by Mark) "Fundamentally, it doesn't matter
                                              > what unit of measurement you use to estimate a PBI, as long as you apply it
                                              > consistently."
                                              >
                                              > I completely agree with that.
                                              >
                                              > I understand where relative scale story points (instead of ideal hours story
                                              > points) might have value on a psychological level, because they obfuscate
                                              > the fact that we're actually talking about time, allowing developers to
                                              > relax and give estimates free from the feeling that they're going to be tied
                                              > to some time measure. (even though they wouldn't be if we were using ideal
                                              > hours, because everyone should know ideal hours != real hours).
                                              >
                                              > My problem comes when people try to make claims for relative scale story
                                              > points that are bigger than that, because as you admit Joe an RSSP always
                                              > resolves to time - e.g. "this team can do about 20 story points per 2-week
                                              > sprint"; so if there are 120 person hours in the sprint, each story point is
                                              > 6 hours.
                                              >
                                              > When someone imagines the effort involved in building a registration form,
                                              > for example, they're doing it in terms of time (or if there's any other
                                              > variable, we're probably not interested in it). Whatever scale they decide
                                              > for 1 point resolves to some measure of time.
                                              >
                                              > So it's essentially the same thing, but with RSSP you're just not admitting
                                              > the underlying "exchange rate", which is there nonetheless. So there's no
                                              > advantage of RSSP except for that psychological mechanism (which only
                                              > prevails for those developers who don't get around to making the conversion
                                              > in their own heads).
                                              >
                                              > All the advantages and disadvantages of RSSP are the same with ideal hours -
                                              > e.g.:
                                              > - "people won't agree what an ideal hour really means" - people also won't
                                              > agree on "how long it takes to build x"
                                              > - from the rapidscrum slideshow: While Accuracy with Precision is desirable,
                                              > Accuracy is the more valuable of the two. - Ideal time story points can be
                                              > just as imprecise and accurate (especially if used on an exponential scale
                                              > for estimating the product backlog)
                                              >
                                              > I realise this is all a bit philosophical. I'm happy to try RSSPs out on the
                                              > basis that hiding the fact we're really talking in the end about ideal time,
                                              > is helpful for people's frame of mind when estimating, and perhaps when
                                              > working too ... I just don't like it when claims are made for them, that are
                                              > just as apt for ideal time, and when the fact that they're really the same
                                              > thing (except perhaps on that psychological level) isn't acknowledged.
                                              >
                                              > Cheers and have a great weekend... :)
                                              > Michael
                                              >
                                              > Footnotes:
                                              > Mike Cohn on ideal time story points:
                                              >
                                              > My preference is to treat a story point as an ideal day of work. We rarely
                                              > have these ideal days, but thinking
                                              > about stories in ideal time offers two advantages. First, it is easier than
                                              > estimating in elapsed time. Estimating
                                              > in elapsed time forces us to consider all other possible impacts on our
                                              > time, such as the all-company meeting
                                              > on Tuesday, my dentist appointment on Wednesday, a few hours a day for
                                              > answering email, and so on.
                                              > Second, estimating story points in ideal time gives our estimates a slightly
                                              > better foundation than when they
                                              > are estimated in entirely nebulous units.
                                              >
                                              > Henryk Kniberg:
                                              > We use man-days as a basis for all time estimates (although we
                                              > call it story points). Our lowest value is 0.5, i.e. any task that is
                                              > smaller
                                              > than 0.5 is either removed, combined with some other task, or just left
                                              > with a 0.5 estimate (no great harm in overestimating slightly). Nice and
                                              > simple.
                                              >
                                              >
                                              > On Fri, Oct 7, 2011 at 4:50 PM, Joe <jhlittle@...> wrote:
                                              >
                                              > > **
                                              > >
                                              > >
                                              > > Hi Michael,
                                              > >
                                              > > I would DEFINITELY do story points.
                                              > >
                                              > > Ideal hours do not actually communicate effort well (people won't agree
                                              > > what an ideal hour really means).
                                              > > People are terrible at estimating time. Relative size/complexity gets
                                              > > estimated much better, and is much less likely to be skewed (usually under
                                              > > or over estimated).
                                              > > Story points comes back to time as soon as you declare "this team can do
                                              > > about 20 story points per 2-week sprint".
                                              > > Only the output of the team is meaningful...THAT's what we need to know,
                                              > > and then we need to know how to fill (but not over-fill) that capacity of
                                              > > the team, each sprint.
                                              > > QED: Story points. (Well, the short version of the case.)
                                              > >
                                              > > Don't ask them to agree to do story points. They have no experience, their
                                              > > answer is not meaningful...at least until they have experience. Say, "we're
                                              > > gonna do this new well-established technique." And give it at least 4
                                              > > sprints. You can tell them it's an experiment and if is terrible after 4
                                              > > sprints, we'll change it. (It won't be if anyone is professional around
                                              > > there.)
                                              > >
                                              > > You might need a good coach to have the authority and the detailed
                                              > > experience to make it work better from Day 1. Seems expensive, but it is not
                                              > > compared to the alternative.
                                              > >
                                              > > Regards,
                                              > > Joe
                                              > >
                                              > > LeanAgileTraining.com
                                              > >
                                              > >
                                              > > --- In scrumdevelopment@yahoogroups.com, "Reinert" <rekahm@> wrote:
                                              > > >
                                              > > >
                                              > > >
                                              > > > Hi,
                                              > > >
                                              > > > There are a lot of advantages if you go for using only story points in
                                              > > your estimation of user stories. I.e. abondoning hours / time totally in all
                                              > > your estimates including (developer) tasks. If you are interested in more
                                              > > information, please check out www.rapidscrum.com. The link "AgileIndy
                                              > > Presentation: Hours are Dead" under "RESOURCES" gives you some more
                                              > > information. I've used many of the techniques he is describing and though
                                              > > they are quite unfamiliar, they are very powerful.
                                              > > >
                                              > > > Reinert
                                              > > >
                                              > > > --- In scrumdevelopment@yahoogroups.com, Michael Jones
                                              > > <michaelhardwinjones@> wrote:
                                              > > > >
                                              > > > > Hi,
                                              > > > >
                                              > > > > We're rolling out an agile process in my company, where waterfall
                                              > > processes
                                              > > > > have been used up to now.
                                              > > > >
                                              > > > > I've been involved in a couple of discussions/debates with various folk
                                              > > here
                                              > > > > (a product manager and a fellow PM) about the units developers should
                                              > > use to
                                              > > > > estimate user stories in the sprint planning meeting. Specifically
                                              > > whether
                                              > > > > to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about
                                              > > the
                                              > > > > same as that registration form we did").
                                              > > > >
                                              > > > > I have my own views, but what are your thoughts? Are there any
                                              > > stand-out
                                              > > > > benefits of either in your experience? Should we throw it as an open
                                              > > > > question to our developers?
                                              > > > >
                                              > > > > Thanks,
                                              > > > > Michael
                                              > > > >
                                              > > >
                                              > >
                                              > >
                                              > >
                                              >
                                            • JackM
                                              Typically you estimate size in story points. Each story is weighted against the other stories in the backlog. So if your first story is a 2. Then the next
                                              Message 22 of 25 , Oct 11, 2011
                                              • 0 Attachment
                                                Typically you estimate size in story points. Each story is weighted against the other stories in the backlog. So if your first story is a 2. Then the next story which is twice the size of that one let's say then you'd give that one a 5. Remember there is no 4 as you should use the modified fibonaci sequence 1,2,3,5,8,13,20,40,100. You can also ad 0, 0.5 if u wish.

                                                It's hard to get started though if you have never done this before so I recommend starting wit 1 pt = 1ideal day and then switch later on once you have a baseline. Remember to always compare when assigning points. It's always relative!

                                                Hope this helps
                                                Jack
                                                Www.agilebuddy.com

                                                --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
                                                >
                                                > Hi,
                                                >
                                                > We're rolling out an agile process in my company, where waterfall processes
                                                > have been used up to now.
                                                >
                                                > I've been involved in a couple of discussions/debates with various folk here
                                                > (a product manager and a fellow PM) about the units developers should use to
                                                > estimate user stories in the sprint planning meeting. Specifically whether
                                                > to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about the
                                                > same as that registration form we did").
                                                >
                                                > I have my own views, but what are your thoughts? Are there any stand-out
                                                > benefits of either in your experience? Should we throw it as an open
                                                > question to our developers?
                                                >
                                                > Thanks,
                                                > Michael
                                                >
                                              • RonJeffries
                                                Hi Jack, ... Then why not add 4 for X sake? Is it not obvious that this is the rankest numerology? Ron Jeffries www.XProgramming.com If another does not intend
                                                Message 23 of 25 , Oct 11, 2011
                                                • 0 Attachment
                                                  Hi Jack,

                                                  On Oct 11, 2011, at 10:43 PM, JackM wrote:

                                                  Typically you estimate size in story points. Each story is weighted against the other stories in the backlog. So if your first story is a 2. Then the next story which is twice the size of that one let's say then you'd give that one a 5. Remember there is no 4 as you should use the modified fibonaci sequence 1,2,3,5,8,13,20,40,100. You can also ad 0, 0.5 if u wish. 

                                                  Then why not add 4 for X sake?

                                                  Is it not obvious that this is the rankest numerology?

                                                  Ron Jeffries
                                                  If another does not intend offense, it is wrong for me to seek it;
                                                  if another does indeed intend offense, it is foolish for me to permit it.
                                                    -- Kelly Easterley

                                                • JackM
                                                  As you get larger you need bigger margin for error. You can discern between 1 & 2 less so between a 40 and 41 pointer so that s why fibonnaci works well Jack
                                                  Message 24 of 25 , Oct 11, 2011
                                                  • 0 Attachment
                                                    As you get larger you need bigger margin for error. You can discern between 1 & 2 less so between a 40 and 41 pointer so that's why fibonnaci works well

                                                    Jack
                                                    Www.agilebuddy.com

                                                    --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                                                    >
                                                    > Hi Jack,
                                                    >
                                                    > On Oct 11, 2011, at 10:43 PM, JackM wrote:
                                                    >
                                                    > > Typically you estimate size in story points. Each story is weighted against the other stories in the backlog. So if your first story is a 2. Then the next story which is twice the size of that one let's say then you'd give that one a 5. Remember there is no 4 as you should use the modified fibonaci sequence 1,2,3,5,8,13,20,40,100. You can also ad 0, 0.5 if u wish.
                                                    >
                                                    >
                                                    > Then why not add 4 for X sake?
                                                    >
                                                    > Is it not obvious that this is the rankest numerology?
                                                    >
                                                    > Ron Jeffries
                                                    > www.XProgramming.com
                                                    > If another does not intend offense, it is wrong for me to seek it;
                                                    > if another does indeed intend offense, it is foolish for me to permit it.
                                                    > -- Kelly Easterley
                                                    >
                                                  • Dave Rooney
                                                    Anything beyond 5, or possibly 8, in the faux-Fibonacci series is a WAG dressed up with precision. When given the choice between precision and accuracy, I ll
                                                    Message 25 of 25 , Oct 12, 2011
                                                    • 0 Attachment
                                                      Anything beyond 5, or possibly 8, in the faux-Fibonacci series is a WAG dressed up with precision.  When given the choice between precision and accuracy, I'll take accuracy, thanks.


                                                      Dave Rooney | Agile Coach and Co-founder
                                                      Westboro Systems - Agile Coaching, Training, Organizational Transformation.
                                                      Blog | Twitter | LinkedIn 



                                                      On 2011-10-11, at 11:02 PM, JackM wrote:

                                                       

                                                      As you get larger you need bigger margin for error. You can discern between 1 & 2 less so between a 40 and 41 pointer so that's why fibonnaci works well

                                                      Jack
                                                      Www.agilebuddy.com

                                                      --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
                                                      >
                                                      > Hi Jack,
                                                      >
                                                      > On Oct 11, 2011, at 10:43 PM, JackM wrote:
                                                      >
                                                      > > Typically you estimate size in story points. Each story is weighted against the other stories in the backlog. So if your first story is a 2. Then the next story which is twice the size of that one let's say then you'd give that one a 5. Remember there is no 4 as you should use the modified fibonaci sequence 1,2,3,5,8,13,20,40,100. You can also ad 0, 0.5 if u wish.
                                                      >
                                                      >
                                                      > Then why not add 4 for X sake?
                                                      >
                                                      > Is it not obvious that this is the rankest numerology?
                                                      >
                                                      > Ron Jeffries
                                                      > www.XProgramming.com
                                                      > If another does not intend offense, it is wrong for me to seek it;
                                                      > if another does indeed intend offense, it is foolish for me to permit it.
                                                      > -- Kelly Easterley
                                                      >


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