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
      ... 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.