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

Re: [scrumdevelopment] Story Estimation

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