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

Re: Story point estimating - ideal time vs relative scale

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.