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

RE: [scrumdevelopment] Story Estimation

Expand Messages
  • 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 1 of 14 , Mar 1, 2006
      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 2 of 14 , Mar 1, 2006
        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 3 of 14 , Mar 2, 2006
          -----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 4 of 14 , Mar 2, 2006
            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 5 of 14 , Mar 2, 2006
              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 6 of 14 , Mar 2, 2006
                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 7 of 14 , Mar 2, 2006
                  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 8 of 14 , Mar 3, 2006
                    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 9 of 14 , Mar 3, 2006
                      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 10 of 14 , Mar 5, 2006
                        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 11 of 14 , Mar 6, 2006
                          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 12 of 14 , Mar 20, 2006
                            --- 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.