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

RE: [scrumdevelopment] Story Estimation

Expand Messages
  • Jeff Heinen
    I think the best way to demonstrate that you ve thought about something enough is to establish a velocity and deliver stories that you ve committed to. If this
    Message 1 of 14 , Mar 1, 2006
    • 0 Attachment
      I think the best way to demonstrate that you've thought about something
      enough is to establish a velocity and deliver stories that you've
      committed to. If this happens predictably then you have empirical
      evidence that you are thinking through things enough. If, after a few
      sprints, you don't achieve any level of predictability and regular
      success, then you need to think about what you're doing and the team can
      identify changes to improve the situation (retrospectives).

      Have you considered estimating stories using points as opposed to hours?
      One thing I learned in CSM class was that you should estimate size and
      derive duration. People tend to be much better at estimating relative
      size than absolute effort. I know that in my personal experience I can
      usually look at a given story and tell quite quickly if it is bigger or
      smaller than another story, and generally by how much. I can't do the
      same thing with hours.

      -Jeff

      > -----Original Message-----
      > From: scrumdevelopment@yahoogroups.com
      > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of
      > mpkirby@...
      > Sent: Wednesday, March 01, 2006 5:40 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: [scrumdevelopment] Story Estimation
      >
      > We have a situation where one of our managers is concerned
      > that the stories on our burndown are not estimated at a
      > "sufficient level of detail".
      >
      > Specifically, we have stories that range in size from 25
      > hours to around 100 hours. She expects that each story would
      > be broken into a set of tasks ranging from 4 to 10 hours each.
      >
      > Of course, for the current iteration we do precisely that.
      > But for the iteration that is going to occur in june we don't
      > bother until we get closer. She thinks that the estimates
      > are likely to far off, and things that we have unrealistic
      > comittments to the overall release (which ends in july).
      >
      > While I can have the basic "how can you estimate 4 hour tasks
      > 3 months in advance"
      > argument with her, I think her fundamental argument is that
      > breaking down a story into small tasks is a demonstration
      > that you have thought about the problem you are solving.
      >
      > I don't think that's unreasonable. We would, of course,
      > re-estimate/replan at the start of the iteration if it was
      > necessary. But the general rule of "Write a story, think
      > about how you would solve a story, and estimate a story" seem
      > to be reasonable.
      >
      > The more detailed breakdown is how she demonstrates that she
      > "thought about the problem".
      >
      > How do others demonstrate that?
      >
      > Mike
      >
      > ---
      > mpkirby@...
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
    • mpkirby@frontiernet.net
      We have a situation where one of our managers is concerned that the stories on our burndown are not estimated at a sufficient level of detail . Specifically,
      Message 2 of 14 , Mar 1, 2006
      • 0 Attachment
        We have a situation where one of our managers is concerned that the stories on our
        burndown are not estimated at a "sufficient level of detail".

        Specifically, we have stories that range in size from 25 hours to around 100 hours. She
        expects that each story would be broken into a set of tasks ranging from 4 to 10 hours each.

        Of course, for the current iteration we do precisely that. But for the iteration that is going to
        occur in june we don't bother until we get closer. She thinks that the estimates are likely to
        far off, and things that we have unrealistic comittments to the overall release (which ends in
        july).

        While I can have the basic "how can you estimate 4 hour tasks 3 months in advance"
        argument with her, I think her fundamental argument is that breaking down a story into small
        tasks is a demonstration that you have thought about the problem you are solving.

        I don't think that's unreasonable. We would, of course, re-estimate/replan at the start of the
        iteration if it was necessary. But the general rule of "Write a story, think about how you would
        solve a story, and estimate a story" seem to be reasonable.

        The more detailed breakdown is how she demonstrates that she "thought about the
        problem".

        How do others demonstrate that?

        Mike

        ---
        mpkirby@...
      • mpkirby@frontiernet.net
        ... I believe this to be definitely true in our organization. If we demonstrate success, much of the resistance will fade. ... We have considered it.
        Message 3 of 14 , Mar 1, 2006
        • 0 Attachment
          On 1 Mar 2006 at 17:39, Jeff Heinen wrote:

          > I think the best way to demonstrate that you've thought about
          > something enough is to establish a velocity and deliver stories that
          > you've committed to. If this happens predictably then you have
          > empirical evidence that you are thinking through things enough. If,
          > after a few sprints, you don't achieve any level of predictability and
          > regular success, then you need to think about what you're doing and
          > the team can identify changes to improve the situation
          > (retrospectives).

          I believe this to be definitely true in our organization. If we demonstrate success, much of the
          resistance will fade.

          > Have you considered estimating stories using points as opposed to
          > hours? One thing I learned in CSM class was that you should estimate
          > size and derive duration. People tend to be much better at estimating
          > relative size than absolute effort. I know that in my personal
          > experience I can usually look at a given story and tell quite quickly
          > if it is bigger or smaller than another story, and generally by how
          > much. I can't do the same thing with hours.

          We have considered it. Unfortunately, we are a large organization and we report through our
          organization's "planning process" in hours. We could do the estimation in points, as long as
          we ultimately convert to effort.

          Adding to the story a bit, my colleague went through the results from the 1st iteration, and
          evaluated the estimation accuracy of the "story scopings" with that of the detailed
          breakdowns that were done in the iteration planning meeting. As predicted, the detailed
          breakdowns were much more accurate.

          This just re-enforces the arguement of the manager who is "encouraging" us to estimate the
          entire release in small 4-10 hour chunks (which for a 6 month release is quite a task of it's
          own).

          My personal feeling is that the "rough scopings" are too rough. The individuals didn't think
          about the problem in enough detail to know what was involved. Even if they compared it with
          "yesterday's weather", they still have to know enough about what's involved in order to know
          whether it is the same as that story we did last iteration.

          Mike

          ---
          mpkirby@...
        • Steven Gordon
          Mike, What would happen if you quickly estimated how many person hours it would take to task out the entire release, and ask whether applying those hours to
          Message 4 of 14 , Mar 1, 2006
          • 0 Attachment
            Mike,

            What would happen if you quickly estimated how many person hours it would take to task out the entire release, and ask whether applying those hours to delivering working software or to tasking out the entire release would be of more value to the organization (given that what is learned during the next few months would likely change the stories, their priorities, or how they would be tasked out, anyway)?

            Steve

            On 3/1/06, mpkirby@... <mpkirby@... > wrote:


            On 1 Mar 2006 at 17:39, Jeff Heinen wrote:

            > I think the best way to demonstrate that you've thought about
            > something enough is to establish a velocity and deliver stories that
            > you've committed to. If this happens predictably then you have
            > empirical evidence that you are thinking through things enough. If,
            > after a few sprints, you don't achieve any level of predictability and
            > regular success, then you need to think about what you're doing and
            > the team can identify changes to improve the situation
            > (retrospectives).

            I believe this to be definitely true in our organization.  If we demonstrate success, much of the
            resistance will fade.

            > Have you considered estimating stories using points as opposed to
            > hours? One thing I learned in CSM class was that you should estimate
            > size and derive duration. People tend to be much better at estimating
            > relative size than absolute effort. I know that in my personal
            > experience I can usually look at a given story and tell quite quickly
            > if it is bigger or smaller than another story, and generally by how
            > much. I can't do the same thing with hours.

            We have considered it.  Unfortunately, we are a large organization and we report through our
            organization's "planning process" in hours.  We could do the estimation in points, as long as
            we ultimately convert to effort.

            Adding to the story a bit, my colleague went through the results from the 1st iteration, and
            evaluated the estimation accuracy of the "story scopings" with that of the detailed
            breakdowns that were done in the iteration planning meeting.  As predicted, the detailed
            breakdowns were much more accurate.

            This just re-enforces the arguement of the manager who is "encouraging" us to estimate the
            entire release in small 4-10 hour chunks (which for a 6 month release is quite a task of it's
            own).

            My personal feeling is that the "rough scopings" are too rough.  The individuals didn't think
            about the problem in enough detail to know what was involved.  Even if they compared it with
            "yesterday's weather", they still have to know enough about what's involved in order to know
            whether it is the same as that story we did last iteration.

            Mike

            ---
            mpkirby@...


          • Jim Hyslop
            ... Hash: SHA1 ... This is similar to my line of thought: priorities. What is more important: working on and developing a high-priority feature right now, or
            Message 5 of 14 , Mar 2, 2006
            • 0 Attachment
              -----BEGIN PGP SIGNED MESSAGE-----
              Hash: SHA1

              Steven Gordon wrote:
              > Mike,
              >
              > What would happen if you quickly estimated how many person hours it would
              > take to task out the entire release, and ask whether applying those hours to
              > delivering working software or to tasking out the entire release would be of
              > more value to the organization (given that what is learned during the next
              > few months would likely change the stories, their priorities, or how they
              > would be tasked out, anyway)?

              This is similar to my line of thought: priorities. What is more
              important: working on and developing a high-priority feature right now,
              or figuring out in detail how a low-priority item will be done? Which
              one will deliver working software in this sprint?

              The monkey wrench in works, of course, is your requirement for hourly
              reporting. I don't have any suggestions there, I'm afraid.

              - --
              Jim Hyslop
              Dreampossible: Better software. Simply. http://www.dreampossible.ca
              Consulting * Mentoring * Training in
              C/C++ * OOD * SW Development & Practices * Version Management
              -----BEGIN PGP SIGNATURE-----
              Version: GnuPG v1.4.2 (MingW32)
              Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

              iD8DBQFEBvzhLdDyDwyJw+MRAlVAAKDD9egntpDX5Gh053Zj9nhvA6nCZgCcDigV
              jube431hzdEew53BSS9C1h4=
              =RXZm
              -----END PGP SIGNATURE-----
            • John Streiff
              I have been thinking a bit about this, reflecting on other related principles stated elsewhere. One that stands out is actually avoiding concrete planning when
              Message 6 of 14 , Mar 2, 2006
              • 0 Attachment
                I have been thinking a bit about this, reflecting on other related
                principles stated elsewhere. One that stands out is actually avoiding
                concrete planning when things are too indeterminate. Rather you plan to
                plan, on the theory that you yet don't know enough to create a concrete
                case. This might be an option here.

                The manager who is concerned that plans should have a specific shape is
                essentially saying 'I know what is best, I'm not seeing it happen and
                I'm concerned'. At least that's what comes across in this medium. If
                this is a fair assessment of the manager's state-of-mind, what is her
                real concern? I'm reasonably sure there's more to this than numbers.

                I would recommend using your hours initially for planning, refactor that
                time as you know more and demonstrate to the manager that there are no
                'magic numbers' in this process. While it is likely true that many do in
                fact plan in consistent time increments, everyone is always trading
                functionality for the schedule.

                Management must understand that plans can and must change for the team
                to remain healthy and capable of delivering. This causes managers to
                stress as they find themselves in often unfamiliar waters with delivery
                responsibilities in legacy corporations whose practices have not changed
                for decades.

                Best of luck - keep us informed on your progress!

                John Streiff

                -----Original Message-----

                Jim Hyslop wrote:

                This is similar to my line of thought: priorities. What is more
                important: working on and developing a high-priority feature right now,
                or figuring out in detail how a low-priority item will be done? Which
                one will deliver working software in this sprint?

                The monkey wrench in works, of course, is your requirement for hourly
                reporting. I don't have any suggestions there, I'm afraid.

                Jim Hyslop
              • Jeff Heinen
                Effort is simple: Hours per story point = (number of team members * 40 * duration of sprint in weeks) / velocity That should suffice for communicating upward,
                Message 7 of 14 , Mar 2, 2006
                • 0 Attachment
                  Effort is simple:

                  Hours per story point = (number of team members * 40 * duration
                  of sprint in weeks) / velocity

                  That should suffice for communicating upward, but keep in mind that at a
                  team level you would never want to equate story points with hours.



                  > -----Original Message-----
                  > From: scrumdevelopment@yahoogroups.com
                  > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of
                  > mpkirby@...
                  > Sent: Wednesday, March 01, 2006 6:08 PM
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: RE: [scrumdevelopment] Story Estimation
                  >
                  >
                  >
                  > On 1 Mar 2006 at 17:39, Jeff Heinen wrote:
                  >
                  > > I think the best way to demonstrate that you've thought about
                  > > something enough is to establish a velocity and deliver
                  > stories that
                  > > you've committed to. If this happens predictably then you have
                  > > empirical evidence that you are thinking through things enough. If,
                  > > after a few sprints, you don't achieve any level of
                  > predictability and
                  > > regular success, then you need to think about what you're doing and
                  > > the team can identify changes to improve the situation
                  > > (retrospectives).
                  >
                  > I believe this to be definitely true in our organization. If
                  > we demonstrate success, much of the resistance will fade.
                  >
                  > > Have you considered estimating stories using points as opposed to
                  > > hours? One thing I learned in CSM class was that you should
                  > estimate
                  > > size and derive duration. People tend to be much better at
                  > estimating
                  > > relative size than absolute effort. I know that in my personal
                  > > experience I can usually look at a given story and tell
                  > quite quickly
                  > > if it is bigger or smaller than another story, and generally by how
                  > > much. I can't do the same thing with hours.
                  >
                  > We have considered it. Unfortunately, we are a large
                  > organization and we report through our organization's
                  > "planning process" in hours. We could do the estimation in
                  > points, as long as we ultimately convert to effort.
                  >
                  > Adding to the story a bit, my colleague went through the
                  > results from the 1st iteration, and evaluated the estimation
                  > accuracy of the "story scopings" with that of the detailed
                  > breakdowns that were done in the iteration planning meeting.
                  > As predicted, the detailed breakdowns were much more accurate.
                  >
                  > This just re-enforces the arguement of the manager who is
                  > "encouraging" us to estimate the entire release in small 4-10
                  > hour chunks (which for a 6 month release is quite a task of it's own).
                  >
                  > My personal feeling is that the "rough scopings" are too
                  > rough. The individuals didn't think about the problem in
                  > enough detail to know what was involved. Even if they
                  > compared it with "yesterday's weather", they still have to
                  > know enough about what's involved in order to know whether it
                  > is the same as that story we did last iteration.
                  >
                  > Mike
                  >
                  > ---
                  > mpkirby@...
                  >
                  >
                  >
                  > To Post a message, send it to: scrumdevelopment@...
                  > To Unsubscribe, send a blank message to:
                  > scrumdevelopment-unsubscribe@...
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                • Steven Gordon
                  And then round to the nearest 100 to avoid implying unintended precision.
                  Message 8 of 14 , Mar 2, 2006
                  • 0 Attachment
                    And then round to the nearest 100 to avoid implying unintended precision.

                    On 3/2/06, Jeff Heinen <jheinen@...> wrote:
                    Effort is simple:

                           Hours per story point = (number of team members * 40 * duration
                    of sprint in weeks) / velocity

                    That should suffice for communicating upward, but keep in mind that at a
                    team level you would never want to equate story points with hours.



                    > -----Original Message-----
                    > From: scrumdevelopment@yahoogroups.com
                    > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of
                    > mpkirby@...
                    > Sent: Wednesday, March 01, 2006 6:08 PM
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: RE: [scrumdevelopment] Story Estimation
                    >
                    >
                  • Mike Cohn
                    Yes, Jeff--that s a key point. A lot of teams want to equate story points to hours and come up with something like 1 story point = 6.2 hours . The fallacy
                    Message 9 of 14 , Mar 2, 2006
                    • 0 Attachment
                      Yes, Jeff--that's a key point. A lot of teams want to equate story
                      points to hours and come up with something like "1 story point = 6.2
                      hours". The fallacy there is that (in this example) the truth is more
                      that "the mean number of hours per story point is 6.2 with a standard
                      deviation of 3.6". In other words, the relationship is between a
                      story point and a distribution of hours.

                      Regards,
                      Mike Cohn
                      Author:
                      Agile Estimating and Planning
                      User Stories Applied
                      www.mountaingoatsoftware.com


                      On Mar 2, 2006, at 4:09 PM, Jeff Heinen wrote:

                      > Effort is simple:
                      >
                      > Hours per story point = (number of team members * 40 * duration
                      > of sprint in weeks) / velocity
                      >
                      > That should suffice for communicating upward, but keep in mind that
                      > at a
                      > team level you would never want to equate story points with hours.
                      >
                      >
                      >
                      >> -----Original Message-----
                      >> From: scrumdevelopment@yahoogroups.com
                      >> [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of
                      >> mpkirby@...
                      >> Sent: Wednesday, March 01, 2006 6:08 PM
                      >> To: scrumdevelopment@yahoogroups.com
                      >> Subject: RE: [scrumdevelopment] Story Estimation
                      >>
                      >>
                      >>
                      >> On 1 Mar 2006 at 17:39, Jeff Heinen wrote:
                      >>
                      >>> I think the best way to demonstrate that you've thought about
                      >>> something enough is to establish a velocity and deliver
                      >> stories that
                      >>> you've committed to. If this happens predictably then you have
                      >>> empirical evidence that you are thinking through things enough. If,
                      >>> after a few sprints, you don't achieve any level of
                      >> predictability and
                      >>> regular success, then you need to think about what you're doing and
                      >>> the team can identify changes to improve the situation
                      >>> (retrospectives).
                      >>
                      >> I believe this to be definitely true in our organization. If
                      >> we demonstrate success, much of the resistance will fade.
                      >>
                      >>> Have you considered estimating stories using points as opposed to
                      >>> hours? One thing I learned in CSM class was that you should
                      >> estimate
                      >>> size and derive duration. People tend to be much better at
                      >> estimating
                      >>> relative size than absolute effort. I know that in my personal
                      >>> experience I can usually look at a given story and tell
                      >> quite quickly
                      >>> if it is bigger or smaller than another story, and generally by how
                      >>> much. I can't do the same thing with hours.
                      >>
                      >> We have considered it. Unfortunately, we are a large
                      >> organization and we report through our organization's
                      >> "planning process" in hours. We could do the estimation in
                      >> points, as long as we ultimately convert to effort.
                      >>
                      >> Adding to the story a bit, my colleague went through the
                      >> results from the 1st iteration, and evaluated the estimation
                      >> accuracy of the "story scopings" with that of the detailed
                      >> breakdowns that were done in the iteration planning meeting.
                      >> As predicted, the detailed breakdowns were much more accurate.
                      >>
                      >> This just re-enforces the arguement of the manager who is
                      >> "encouraging" us to estimate the entire release in small 4-10
                      >> hour chunks (which for a 6 month release is quite a task of it's
                      >> own).
                      >>
                      >> My personal feeling is that the "rough scopings" are too
                      >> rough. The individuals didn't think about the problem in
                      >> enough detail to know what was involved. Even if they
                      >> compared it with "yesterday's weather", they still have to
                      >> know enough about what's involved in order to know whether it
                      >> is the same as that story we did last iteration.
                      >>
                      >> Mike
                      >>
                      >> ---
                      >> mpkirby@...
                      >>
                      >>
                      >>
                      >> To Post a message, send it to: scrumdevelopment@...
                      >> To Unsubscribe, send a blank message to:
                      >> scrumdevelopment-unsubscribe@...
                      >> Yahoo! Groups Links
                      >>
                      >>
                      >>
                      >>
                      >>
                      >>
                      >>
                      >>
                      >
                      >
                      > To Post a message, send it to: scrumdevelopment@...
                      > To Unsubscribe, send a blank message to: scrumdevelopment-
                      > unsubscribe@...
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                      >
                    • mpkirby@frontiernet.net
                      ... I never really understood the distinction between story points and hours. It s seems like a level of indirection that isn t really necessary. And even if
                      Message 10 of 14 , Mar 3, 2006
                      • 0 Attachment
                        On 2 Mar 2006 at 19:15, Mike Cohn wrote:

                        > Yes, Jeff--that's a key point. A lot of teams want to equate story 
                        > points to hours and come up with something like "1 story point = 6.2 
                        > hours". The fallacy there is that (in this example) the truth is more 
                        > that "the mean number of hours per story point is 6.2 with a standard 
                        > deviation of 3.6".  In other words, the relationship is between a 
                        > story point and a distribution of hours.

                        I never really understood the distinction between story points and hours. It's seems like a
                        level of indirection that isn't really necessary.

                        And even if I estimate in story points, it still has to be converted and displayed (to both the
                        team, and upper management) in effort.

                        Team members would still report remaining time in terms of effort, yes? Management still
                        wants to see hours remaining, hours complete, hours of growth.

                        Has someone out there done both, and have a good sense for the differences?

                        Thanks,
                        Mike

                        ---
                        mpkirby@...
                      • Ron Jeffries
                        ... On the contrary: it is a part of a conversion of attention from something unimportant to something important. ... It s better if the team and management
                        Message 11 of 14 , Mar 3, 2006
                        • 0 Attachment
                          On Friday, March 3, 2006, at 4:01:29 AM, mpkirby@... wrote:

                          > I never really understood the distinction between story points and
                          > hours. It's seems like a level of indirection that isn't really
                          > necessary.

                          On the contrary: it is a part of a conversion of attention from
                          something unimportant to something important.

                          > And even if I estimate in story points, it still has to be
                          > converted and displayed (to both the team, and upper management)
                          > in effort.

                          It's better if the team and management think in terms of value, not
                          effort. A Scrum burn chart isn't about effort, it's about
                          completion.

                          > Team members would still report remaining time in terms of effort,
                          > yes? Management still wants to see hours remaining, hours
                          > complete, hours of growth.

                          Management needs to turn their attention to things that matter, like
                          amount of value completed, amount shipped, the relationship between
                          features and time, early attention to low-hanging fruit -- valuable
                          features that can be done quickly.

                          Hours distracts from this, because it looks like something they
                          ought to monitor and control.

                          > Has someone out there done both, and have a good sense for the differences?

                          Yep. That's where the above comes from.

                          Ron Jeffries
                          www.XProgramming.com
                          If you want to garden, you have to bend down and touch the soil.
                          Gardening is a practice, not an idea.
                          -- Thich Nhat Hanh
                        • Mike Cohn
                          Hi Mike-- ... I definitely coach teams to estimate the sprint backlog in hours and the product backlog in something different, I prefer story points. Here s
                          Message 12 of 14 , Mar 5, 2006
                          • 0 Attachment
                            Hi Mike--

                            >
                            > I never really understood the distinction between story points and
                            > hours. It's seems like a
                            > level of indirection that isn't really necessary.
                            >
                            > Thanks,
                            > Mike
                            >
                            > ---
                            > mpkirby@...
                            >

                            I definitely coach teams to estimate the sprint backlog in hours and
                            the product backlog in something different, I prefer story points.
                            Here's the key difference. Some teams think they can estimate items
                            on both backlogs in hours but the units are actually different.
                            Sprint backlog items get a lot more thought so the units are really
                            "hours-I-thought-alot-about" whereas product backlog items are
                            estimated in "hours-I-pulled-out-of-the-air." These are quite
                            different units. I find that on average (across the teams I work
                            with) that teams spend around 20 minutes decomposing a product
                            backlog item into sprint backlog items and estimating each. These are
                            the "hours-I-thought-alot-about." On the other hand, they spend an
                            average of 3 minutes per product backlog item estimate (some longer
                            but many less). These are the "hours-I-pulled-out-of-the-air." The
                            problem arises when someone sums the product backlog estimates, let's
                            say to 1000 hours (which are really "hours-I-pulled-out-of-the-air").
                            They then look at the last sprint and see that the team completed 250
                            hours (which are really "hours-I-thought-alot-about"). They then
                            want to do 1000 / 250 = 4 sprints left. However, since this is dividing:

                            1000 "hours-I-pulled-out-of-the-air."
                            ------------------------------------------------
                            250 "hours-I-thought-alot-about."

                            The math doesn't work. It's quite literally dividing apples by
                            oranges. Almost every team that does this will find their project
                            taking longer than this math would indicate because it seems human
                            nature to underestimate large items (the product backlog items).

                            Using a term like "story points" makes it clear that we cannot do
                            this division. To determine the number of expected remaining sprints
                            you need to know the number of story points remaining and the number
                            of story points completed on average per sprint. Separating points
                            and hours allows the fact that a point translates to a range of hours
                            to come through in the calculation.

                            Regards,
                            Mike Cohn
                            Author:
                            Agile Estimating and Planning
                            User Stories Applied
                            www.mountaingoatsoftware.com
                          • Dymond, Robin
                            See Below. ... From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of mpkirby@frontiernet.net Sent: Wednesday, March 01,
                            Message 13 of 14 , Mar 6, 2006
                            • 0 Attachment
                              See Below.

                              -----Original Message-----
                              From: scrumdevelopment@yahoogroups.com
                              [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of
                              mpkirby@...
                              Sent: Wednesday, March 01, 2006 8:40 PM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: [scrumdevelopment] Story Estimation


                              <snip>
                              While I can have the basic "how can you estimate 4 hour tasks 3 months
                              in advance"
                              argument with her, I think her fundamental argument is that breaking
                              down a story into small
                              tasks is a demonstration that you have thought about the problem you are
                              solving.

                              I don't think that's unreasonable. We would, of course,
                              re-estimate/replan at the start of the
                              iteration if it was necessary. But the general rule of "Write a story,
                              think about how you would
                              solve a story, and estimate a story" seem to be reasonable.
                              </snip>

                              Actually, it is unreasonable to ask for this. It is unreasonable because
                              it is asking for upfront requirements analysis. The reality is it
                              dubious to spend much time figuring this out. It will inevitably change
                              as the team learns through the course of the project. The amount of time
                              spent "figuring out" better estimates is waste. It is much better for
                              the team, the business, and the project to instead figure out how to get
                              to the first release as early as possible in the project.

                              Cheers,

                              Robin Dymond



                              The information contained in this e-mail is confidential and/or proprietary
                              to Capital One and/or its affiliates. The information transmitted herewith
                              is intended only for use by the individual or entity to which it is
                              addressed. If the reader of this message is not the intended recipient,
                              you are hereby notified that any review, retransmission, dissemination,
                              distribution, copying or other use of, or taking of any action in reliance
                              upon this information is strictly prohibited. If you have received this
                              communication in error, please contact the sender and delete the material
                              from your computer.
                            • kane_sfo
                              ... individuals didn t think ... if they compared it with ... involved in order to know ... In all likelihood, the individuals are giving you the best possible
                              Message 14 of 14 , Mar 20, 2006
                              • 0 Attachment
                                --- In scrumdevelopment@yahoogroups.com, mpkirby@... wrote:
                                >
                                > My personal feeling is that the "rough scopings" are too rough. The
                                individuals didn't think
                                > about the problem in enough detail to know what was involved. Even
                                if they compared it with
                                > "yesterday's weather", they still have to know enough about what's
                                involved in order to know
                                > whether it is the same as that story we did last iteration.

                                In all likelihood, the individuals are giving you the best possible
                                estimates they are able. The complexity of software makes it
                                impossible for an individual to understand every behaviour let alone
                                sequence of behaviours.

                                I would suggest that seeking this level of accuracy is futile and, as
                                the other contributors to thread have suggested, you may have more
                                success by abstracting to a higher level (ie Story points).

                                Best regards,
                                Kane.
                              Your message has been successfully submitted and would be delivered to recipients shortly.