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

Re: [scrumdevelopment] Story Estimation

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