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

Combining Estimates: Bootstapping a Dev, QA, Doc team

Expand Messages
  • ijafw
    All: I have inherited a team that is new to scrum and am leading them in the planning efforts. Since they re new to the scrum, they have no sense of how to
    Message 1 of 8 , Dec 9, 2008
    • 0 Attachment
      All:

      I have inherited a team that is new to scrum and am leading them in
      the planning efforts. Since they're new to the scrum, they have no
      sense of how to make a single story point estimate given the
      development, testing and doc efforts that will make a story
      successful. That will come with experience.

      But to get them started, any thoughts on how to boot-strap? Should
      each of the three efforts make estimates from their points of view,
      and the combine (additively?)? I assume that in the future, we'd do
      relative estimates (it was X last time, so it must be X this time...),
      not any per-discipline additive estimates.

      Thoughts welcome.

      Steveo
    • Richard Lawrence
      Provided you can wait two or three sprints to be able to estimate a release, you can start out doing relative estimating. The team can look at the backlog and
      Message 2 of 8 , Dec 9, 2008
      • 0 Attachment
        Provided you can wait two or three sprints to be able to estimate a
        release, you can start out doing relative estimating. The team can
        look at the backlog and find something that they can agree is fairly
        small, but not the smallest item on the backlog. Call that a 2.
        Estimate enough stories to likely get you through a few sprints. Then,
        have the team add stories one at a time to the first sprint plan until
        they feel like they have enough to fill their capacity. They'll likely
        be wrong and have to add or remove work. Working on one story at a
        time makes this adjustment less painful. For sprint 2, use the
        velocity established in sprint 1. Repeat from there. By sprint 3,
        velocity will be starting to stabilize and reasonably accurate release
        planning will be possible.

        Richard
        --
        Richard Lawrence
        Certified Scrum Coach
        Founder and Principal Consultant, Humanizing Work, LLC
        303-895-7688
        richard@...
        www.humanizingwork.com
        www.richardlawrence.info

        On Tue, Dec 9, 2008 at 11:11 AM, ijafw <stephencanthony@...> wrote:
        > All:
        >
        > I have inherited a team that is new to scrum and am leading them in
        > the planning efforts. Since they're new to the scrum, they have no
        > sense of how to make a single story point estimate given the
        > development, testing and doc efforts that will make a story
        > successful. That will come with experience.
        >
        > But to get them started, any thoughts on how to boot-strap? Should
        > each of the three efforts make estimates from their points of view,
        > and the combine (additively?)? I assume that in the future, we'd do
        > relative estimates (it was X last time, so it must be X this time...),
        > not any per-discipline additive estimates.
        >
        > Thoughts welcome.
        >
        > Steveo
        >
        >
      • Doug McQuilken
        Steve,   Alternatively, use a capacity-based model. Estimate in story points. Perform task breakdown. Estimate effort hours per task. Deduct from available
        Message 3 of 8 , Dec 9, 2008
        • 0 Attachment
          Steve,
           
          Alternatively, use a capacity-based model.
          Estimate in story points.
          Perform task breakdown.
          Estimate effort hours per task.
          Deduct from available capacity (of available hours)
          After the three sprints - you will have a velocity to use going forward.
           
          Regards,
          Doug

          --- On Tue, 12/9/08, Richard Lawrence <rslawrence@...> wrote:
          From: Richard Lawrence <rslawrence@...>
          Subject: Re: [scrumdevelopment] Combining Estimates: Bootstapping a Dev, QA, Doc team
          To: scrumdevelopment@yahoogroups.com
          Date: Tuesday, December 9, 2008, 1:40 PM

          Provided you can wait two or three sprints to be able to estimate a
          release, you can start out doing relative estimating. The team can
          look at the backlog and find something that they can agree is fairly
          small, but not the smallest item on the backlog. Call that a 2.
          Estimate enough stories to likely get you through a few sprints. Then,
          have the team add stories one at a time to the first sprint plan until
          they feel like they have enough to fill their capacity. They'll likely
          be wrong and have to add or remove work. Working on one story at a
          time makes this adjustment less painful. For sprint 2, use the
          velocity established in sprint 1. Repeat from there. By sprint 3,
          velocity will be starting to stabilize and reasonably accurate release
          planning will be possible.

          Richard
          --
          Richard Lawrence
          Certified Scrum Coach
          Founder and Principal Consultant, Humanizing Work, LLC
          303-895-7688
          richard@humanizingw ork.com
          www.humanizingwork. com
          www.richardlawrence .info

          On Tue, Dec 9, 2008 at 11:11 AM, ijafw <stephencanthony@ gmail.com> wrote:
          > All:
          >
          > I have inherited a team that is new to scrum and am leading them in
          > the planning efforts. Since they're new to the scrum, they have no
          > sense of how to make a single story point estimate given the
          > development, testing and doc efforts that will make a story
          > successful. That will come with experience.
          >
          > But to get them started, any thoughts on how to boot-strap? Should
          > each of the three efforts make estimates from their points of view,
          > and the combine (additively? )? I assume that in the future, we'd do
          > relative estimates (it was X last time, so it must be X this time...),
          > not any per-discipline additive estimates.
          >
          > Thoughts welcome.
          >
          > Steveo
          >
          >
        • mike.dwyer1@comcast.net
          Or buy Mike Cohn s Book Go to his website or (gasp) take a scrumaster course Listening to this stuff will get you in some deep doo doo Sent via BlackBerry by
          Message 4 of 8 , Dec 9, 2008
          • 0 Attachment
            Or buy Mike Cohn's Book
            Go to his website or (gasp) take a scrumaster course
            Listening to this stuff will get you in some deep doo doo

            Sent via BlackBerry by AT&T


            From: Doug McQuilken
            Date: Tue, 9 Dec 2008 11:37:43 -0800 (PST)
            To: <scrumdevelopment@yahoogroups.com>
            Subject: Re: [scrumdevelopment] Combining Estimates: Bootstapping a Dev, QA, Doc team

            Steve,
             
            Alternatively, use a capacity-based model.
            Estimate in story points.
            Perform task breakdown.
            Estimate effort hours per task.
            Deduct from available capacity (of available hours)
            After the three sprints - you will have a velocity to use going forward.
             
            Regards,
            Doug

            --- On Tue, 12/9/08, Richard Lawrence <rslawrence@gmail. com> wrote:
            From: Richard Lawrence <rslawrence@gmail. com>
            Subject: Re: [scrumdevelopment] Combining Estimates: Bootstapping a Dev, QA, Doc team
            To: scrumdevelopment@ yahoogroups. com
            Date: Tuesday, December 9, 2008, 1:40 PM

            Provided you can wait two or three sprints to be able to estimate a
            release, you can start out doing relative estimating. The team can
            look at the backlog and find something that they can agree is fairly
            small, but not the smallest item on the backlog. Call that a 2.
            Estimate enough stories to likely get you through a few sprints. Then,
            have the team add stories one at a time to the first sprint plan until
            they feel like they have enough to fill their capacity. They'll likely
            be wrong and have to add or remove work. Working on one story at a
            time makes this adjustment less painful. For sprint 2, use the
            velocity established in sprint 1. Repeat from there. By sprint 3,
            velocity will be starting to stabilize and reasonably accurate release
            planning will be possible.

            Richard
            --
            Richard Lawrence
            Certified Scrum Coach
            Founder and Principal Consultant, Humanizing Work, LLC
            303-895-7688
            richard@humanizingw ork.com
            www.humanizingwork. com
            www.richardlawrence .info

            On Tue, Dec 9, 2008 at 11:11 AM, ijafw <stephencanthony@ gmail.com> wrote:
            > All:
            >
            > I have inherited a team that is new to scrum and am leading them in
            > the planning efforts. Since they're new to the scrum, they have no
            > sense of how to make a single story point estimate given the
            > development, testing and doc efforts that will make a story
            > successful. That will come with experience.
            >
            > But to get them started, any thoughts on how to boot-strap? Should
            > each of the three efforts make estimates from their points of view,
            > and the combine (additively? )? I assume that in the future, we'd do
            > relative estimates (it was X last time, so it must be X this time...),
            > not any per-discipline additive estimates.
            >
            > Thoughts welcome.
            >
            > Steveo
            >
            >

          • Ron Jeffries
            Hello, ijafw. On Tuesday, December 9, 2008, at 1:11:42 PM, you ... Why are the efforts themselves being split? Ron Jeffries www.XProgramming.com
            Message 5 of 8 , Dec 9, 2008
            • 0 Attachment
              Hello, ijafw. On Tuesday, December 9, 2008, at 1:11:42 PM, you
              wrote:

              > I have inherited a team that is new to scrum and am leading them in
              > the planning efforts. Since they're new to the scrum, they have no
              > sense of how to make a single story point estimate given the
              > development, testing and doc efforts that will make a story
              > successful. That will come with experience.

              > But to get them started, any thoughts on how to boot-strap? Should
              > each of the three efforts make estimates from their points of view,
              > and the combine (additively?)? I assume that in the future, we'd do
              > relative estimates (it was X last time, so it must be X this time...),
              > not any per-discipline additive estimates.

              Why are the efforts themselves being split?

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              The truth ain't like puppies, a bunch of 'em runnin' around
              and you pick your favorite. --Emerson Codd
            • Adam Sroka
              ... What about *starting* with relative estimates. i.e. you assign an amount of points to what looks like an average sized story and estimate the rest
              Message 6 of 8 , Dec 9, 2008
              • 0 Attachment
                On Tue, Dec 9, 2008 at 10:11 AM, ijafw <stephencanthony@...> wrote:
                > All:
                >
                > I have inherited a team that is new to scrum and am leading them in
                > the planning efforts. Since they're new to the scrum, they have no
                > sense of how to make a single story point estimate given the
                > development, testing and doc efforts that will make a story
                > successful. That will come with experience.
                >
                > But to get them started, any thoughts on how to boot-strap? Should
                > each of the three efforts make estimates from their points of view,
                > and the combine (additively?)? I assume that in the future, we'd do
                > relative estimates (it was X last time, so it must be X this time...),
                > not any per-discipline additive estimates.
                >
                > Thoughts welcome.

                What about *starting* with relative estimates. i.e. you assign an
                amount of points to what looks like an "average" sized story and
                estimate the rest relative to that. You will have no clue what your
                velocity is until you have done this a few times and gained some
                consistency, but then that is the reality isn't it? Part of the idea
                of Agile estimation is that you are honest with yourself and your team
                (including the PO and customer.) The honest answer is that you have no
                idea what your team can do until you've worked together for a while.

                BTW, this is exactly what Mike Cohn recommends in his book (And his
                class, which I have taken.)
              • Roy Morien
                Interesting comments, and quite correct and relevant. I had the experience recently of trying to teach about Story Points. The students were totally
                Message 7 of 8 , Dec 9, 2008
                • 0 Attachment
                  Interesting comments, and quite correct and relevant.
                   
                  I had the experience recently of trying to teach about Story Points. The students were totally bamboozled. "How can we know how many Story Points to give?".   But they were quite happy to guess 30 hours, and 15 hours for the same User Story. (I told them I could do it in 2 hours ... because I had (1) 30 years experience versus their 30 months, (2) I had well understood standards in place, and reuseable code available, they didn't, (3) I was quite competent at the development environment, they weren't. All of these and more are what makes 3rd Party estimating in hours a nonsense. (4) I had done something similar many times before.
                   
                  But it was interesting that they were immediately happy to make a time guess

                  Regards,
                  Roy Morien


                  To: scrumdevelopment@yahoogroups.com
                  From: rslawrence@...
                  Date: Tue, 9 Dec 2008 11:40:45 -0700
                  Subject: Re: [scrumdevelopment] Combining Estimates: Bootstapping a Dev, QA, Doc team


                  Provided you can wait two or three sprints to be able to estimate a
                  release, you can start out doing relative estimating. The team can
                  look at the backlog and find something that they can agree is fairly
                  small, but not the smallest item on the backlog. Call that a 2.
                  Estimate enough stories to likely get you through a few sprints. Then,
                  have the team add stories one at a time to the first sprint plan until
                  they feel like they have enough to fill their capacity. They'll likely
                  be wrong and have to add or remove work. Working on one story at a
                  time makes this adjustment less painful. For sprint 2, use the
                  velocity established in sprint 1. Repeat from there. By sprint 3,
                  velocity will be starting to stabilize and reasonably accurate release
                  planning will be possible.

                  Richard
                  --
                  Richard Lawrence
                  Certified Scrum Coach
                  Founder and Principal Consultant, Humanizing Work, LLC
                  303-895-7688
                  richard@humanizingw ork.com
                  www.humanizingwork. com
                  www.richardlawrence .info

                  On Tue, Dec 9, 2008 at 11:11 AM, ijafw <stephencanthony@ gmail.com> wrote:
                  > All:
                  >
                  > I have inherited a team that is new to scrum and am leading them in
                  > the planning efforts. Since they're new to the scrum, they have no
                  > sense of how to make a single story point estimate given the
                  > development, testing and doc efforts that will make a story
                  > successful. That will come with experience.
                  >
                  > But to get them started, any thoughts on how to boot-strap? Should
                  > each of the three efforts make estimates from their points of view,
                  > and the combine (additively? )? I assume that in the future, we'd do
                  > relative estimates (it was X last time, so it must be X this time...),
                  > not any per-discipline additive estimates.
                  >
                  > Thoughts welcome.
                  >
                  > Steveo
                  >
                  >



                  Download free emoticons today! Holiday cheer from Messenger.
                • Paul Oldfield
                  (responding to Richard, Steveo) ... +1 except I advise starting with a medium size and calling it an 8 (I favour Fibonacci series). Get the whole team together
                  Message 8 of 8 , Dec 10, 2008
                  • 0 Attachment
                    (responding to Richard, Steveo)

                    > Provided you can wait two or three sprints to be able to estimate a
                    > release, you can start out doing relative estimating. The team can
                    > look at the backlog and find something that they can agree is fairly
                    > small, but not the smallest item on the backlog. Call that a 2.
                    > Estimate enough stories to likely get you through a few sprints. Then,
                    > have the team add stories one at a time to the first sprint plan until
                    > they feel like they have enough to fill their capacity. They'll likely
                    > be wrong and have to add or remove work. Working on one story at a
                    > time makes this adjustment less painful. For sprint 2, use the
                    > velocity established in sprint 1. Repeat from there. By sprint 3,
                    > velocity will be starting to stabilize and reasonably accurate release
                    > planning will be possible.

                    +1 except I advise starting with a medium size and calling it
                    an 8 (I favour Fibonacci series).

                    Get the whole team together to estimate relative sizes. Some
                    interesting conversations happen when there's disagreement
                    on relative size; as long as these are short, they are good
                    learning experience; Dev learns what Test finds hard and v/v;
                    this is a small step toward having more flexible teams.

                    The object of the estimation is to put stories of similar
                    size into 'bins' where they all have the same number of
                    story points. We don't need to know, yet, how long it will
                    take the team to complete one of these stories, but it does
                    help if the stories we put in the '3' bin take on average
                    3/8 of the time, more or less, of those we put in the '8'
                    bin. We're looking for approximate relative size.

                    Paul Oldfield
                    Capgemini
                  Your message has been successfully submitted and would be delivered to recipients shortly.