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

Planning a product release

Expand Messages
  • Dan Brown
    I could use some advice from the group. Our group adapted Scrum about 5 months ago in the middle of a project that was failing. We since extended this to a
    Message 1 of 13 , Apr 11, 2003
    • 0 Attachment
      I could use some advice from the group.

      Our group adapted Scrum about 5 months ago in the middle of a project
      that was failing. We since extended this to a couple other projects
      that were failing and it has worked wonders and I have grown in
      experience leading some of these projects. What no one on our team
      has any experience with is STARTING a product release with Scrum.

      I read a recommendation several (hundred?) messages ago that
      advocated something like a planning sprint to bring teams into
      Scrum. Our team is already bought into Scrum, and would like to
      evolve our design during many sprints with several Scrum teams
      working in parallel after which we will deliver our product.
      However, we are having a hard time telling management that we will be
      able to deliver a product with XY&Z in it on date D, without first
      doing enough of a design analysis on the feature list to feel like we
      really understand the complexities to give a solid estimate. In our
      industry, estimates are required because our business & our customers
      need some planning to bring together many elements, of which the
      software we will deliver is just one.

      I'm sure Scrum must be used places where these types of pre-project
      estimates must be given and contracted upon. What is done in this
      case? Is decomposing the user stories into what we feel are month-
      long product backlog bits in a planning sprint sufficient and
      recommended? Somehow I have a sinking feeling (clinging to my false
      sense of security in waterfall) that this may just get me fired.

      Thanks so very much for any advice,

      Dan
    • gilmanj_2000
      This is something I am interested in too. I understand how Scrum works to maximize project velocity and still provide flexibility between sprints to deal with
      Message 2 of 13 , Apr 13, 2003
      • 0 Attachment
        This is something I am interested in too.

        I understand how Scrum works to maximize project velocity and still
        provide flexibility between sprints to deal with uncertainty and
        changing priorities. Does Scrum help me say anything about
        projected release dates?

        John Gilman

        --- In scrumdevelopment@yahoogroups.com, "Dan Brown"
        <kid_danomite@y...> wrote:
        > I could use some advice from the group.
        >
        > Our group adapted Scrum about 5 months ago in the middle of a
        project
        > that was failing. We since extended this to a couple other
        projects
        > that were failing and it has worked wonders and I have grown in
        > experience leading some of these projects. What no one on our
        team
        > has any experience with is STARTING a product release with Scrum.
        >
        > I read a recommendation several (hundred?) messages ago that
        > advocated something like a planning sprint to bring teams into
        > Scrum. Our team is already bought into Scrum, and would like to
        > evolve our design during many sprints with several Scrum teams
        > working in parallel after which we will deliver our product.
        > However, we are having a hard time telling management that we will
        be
        > able to deliver a product with XY&Z in it on date D, without first
        > doing enough of a design analysis on the feature list to feel like
        we
        > really understand the complexities to give a solid estimate. In
        our
        > industry, estimates are required because our business & our
        customers
        > need some planning to bring together many elements, of which the
        > software we will deliver is just one.
        >
        > I'm sure Scrum must be used places where these types of pre-
        project
        > estimates must be given and contracted upon. What is done in this
        > case? Is decomposing the user stories into what we feel are month-
        > long product backlog bits in a planning sprint sufficient and
        > recommended? Somehow I have a sinking feeling (clinging to my
        false
        > sense of security in waterfall) that this may just get me fired.
        >
        > Thanks so very much for any advice,
        >
        > Dan
      • Ken Schwaber
        Dan, Two immediate suggestions are to attend a Scrum Certification class (see www.controlchaos.com) where this is covered, or bring in someone who has done
        Message 3 of 13 , Apr 13, 2003
        • 0 Attachment
          Dan,
          Two immediate suggestions are to attend a Scrum Certification class (see
          www.controlchaos.com) where this is covered, or bring in someone who has
          done this before using Scrum. Mike Cohn and Mike Beedle are certainly two
          who pop to mind.

          A brief answer to your question is that you lay out the product backlog into
          the future, until it contains the features and requirements that are being
          looked for in a release. You roughly estimate them based on your past
          experience and the best guesses of the teams. But you leave yourself wiggle
          room. Define the release in terms of general capabilities and functionality,
          not down to a gnat's eyelash. That way, as you find some functionality to be
          unrealizable, you can skimp on it or move it out to another release. Or, as
          competitive pressures require, you can change it out for something more
          important. Releases are done for competitive reasons and to satisfy key
          customer demands. Once the date, cost, and quality is fixed, we are all
          experts at wiggling the functionality to fit. Do so.

          The Scrum Certification class goes over what to do with fixed price/fixed
          date contracts, where you don't have the trust of management. The answer is
          to put in the effort to come up with some pretty reasonable estimates. But
          you state that you've taken over some failing projects and turned them
          around (a Scrum specialty). Now's the time to teach management to adjust
          functionality, cost, and date empirically, based on the product backlog, on
          a monthly basis. Get them attending the Sprint reviews and making the
          decisions.
          Ken Schwaber

          -----Original Message-----
          From: Dan Brown [mailto:kid_danomite@...]
          Sent: Friday, April 11, 2003 11:56 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Planning a product release


          I could use some advice from the group.

          Our group adapted Scrum about 5 months ago in the middle of a project
          that was failing. We since extended this to a couple other projects
          that were failing and it has worked wonders and I have grown in
          experience leading some of these projects. What no one on our team
          has any experience with is STARTING a product release with Scrum.

          I read a recommendation several (hundred?) messages ago that
          advocated something like a planning sprint to bring teams into
          Scrum. Our team is already bought into Scrum, and would like to
          evolve our design during many sprints with several Scrum teams
          working in parallel after which we will deliver our product.
          However, we are having a hard time telling management that we will be
          able to deliver a product with XY&Z in it on date D, without first
          doing enough of a design analysis on the feature list to feel like we
          really understand the complexities to give a solid estimate. In our
          industry, estimates are required because our business & our customers
          need some planning to bring together many elements, of which the
          software we will deliver is just one.

          I'm sure Scrum must be used places where these types of pre-project
          estimates must be given and contracted upon. What is done in this
          case? Is decomposing the user stories into what we feel are month-
          long product backlog bits in a planning sprint sufficient and
          recommended? Somehow I have a sinking feeling (clinging to my false
          sense of security in waterfall) that this may just get me fired.

          Thanks so very much for any advice,

          Dan




          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...

          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        • Mike Cohn
          Dan-- Dan-- I ve had a number of situations where I need to produce a deadline I can commit to but only have the beginnings of the requirements/tasks. Here s
          Message 4 of 13 , Apr 14, 2003
          • 0 Attachment
            Dan--
            Dan--

            I've had a number of situations where I need to produce a deadline I can
            commit to but only have the beginnings of the requirements/tasks. Here's
            what I do:

            I try to specify the requirements as XP user stories. I find those to be the
            best way to capture requirements for just about any agile project. This way
            they are not too small, not too big, but typically "just right" for
            estimating. Stories also avoid problems with task-estimating where many of
            the tasks are highly similar, which leads to a systematic error in the
            estimate (one mistake trickles through many estimates).

            For each story I estimate it at both 50% and 90% levels of confidence. My
            50% estimate is one I think I'll make half the time--if I coded that story
            20 times, 10 would finish ahead of this and 10 after. It has no padding in
            it. The 90% estimate assumes the task is on the hard end of the
            spectrum--it's not a "worst case" scenario because no one gets run over by a
            bus or anything like that in this estimate.

            My project schedule is then the sum of the 50% unbuffered estimates plus
            some buffer which is determined by looking at the differences between the
            50% and 90% estimates: take the square root of the sum of the differences
            between each 50% and 90% estimate and that will give you a reasonable
            project buffer. The approach is covered well in Leach's "Critical Chain
            Project Management."

            This gives me a buffered schedule that takes into account overall
            uncertainty (but isn't as huge as one from adding all the individual
            uncertainty, which would be wrong). I then round it up into a number of
            sprints. If the team is new to Scrum I may add one more sprint (month) to
            the end and use that as a "stabilization sprint" meaning the team will need
            that extra month to work out any last bugs.

            I've been very successful with this in estimating and committing to projects
            out about 9 months into the future. (I haven't failed with it at longer
            ones; I've just been able to avoid longer commitments!)

            I realize I didn't have time to type in many details (it's a busy month!)
            but I have written more about it on www.userstories.com if you're
            interested. If so, go to http://www.userstories.com/download.php and take a
            look at "Principles of Estimating," "Estimating User Stories," "Why Plans Go
            Wrong," and "Planning a Release."

            --Mike

            -----Original Message-----
            From: Dan Brown [mailto:kid_danomite@...]
            Sent: Friday, April 11, 2003 9:56 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Planning a product release

            I could use some advice from the group.

            Our group adapted Scrum about 5 months ago in the middle of a project
            that was failing. We since extended this to a couple other projects
            that were failing and it has worked wonders and I have grown in
            experience leading some of these projects. What no one on our team
            has any experience with is STARTING a product release with Scrum.

            I read a recommendation several (hundred?) messages ago that
            advocated something like a planning sprint to bring teams into
            Scrum. Our team is already bought into Scrum, and would like to
            evolve our design during many sprints with several Scrum teams
            working in parallel after which we will deliver our product.
            However, we are having a hard time telling management that we will be
            able to deliver a product with XY&Z in it on date D, without first
            doing enough of a design analysis on the feature list to feel like we
            really understand the complexities to give a solid estimate. In our
            industry, estimates are required because our business & our customers
            need some planning to bring together many elements, of which the
            software we will deliver is just one.

            I'm sure Scrum must be used places where these types of pre-project
            estimates must be given and contracted upon. What is done in this
            case? Is decomposing the user stories into what we feel are month-
            long product backlog bits in a planning sprint sufficient and
            recommended? Somehow I have a sinking feeling (clinging to my false
            sense of security in waterfall) that this may just get me fired.

            Thanks so very much for any advice,

            Dan




            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...

            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          • gilmanj_2000
            Mike, thanks for your response to Dan and I really enjoyed what you ve written so far on your user stories book. Look forward to it s completion. Here is my
            Message 5 of 13 , Apr 16, 2003
            • 0 Attachment
              Mike, thanks for your response to Dan and I really enjoyed what
              you've written so far on your user stories book. Look forward to
              it's completion.

              Here is my question. I understand the importance of including a
              proper buffer in the project itself. But, when estimating work in
              the product backlog e.g.
              http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
              your individual estimates include a buffer based on your 50% and 90%
              task estimates? Or are these your 50% estimates?

              Thanks, John

              --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
              wrote:
              > Dan--
              > Dan--
              >
              > I've had a number of situations where I need to produce a deadline
              I can
              > commit to but only have the beginnings of the requirements/tasks.
              Here's
              > what I do:
              >
              > I try to specify the requirements as XP user stories. I find those
              to be the
              > best way to capture requirements for just about any agile project.
              This way
              > they are not too small, not too big, but typically "just right" for
              > estimating. Stories also avoid problems with task-estimating where
              many of
              > the tasks are highly similar, which leads to a systematic error in
              the
              > estimate (one mistake trickles through many estimates).
              >
              > For each story I estimate it at both 50% and 90% levels of
              confidence. My
              > 50% estimate is one I think I'll make half the time--if I coded
              that story
              > 20 times, 10 would finish ahead of this and 10 after. It has no
              padding in
              > it. The 90% estimate assumes the task is on the hard end of the
              > spectrum--it's not a "worst case" scenario because no one gets run
              over by a
              > bus or anything like that in this estimate.
              >
              > My project schedule is then the sum of the 50% unbuffered estimates
              plus
              > some buffer which is determined by looking at the differences
              between the
              > 50% and 90% estimates: take the square root of the sum of the
              differences
              > between each 50% and 90% estimate and that will give you a
              reasonable
              > project buffer. The approach is covered well in Leach's "Critical
              Chain
              > Project Management."
              >
              > This gives me a buffered schedule that takes into account overall
              > uncertainty (but isn't as huge as one from adding all the individual
              > uncertainty, which would be wrong). I then round it up into a
              number of
              > sprints. If the team is new to Scrum I may add one more sprint
              (month) to
              > the end and use that as a "stabilization sprint" meaning the team
              will need
              > that extra month to work out any last bugs.
              >
              > I've been very successful with this in estimating and committing to
              projects
              > out about 9 months into the future. (I haven't failed with it at
              longer
              > ones; I've just been able to avoid longer commitments!)
              >
              > I realize I didn't have time to type in many details (it's a busy
              month!)
              > but I have written more about it on www.userstories.com if you're
              > interested. If so, go to http://www.userstories.com/download.php
              and take a
              > look at "Principles of Estimating," "Estimating User Stories," "Why
              Plans Go
              > Wrong," and "Planning a Release."
              >
              > --Mike
              >
              > -----Original Message-----
              > From: Dan Brown [mailto:kid_danomite@y...]
              > Sent: Friday, April 11, 2003 9:56 PM
              > To: scrumdevelopment@yahoogroups.com
              > Subject: [scrumdevelopment] Planning a product release
              >
              > I could use some advice from the group.
              >
              > Our group adapted Scrum about 5 months ago in the middle of a
              project
              > that was failing. We since extended this to a couple other
              projects
              > that were failing and it has worked wonders and I have grown in
              > experience leading some of these projects. What no one on our team
              > has any experience with is STARTING a product release with Scrum.
              >
              > I read a recommendation several (hundred?) messages ago that
              > advocated something like a planning sprint to bring teams into
              > Scrum. Our team is already bought into Scrum, and would like to
              > evolve our design during many sprints with several Scrum teams
              > working in parallel after which we will deliver our product.
              > However, we are having a hard time telling management that we will
              be
              > able to deliver a product with XY&Z in it on date D, without first
              > doing enough of a design analysis on the feature list to feel like
              we
              > really understand the complexities to give a solid estimate. In
              our
              > industry, estimates are required because our business & our
              customers
              > need some planning to bring together many elements, of which the
              > software we will deliver is just one.
              >
              > I'm sure Scrum must be used places where these types of pre-project
              > estimates must be given and contracted upon. What is done in this
              > case? Is decomposing the user stories into what we feel are month-
              > long product backlog bits in a planning sprint sufficient and
              > recommended? Somehow I have a sinking feeling (clinging to my
              false
              > sense of security in waterfall) that this may just get me fired.
              >
              > Thanks so very much for any advice,
              >
              > Dan
              >
              >
              >
              >
              > To Post a message, send it to: scrumdevelopment@e...
              > To Unsubscribe, send a blank message to:
              > scrumdevelopment-unsubscribe@e...
              >
              > Your use of Yahoo! Groups is subject to
              http://docs.yahoo.com/info/terms/
            • Mike Cohn
              John-- The image on the page is from a simplified version of the spreadsheet I was using at the time. There s a better version of the actual spreadsheet at
              Message 6 of 13 , Apr 16, 2003
              • 0 Attachment
                John--

                The image on the page is from a simplified version of the spreadsheet I was
                using at the time. There's a better version of the actual spreadsheet at
                http://www.mountaingoatsoftware.com/resources.html. In that one you'll see
                where I have columns for 50% and 90%. Developers have such an easier time
                saying "that will take 4 or 5 days" instead of "that will take 4 days" that
                I have the team formalize what they mean by their low and high estimates and
                then give both. Giving two estimates seems like twice the work of giving one
                estimate but it's actually much easier. Even better--the two estimates are
                more expressive so I can use them to size buffers early on.

                When a sprint is ongoing and we're tracking sprint backlog (as shown at
                http://www.mountaingoatsoftware.com/scrum/sprintbacklog.html) we just track
                a simple 50% estimate of the time left to completion. The work is already in
                the sprint at that point so you don't have any real control over the buffer
                (it's already sized) so there's no point in tracking 50% and 90% numbers for
                items in the sprint backlog.

                I'm glad you enjoyed the user stories drafts. I'd appreciate any specific
                feedback you have on it as I continue with it.

                --Mike

                -----Original Message-----
                From: gilmanj_2000 [mailto:jpgilman@...]
                Sent: Wednesday, April 16, 2003 5:34 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] Re: Planning a product release

                Mike, thanks for your response to Dan and I really enjoyed what
                you've written so far on your user stories book. Look forward to
                it's completion.

                Here is my question. I understand the importance of including a
                proper buffer in the project itself. But, when estimating work in
                the product backlog e.g.
                http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
                your individual estimates include a buffer based on your 50% and 90%
                task estimates? Or are these your 50% estimates?

                Thanks, John

                --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                wrote:
                > Dan--
                > Dan--
                >
                > I've had a number of situations where I need to produce a deadline
                I can
                > commit to but only have the beginnings of the requirements/tasks.
                Here's
                > what I do:
                >
                > I try to specify the requirements as XP user stories. I find those
                to be the
                > best way to capture requirements for just about any agile project.
                This way
                > they are not too small, not too big, but typically "just right" for
                > estimating. Stories also avoid problems with task-estimating where
                many of
                > the tasks are highly similar, which leads to a systematic error in
                the
                > estimate (one mistake trickles through many estimates).
                >
                > For each story I estimate it at both 50% and 90% levels of
                confidence. My
                > 50% estimate is one I think I'll make half the time--if I coded
                that story
                > 20 times, 10 would finish ahead of this and 10 after. It has no
                padding in
                > it. The 90% estimate assumes the task is on the hard end of the
                > spectrum--it's not a "worst case" scenario because no one gets run
                over by a
                > bus or anything like that in this estimate.
                >
                > My project schedule is then the sum of the 50% unbuffered estimates
                plus
                > some buffer which is determined by looking at the differences
                between the
                > 50% and 90% estimates: take the square root of the sum of the
                differences
                > between each 50% and 90% estimate and that will give you a
                reasonable
                > project buffer. The approach is covered well in Leach's "Critical
                Chain
                > Project Management."
                >
                > This gives me a buffered schedule that takes into account overall
                > uncertainty (but isn't as huge as one from adding all the individual
                > uncertainty, which would be wrong). I then round it up into a
                number of
                > sprints. If the team is new to Scrum I may add one more sprint
                (month) to
                > the end and use that as a "stabilization sprint" meaning the team
                will need
                > that extra month to work out any last bugs.
                >
                > I've been very successful with this in estimating and committing to
                projects
                > out about 9 months into the future. (I haven't failed with it at
                longer
                > ones; I've just been able to avoid longer commitments!)
                >
                > I realize I didn't have time to type in many details (it's a busy
                month!)
                > but I have written more about it on www.userstories.com if you're
                > interested. If so, go to http://www.userstories.com/download.php
                and take a
                > look at "Principles of Estimating," "Estimating User Stories," "Why
                Plans Go
                > Wrong," and "Planning a Release."
                >
                > --Mike
                >
                > -----Original Message-----
                > From: Dan Brown [mailto:kid_danomite@y...]
                > Sent: Friday, April 11, 2003 9:56 PM
                > To: scrumdevelopment@yahoogroups.com
                > Subject: [scrumdevelopment] Planning a product release
                >
                > I could use some advice from the group.
                >
                > Our group adapted Scrum about 5 months ago in the middle of a
                project
                > that was failing. We since extended this to a couple other
                projects
                > that were failing and it has worked wonders and I have grown in
                > experience leading some of these projects. What no one on our team
                > has any experience with is STARTING a product release with Scrum.
                >
                > I read a recommendation several (hundred?) messages ago that
                > advocated something like a planning sprint to bring teams into
                > Scrum. Our team is already bought into Scrum, and would like to
                > evolve our design during many sprints with several Scrum teams
                > working in parallel after which we will deliver our product.
                > However, we are having a hard time telling management that we will
                be
                > able to deliver a product with XY&Z in it on date D, without first
                > doing enough of a design analysis on the feature list to feel like
                we
                > really understand the complexities to give a solid estimate. In
                our
                > industry, estimates are required because our business & our
                customers
                > need some planning to bring together many elements, of which the
                > software we will deliver is just one.
                >
                > I'm sure Scrum must be used places where these types of pre-project
                > estimates must be given and contracted upon. What is done in this
                > case? Is decomposing the user stories into what we feel are month-
                > long product backlog bits in a planning sprint sufficient and
                > recommended? Somehow I have a sinking feeling (clinging to my
                false
                > sense of security in waterfall) that this may just get me fired.
                >
                > Thanks so very much for any advice,
                >
                > Dan
                >
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@e...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@e...
                >
                > Your use of Yahoo! Groups is subject to
                http://docs.yahoo.com/info/terms/



                To Post a message, send it to: scrumdevelopment@...
                To Unsubscribe, send a blank message to:
                scrumdevelopment-unsubscribe@...

                Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              • John Gilman
                Thanks, Mike What I found at http://www.mountaingoatsoftware.com/resources.html was a sprint burndown chart. Are you saying that you also use the same
                Message 7 of 13 , Apr 16, 2003
                • 0 Attachment
                  Thanks, Mike

                  What I found at http://www.mountaingoatsoftware.com/resources.html
                  was a sprint burndown chart. Are you saying that you also use the
                  same estimates and/or format for your product backlog?

                  John

                  --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                  wrote:
                  > John--
                  >
                  > The image on the page is from a simplified version of the
                  spreadsheet I was
                  > using at the time. There's a better version of the actual
                  spreadsheet at
                  > http://www.mountaingoatsoftware.com/resources.html. In that one
                  you'll see
                  > where I have columns for 50% and 90%. Developers have such an
                  easier time
                  > saying "that will take 4 or 5 days" instead of "that will take 4
                  days" that
                  > I have the team formalize what they mean by their low and high
                  estimates and
                  > then give both. Giving two estimates seems like twice the work of
                  giving one
                  > estimate but it's actually much easier. Even better--the two
                  estimates are
                  > more expressive so I can use them to size buffers early on.
                  >
                  > When a sprint is ongoing and we're tracking sprint backlog (as
                  shown at
                  > http://www.mountaingoatsoftware.com/scrum/sprintbacklog.html) we
                  just track
                  > a simple 50% estimate of the time left to completion. The work is
                  already in
                  > the sprint at that point so you don't have any real control over
                  the buffer
                  > (it's already sized) so there's no point in tracking 50% and 90%
                  numbers for
                  > items in the sprint backlog.
                  >
                  > I'm glad you enjoyed the user stories drafts. I'd appreciate any
                  specific
                  > feedback you have on it as I continue with it.
                  >
                  > --Mike
                  >
                  > -----Original Message-----
                  > From: gilmanj_2000 [mailto:jpgilman@m...]
                  > Sent: Wednesday, April 16, 2003 5:34 PM
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: [scrumdevelopment] Re: Planning a product release
                  >
                  > Mike, thanks for your response to Dan and I really enjoyed what
                  > you've written so far on your user stories book. Look forward to
                  > it's completion.
                  >
                  > Here is my question. I understand the importance of including a
                  > proper buffer in the project itself. But, when estimating work in
                  > the product backlog e.g.
                  > http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
                  > your individual estimates include a buffer based on your 50% and
                  90%
                  > task estimates? Or are these your 50% estimates?
                  >
                  > Thanks, John
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                  > wrote:
                  > > Dan--
                  > > Dan--
                  > >
                  > > I've had a number of situations where I need to produce a
                  deadline
                  > I can
                  > > commit to but only have the beginnings of the
                  requirements/tasks.
                  > Here's
                  > > what I do:
                  > >
                  > > I try to specify the requirements as XP user stories. I find
                  those
                  > to be the
                  > > best way to capture requirements for just about any agile
                  project.
                  > This way
                  > > they are not too small, not too big, but typically "just right"
                  for
                  > > estimating. Stories also avoid problems with task-estimating
                  where
                  > many of
                  > > the tasks are highly similar, which leads to a systematic error
                  in
                  > the
                  > > estimate (one mistake trickles through many estimates).
                  > >
                  > > For each story I estimate it at both 50% and 90% levels of
                  > confidence. My
                  > > 50% estimate is one I think I'll make half the time--if I coded
                  > that story
                  > > 20 times, 10 would finish ahead of this and 10 after. It has no
                  > padding in
                  > > it. The 90% estimate assumes the task is on the hard end of the
                  > > spectrum--it's not a "worst case" scenario because no one gets
                  run
                  > over by a
                  > > bus or anything like that in this estimate.
                  > >
                  > > My project schedule is then the sum of the 50% unbuffered
                  estimates
                  > plus
                  > > some buffer which is determined by looking at the differences
                  > between the
                  > > 50% and 90% estimates: take the square root of the sum of the
                  > differences
                  > > between each 50% and 90% estimate and that will give you a
                  > reasonable
                  > > project buffer. The approach is covered well in
                  Leach's "Critical
                  > Chain
                  > > Project Management."
                  > >
                  > > This gives me a buffered schedule that takes into account overall
                  > > uncertainty (but isn't as huge as one from adding all the
                  individual
                  > > uncertainty, which would be wrong). I then round it up into a
                  > number of
                  > > sprints. If the team is new to Scrum I may add one more sprint
                  > (month) to
                  > > the end and use that as a "stabilization sprint" meaning the
                  team
                  > will need
                  > > that extra month to work out any last bugs.
                  > >
                  > > I've been very successful with this in estimating and committing
                  to
                  > projects
                  > > out about 9 months into the future. (I haven't failed with it at
                  > longer
                  > > ones; I've just been able to avoid longer commitments!)
                  > >
                  > > I realize I didn't have time to type in many details (it's a
                  busy
                  > month!)
                  > > but I have written more about it on www.userstories.com if you're
                  > > interested. If so, go to http://www.userstories.com/download.php
                  > and take a
                  > > look at "Principles of Estimating," "Estimating User
                  Stories," "Why
                  > Plans Go
                  > > Wrong," and "Planning a Release."
                  > >
                  > > --Mike
                  > >
                  > > -----Original Message-----
                  > > From: Dan Brown [mailto:kid_danomite@y...]
                  > > Sent: Friday, April 11, 2003 9:56 PM
                  > > To: scrumdevelopment@yahoogroups.com
                  > > Subject: [scrumdevelopment] Planning a product release
                  > >
                  > > I could use some advice from the group.
                  > >
                  > > Our group adapted Scrum about 5 months ago in the middle of a
                  > project
                  > > that was failing. We since extended this to a couple other
                  > projects
                  > > that were failing and it has worked wonders and I have grown in
                  > > experience leading some of these projects. What no one on our
                  team
                  > > has any experience with is STARTING a product release with
                  Scrum.
                  > >
                  > > I read a recommendation several (hundred?) messages ago that
                  > > advocated something like a planning sprint to bring teams into
                  > > Scrum. Our team is already bought into Scrum, and would like to
                  > > evolve our design during many sprints with several Scrum teams
                  > > working in parallel after which we will deliver our product.
                  > > However, we are having a hard time telling management that we
                  will
                  > be
                  > > able to deliver a product with XY&Z in it on date D, without
                  first
                  > > doing enough of a design analysis on the feature list to feel
                  like
                  > we
                  > > really understand the complexities to give a solid estimate. In
                  > our
                  > > industry, estimates are required because our business & our
                  > customers
                  > > need some planning to bring together many elements, of which the
                  > > software we will deliver is just one.
                  > >
                  > > I'm sure Scrum must be used places where these types of pre-
                  project
                  > > estimates must be given and contracted upon. What is done in
                  this
                  > > case? Is decomposing the user stories into what we feel are
                  month-
                  > > long product backlog bits in a planning sprint sufficient and
                  > > recommended? Somehow I have a sinking feeling (clinging to my
                  > false
                  > > sense of security in waterfall) that this may just get me fired.
                  > >
                  > > Thanks so very much for any advice,
                  > >
                  > > Dan
                  > >
                  > >
                  > >
                  > >
                  > > To Post a message, send it to: scrumdevelopment@e...
                  > > To Unsubscribe, send a blank message to:
                  > > scrumdevelopment-unsubscribe@e...
                  > >
                  > > Your use of Yahoo! Groups is subject to
                  > http://docs.yahoo.com/info/terms/
                  >
                  >
                  >
                  > To Post a message, send it to: scrumdevelopment@e...
                  > To Unsubscribe, send a blank message to:
                  > scrumdevelopment-unsubscribe@e...
                  >
                  > Your use of Yahoo! Groups is subject to
                  http://docs.yahoo.com/info/terms/
                • Dan Brown
                  Mike & Ken: Thanks! That makes a lot of sense, but it will take some practice to decompose our stories into 3-4 day chunks instead of diving into the design
                  Message 8 of 13 , Apr 16, 2003
                  • 0 Attachment
                    Mike & Ken:

                    Thanks! That makes a lot of sense, but it will take some practice to
                    decompose our stories into 3-4 day chunks instead of diving into the
                    design of a big task more quickly.

                    Mike - I hope the answer to the XXXXXXXX on c 7, p 48 comes out the
                    way you want it!

                    One final thing - I did notice a potential error on c9, p74, where
                    the text & the table are inconsistent about using the square root of
                    the sum of the squares (probably what you want) or the square root of
                    the sum. The other thing you may want to mention at the end of this
                    page (74) when comparing simple 50% buffers to square root sum of the
                    squares is that if you have a large number of tasks, the 50% buffer
                    grows much more quickly than the square root of the sum of squares
                    (i.e. for a very large program, this may represent very little
                    difference from the 50% case). Have you ever tried something like
                    taking the an average of the sum of the 50% & the sum of the 90% or
                    if you want to stick with the square of the difference approximating
                    the variance of the task you could even set confidence bounds on the
                    project by estimating the average of the sum(50%) & sum(90%) plus or
                    minus the square root of the sum of the squares of the differences.
                    This would have the added benefit of telling you if your confidence
                    bounds are, perhaps, longer than 1 Sprint-length.

                    Dan


                    --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                    wrote:
                    > John--
                    >
                    > The image on the page is from a simplified version of the
                    spreadsheet I was
                    > using at the time. There's a better version of the actual
                    spreadsheet at
                    > http://www.mountaingoatsoftware.com/resources.html. In that one
                    you'll see
                    > where I have columns for 50% and 90%. Developers have such an
                    easier time
                    > saying "that will take 4 or 5 days" instead of "that will take 4
                    days" that
                    > I have the team formalize what they mean by their low and high
                    estimates and
                    > then give both. Giving two estimates seems like twice the work of
                    giving one
                    > estimate but it's actually much easier. Even better--the two
                    estimates are
                    > more expressive so I can use them to size buffers early on.
                    >
                    > When a sprint is ongoing and we're tracking sprint backlog (as
                    shown at
                    > http://www.mountaingoatsoftware.com/scrum/sprintbacklog.html) we
                    just track
                    > a simple 50% estimate of the time left to completion. The work is
                    already in
                    > the sprint at that point so you don't have any real control over
                    the buffer
                    > (it's already sized) so there's no point in tracking 50% and 90%
                    numbers for
                    > items in the sprint backlog.
                    >
                    > I'm glad you enjoyed the user stories drafts. I'd appreciate any
                    specific
                    > feedback you have on it as I continue with it.
                    >
                    > --Mike
                    >
                    > -----Original Message-----
                    > From: gilmanj_2000 [mailto:jpgilman@m...]
                    > Sent: Wednesday, April 16, 2003 5:34 PM
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: [scrumdevelopment] Re: Planning a product release
                    >
                    > Mike, thanks for your response to Dan and I really enjoyed what
                    > you've written so far on your user stories book. Look forward to
                    > it's completion.
                    >
                    > Here is my question. I understand the importance of including a
                    > proper buffer in the project itself. But, when estimating work in
                    > the product backlog e.g.
                    > http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
                    > your individual estimates include a buffer based on your 50% and
                    90%
                    > task estimates? Or are these your 50% estimates?
                    >
                    > Thanks, John
                    >
                    > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                    > wrote:
                    > > Dan--
                    > > Dan--
                    > >
                    > > I've had a number of situations where I need to produce a
                    deadline
                    > I can
                    > > commit to but only have the beginnings of the requirements/tasks.
                    > Here's
                    > > what I do:
                    > >
                    > > I try to specify the requirements as XP user stories. I find
                    those
                    > to be the
                    > > best way to capture requirements for just about any agile
                    project.
                    > This way
                    > > they are not too small, not too big, but typically "just right"
                    for
                    > > estimating. Stories also avoid problems with task-estimating
                    where
                    > many of
                    > > the tasks are highly similar, which leads to a systematic error
                    in
                    > the
                    > > estimate (one mistake trickles through many estimates).
                    > >
                    > > For each story I estimate it at both 50% and 90% levels of
                    > confidence. My
                    > > 50% estimate is one I think I'll make half the time--if I coded
                    > that story
                    > > 20 times, 10 would finish ahead of this and 10 after. It has no
                    > padding in
                    > > it. The 90% estimate assumes the task is on the hard end of the
                    > > spectrum--it's not a "worst case" scenario because no one gets
                    run
                    > over by a
                    > > bus or anything like that in this estimate.
                    > >
                    > > My project schedule is then the sum of the 50% unbuffered
                    estimates
                    > plus
                    > > some buffer which is determined by looking at the differences
                    > between the
                    > > 50% and 90% estimates: take the square root of the sum of the
                    > differences
                    > > between each 50% and 90% estimate and that will give you a
                    > reasonable
                    > > project buffer. The approach is covered well in
                    Leach's "Critical
                    > Chain
                    > > Project Management."
                    > >
                    > > This gives me a buffered schedule that takes into account overall
                    > > uncertainty (but isn't as huge as one from adding all the
                    individual
                    > > uncertainty, which would be wrong). I then round it up into a
                    > number of
                    > > sprints. If the team is new to Scrum I may add one more sprint
                    > (month) to
                    > > the end and use that as a "stabilization sprint" meaning the team
                    > will need
                    > > that extra month to work out any last bugs.
                    > >
                    > > I've been very successful with this in estimating and committing
                    to
                    > projects
                    > > out about 9 months into the future. (I haven't failed with it at
                    > longer
                    > > ones; I've just been able to avoid longer commitments!)
                    > >
                    > > I realize I didn't have time to type in many details (it's a busy
                    > month!)
                    > > but I have written more about it on www.userstories.com if you're
                    > > interested. If so, go to http://www.userstories.com/download.php
                    > and take a
                    > > look at "Principles of Estimating," "Estimating User
                    Stories," "Why
                    > Plans Go
                    > > Wrong," and "Planning a Release."
                    > >
                    > > --Mike
                    > >
                    > > -----Original Message-----
                    > > From: Dan Brown [mailto:kid_danomite@y...]
                    > > Sent: Friday, April 11, 2003 9:56 PM
                    > > To: scrumdevelopment@yahoogroups.com
                    > > Subject: [scrumdevelopment] Planning a product release
                    > >
                    > > I could use some advice from the group.
                    > >
                    > > Our group adapted Scrum about 5 months ago in the middle of a
                    > project
                    > > that was failing. We since extended this to a couple other
                    > projects
                    > > that were failing and it has worked wonders and I have grown in
                    > > experience leading some of these projects. What no one on our
                    team
                    > > has any experience with is STARTING a product release with
                    Scrum.
                    > >
                    > > I read a recommendation several (hundred?) messages ago that
                    > > advocated something like a planning sprint to bring teams into
                    > > Scrum. Our team is already bought into Scrum, and would like to
                    > > evolve our design during many sprints with several Scrum teams
                    > > working in parallel after which we will deliver our product.
                    > > However, we are having a hard time telling management that we
                    will
                    > be
                    > > able to deliver a product with XY&Z in it on date D, without
                    first
                    > > doing enough of a design analysis on the feature list to feel
                    like
                    > we
                    > > really understand the complexities to give a solid estimate. In
                    > our
                    > > industry, estimates are required because our business & our
                    > customers
                    > > need some planning to bring together many elements, of which the
                    > > software we will deliver is just one.
                    > >
                    > > I'm sure Scrum must be used places where these types of pre-
                    project
                    > > estimates must be given and contracted upon. What is done in
                    this
                    > > case? Is decomposing the user stories into what we feel are
                    month-
                    > > long product backlog bits in a planning sprint sufficient and
                    > > recommended? Somehow I have a sinking feeling (clinging to my
                    > false
                    > > sense of security in waterfall) that this may just get me fired.
                    > >
                    > > Thanks so very much for any advice,
                    > >
                    > > Dan
                    > >
                    > >
                    > >
                    > >
                    > > To Post a message, send it to: scrumdevelopment@e...
                    > > To Unsubscribe, send a blank message to:
                    > > scrumdevelopment-unsubscribe@e...
                    > >
                    > > Your use of Yahoo! Groups is subject to
                    > http://docs.yahoo.com/info/terms/
                    >
                    >
                    >
                    > To Post a message, send it to: scrumdevelopment@e...
                    > To Unsubscribe, send a blank message to:
                    > scrumdevelopment-unsubscribe@e...
                    >
                    > Your use of Yahoo! Groups is subject to
                    http://docs.yahoo.com/info/terms/
                  • Mike Cohn
                    John-- Yes, I use effectively the same spreadsheet for the product backlog. It doesn t have columns for tracking the burndown by date--there s just a 50% and
                    Message 9 of 13 , Apr 20, 2003
                    • 0 Attachment
                      John--
                      Yes, I use effectively the same spreadsheet for the product backlog. It
                      doesn't have columns for tracking the burndown by date--there's just a 50%
                      and 90% column in the product backlog. Then there are columns for who gave
                      the estimate and the date it was given. Those are sometimes useful if you
                      have to go back and ask, "Joe, does it still look like 40 hours to do the
                      XML report?" or "Mary, you thought XML reporting would take 40 hours but I
                      can see from the date column that this was before we started using JAXB. Do
                      you still think it's 40 hours?"

                      -Mike

                      -----Original Message-----
                      From: John Gilman [mailto:jpgilman@...]
                      Sent: Wednesday, April 16, 2003 9:36 PM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: [scrumdevelopment] Re: Planning a product release

                      Thanks, Mike

                      What I found at http://www.mountaingoatsoftware.com/resources.html
                      was a sprint burndown chart. Are you saying that you also use the
                      same estimates and/or format for your product backlog?

                      John

                      --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                      wrote:
                      > John--
                      >
                      > The image on the page is from a simplified version of the
                      spreadsheet I was
                      > using at the time. There's a better version of the actual
                      spreadsheet at
                      > http://www.mountaingoatsoftware.com/resources.html. In that one
                      you'll see
                      > where I have columns for 50% and 90%. Developers have such an
                      easier time
                      > saying "that will take 4 or 5 days" instead of "that will take 4
                      days" that
                      > I have the team formalize what they mean by their low and high
                      estimates and
                      > then give both. Giving two estimates seems like twice the work of
                      giving one
                      > estimate but it's actually much easier. Even better--the two
                      estimates are
                      > more expressive so I can use them to size buffers early on.
                      >
                      > When a sprint is ongoing and we're tracking sprint backlog (as
                      shown at
                      > http://www.mountaingoatsoftware.com/scrum/sprintbacklog.html) we
                      just track
                      > a simple 50% estimate of the time left to completion. The work is
                      already in
                      > the sprint at that point so you don't have any real control over
                      the buffer
                      > (it's already sized) so there's no point in tracking 50% and 90%
                      numbers for
                      > items in the sprint backlog.
                      >
                      > I'm glad you enjoyed the user stories drafts. I'd appreciate any
                      specific
                      > feedback you have on it as I continue with it.
                      >
                      > --Mike
                      >
                      > -----Original Message-----
                      > From: gilmanj_2000 [mailto:jpgilman@m...]
                      > Sent: Wednesday, April 16, 2003 5:34 PM
                      > To: scrumdevelopment@yahoogroups.com
                      > Subject: [scrumdevelopment] Re: Planning a product release
                      >
                      > Mike, thanks for your response to Dan and I really enjoyed what
                      > you've written so far on your user stories book. Look forward to
                      > it's completion.
                      >
                      > Here is my question. I understand the importance of including a
                      > proper buffer in the project itself. But, when estimating work in
                      > the product backlog e.g.
                      > http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
                      > your individual estimates include a buffer based on your 50% and
                      90%
                      > task estimates? Or are these your 50% estimates?
                      >
                      > Thanks, John
                      >
                      > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                      > wrote:
                      > > Dan--
                      > > Dan--
                      > >
                      > > I've had a number of situations where I need to produce a
                      deadline
                      > I can
                      > > commit to but only have the beginnings of the
                      requirements/tasks.
                      > Here's
                      > > what I do:
                      > >
                      > > I try to specify the requirements as XP user stories. I find
                      those
                      > to be the
                      > > best way to capture requirements for just about any agile
                      project.
                      > This way
                      > > they are not too small, not too big, but typically "just right"
                      for
                      > > estimating. Stories also avoid problems with task-estimating
                      where
                      > many of
                      > > the tasks are highly similar, which leads to a systematic error
                      in
                      > the
                      > > estimate (one mistake trickles through many estimates).
                      > >
                      > > For each story I estimate it at both 50% and 90% levels of
                      > confidence. My
                      > > 50% estimate is one I think I'll make half the time--if I coded
                      > that story
                      > > 20 times, 10 would finish ahead of this and 10 after. It has no
                      > padding in
                      > > it. The 90% estimate assumes the task is on the hard end of the
                      > > spectrum--it's not a "worst case" scenario because no one gets
                      run
                      > over by a
                      > > bus or anything like that in this estimate.
                      > >
                      > > My project schedule is then the sum of the 50% unbuffered
                      estimates
                      > plus
                      > > some buffer which is determined by looking at the differences
                      > between the
                      > > 50% and 90% estimates: take the square root of the sum of the
                      > differences
                      > > between each 50% and 90% estimate and that will give you a
                      > reasonable
                      > > project buffer. The approach is covered well in
                      Leach's "Critical
                      > Chain
                      > > Project Management."
                      > >
                      > > This gives me a buffered schedule that takes into account overall
                      > > uncertainty (but isn't as huge as one from adding all the
                      individual
                      > > uncertainty, which would be wrong). I then round it up into a
                      > number of
                      > > sprints. If the team is new to Scrum I may add one more sprint
                      > (month) to
                      > > the end and use that as a "stabilization sprint" meaning the
                      team
                      > will need
                      > > that extra month to work out any last bugs.
                      > >
                      > > I've been very successful with this in estimating and committing
                      to
                      > projects
                      > > out about 9 months into the future. (I haven't failed with it at
                      > longer
                      > > ones; I've just been able to avoid longer commitments!)
                      > >
                      > > I realize I didn't have time to type in many details (it's a
                      busy
                      > month!)
                      > > but I have written more about it on www.userstories.com if you're
                      > > interested. If so, go to http://www.userstories.com/download.php
                      > and take a
                      > > look at "Principles of Estimating," "Estimating User
                      Stories," "Why
                      > Plans Go
                      > > Wrong," and "Planning a Release."
                      > >
                      > > --Mike
                      > >
                      > > -----Original Message-----
                      > > From: Dan Brown [mailto:kid_danomite@y...]
                      > > Sent: Friday, April 11, 2003 9:56 PM
                      > > To: scrumdevelopment@yahoogroups.com
                      > > Subject: [scrumdevelopment] Planning a product release
                      > >
                      > > I could use some advice from the group.
                      > >
                      > > Our group adapted Scrum about 5 months ago in the middle of a
                      > project
                      > > that was failing. We since extended this to a couple other
                      > projects
                      > > that were failing and it has worked wonders and I have grown in
                      > > experience leading some of these projects. What no one on our
                      team
                      > > has any experience with is STARTING a product release with
                      Scrum.
                      > >
                      > > I read a recommendation several (hundred?) messages ago that
                      > > advocated something like a planning sprint to bring teams into
                      > > Scrum. Our team is already bought into Scrum, and would like to
                      > > evolve our design during many sprints with several Scrum teams
                      > > working in parallel after which we will deliver our product.
                      > > However, we are having a hard time telling management that we
                      will
                      > be
                      > > able to deliver a product with XY&Z in it on date D, without
                      first
                      > > doing enough of a design analysis on the feature list to feel
                      like
                      > we
                      > > really understand the complexities to give a solid estimate. In
                      > our
                      > > industry, estimates are required because our business & our
                      > customers
                      > > need some planning to bring together many elements, of which the
                      > > software we will deliver is just one.
                      > >
                      > > I'm sure Scrum must be used places where these types of pre-
                      project
                      > > estimates must be given and contracted upon. What is done in
                      this
                      > > case? Is decomposing the user stories into what we feel are
                      month-
                      > > long product backlog bits in a planning sprint sufficient and
                      > > recommended? Somehow I have a sinking feeling (clinging to my
                      > false
                      > > sense of security in waterfall) that this may just get me fired.
                      > >
                      > > Thanks so very much for any advice,
                      > >
                      > > Dan
                      > >
                      > >
                      > >
                      > >
                      > > To Post a message, send it to: scrumdevelopment@e...
                      > > To Unsubscribe, send a blank message to:
                      > > scrumdevelopment-unsubscribe@e...
                      > >
                      > > Your use of Yahoo! Groups is subject to
                      > http://docs.yahoo.com/info/terms/
                      >
                      >
                      >
                      > To Post a message, send it to: scrumdevelopment@e...
                      > To Unsubscribe, send a blank message to:
                      > scrumdevelopment-unsubscribe@e...
                      >
                      > Your use of Yahoo! Groups is subject to
                      http://docs.yahoo.com/info/terms/



                      To Post a message, send it to: scrumdevelopment@...
                      To Unsubscribe, send a blank message to:
                      scrumdevelopment-unsubscribe@...

                      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                    • John Gilman
                      Thanks, Mike. I put together our Product Backlog last week which includes both. The items are mostly Big User Stories, with smaller, estimatable stories as
                      Message 10 of 13 , Apr 21, 2003
                      • 0 Attachment
                        Thanks, Mike. I put together our Product Backlog last week which
                        includes both. The items are mostly Big User Stories, with smaller,
                        estimatable stories as children. This week I initiated a series of
                        small meetings to discover the estimatable user stories and provide
                        estimates.

                        John

                        --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                        wrote:
                        > John--
                        > Yes, I use effectively the same spreadsheet for the product
                        backlog. It
                        > doesn't have columns for tracking the burndown by date--there's
                        just a 50%
                        > and 90% column in the product backlog. Then there are columns for
                        who gave
                        > the estimate and the date it was given. Those are sometimes useful
                        if you
                        > have to go back and ask, "Joe, does it still look like 40 hours to
                        do the
                        > XML report?" or "Mary, you thought XML reporting would take 40
                        hours but I
                        > can see from the date column that this was before we started using
                        JAXB. Do
                        > you still think it's 40 hours?"
                        >
                        > -Mike
                        >
                        > -----Original Message-----
                        > From: John Gilman [mailto:jpgilman@m...]
                        > Sent: Wednesday, April 16, 2003 9:36 PM
                        > To: scrumdevelopment@yahoogroups.com
                        > Subject: [scrumdevelopment] Re: Planning a product release
                        >
                        > Thanks, Mike
                        >
                        > What I found at http://www.mountaingoatsoftware.com/resources.html
                        > was a sprint burndown chart. Are you saying that you also use the
                        > same estimates and/or format for your product backlog?
                        >
                        > John
                        >
                        > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                        > wrote:
                        > > John--
                        > >
                        > > The image on the page is from a simplified version of the
                        > spreadsheet I was
                        > > using at the time. There's a better version of the actual
                        > spreadsheet at
                        > > http://www.mountaingoatsoftware.com/resources.html. In that one
                        > you'll see
                        > > where I have columns for 50% and 90%. Developers have such an
                        > easier time
                        > > saying "that will take 4 or 5 days" instead of "that will take 4
                        > days" that
                        > > I have the team formalize what they mean by their low and high
                        > estimates and
                        > > then give both. Giving two estimates seems like twice the work of
                        > giving one
                        > > estimate but it's actually much easier. Even better--the two
                        > estimates are
                        > > more expressive so I can use them to size buffers early on.
                        > >
                        > > When a sprint is ongoing and we're tracking sprint backlog (as
                        > shown at
                        > > http://www.mountaingoatsoftware.com/scrum/sprintbacklog.html) we
                        > just track
                        > > a simple 50% estimate of the time left to completion. The work is
                        > already in
                        > > the sprint at that point so you don't have any real control over
                        > the buffer
                        > > (it's already sized) so there's no point in tracking 50% and 90%
                        > numbers for
                        > > items in the sprint backlog.
                        > >
                        > > I'm glad you enjoyed the user stories drafts. I'd appreciate any
                        > specific
                        > > feedback you have on it as I continue with it.
                        > >
                        > > --Mike
                        > >
                        > > -----Original Message-----
                        > > From: gilmanj_2000 [mailto:jpgilman@m...]
                        > > Sent: Wednesday, April 16, 2003 5:34 PM
                        > > To: scrumdevelopment@yahoogroups.com
                        > > Subject: [scrumdevelopment] Re: Planning a product release
                        > >
                        > > Mike, thanks for your response to Dan and I really enjoyed what
                        > > you've written so far on your user stories book. Look forward to
                        > > it's completion.
                        > >
                        > > Here is my question. I understand the importance of including a
                        > > proper buffer in the project itself. But, when estimating work
                        in
                        > > the product backlog e.g.
                        > > http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
                        > > your individual estimates include a buffer based on your 50% and
                        > 90%
                        > > task estimates? Or are these your 50% estimates?
                        > >
                        > > Thanks, John
                        > >
                        > > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                        > > wrote:
                        > > > Dan--
                        > > > Dan--
                        > > >
                        > > > I've had a number of situations where I need to produce a
                        > deadline
                        > > I can
                        > > > commit to but only have the beginnings of the
                        > requirements/tasks.
                        > > Here's
                        > > > what I do:
                        > > >
                        > > > I try to specify the requirements as XP user stories. I find
                        > those
                        > > to be the
                        > > > best way to capture requirements for just about any agile
                        > project.
                        > > This way
                        > > > they are not too small, not too big, but typically "just right"
                        > for
                        > > > estimating. Stories also avoid problems with task-estimating
                        > where
                        > > many of
                        > > > the tasks are highly similar, which leads to a systematic error
                        > in
                        > > the
                        > > > estimate (one mistake trickles through many estimates).
                        > > >
                        > > > For each story I estimate it at both 50% and 90% levels of
                        > > confidence. My
                        > > > 50% estimate is one I think I'll make half the time--if I coded
                        > > that story
                        > > > 20 times, 10 would finish ahead of this and 10 after. It has no
                        > > padding in
                        > > > it. The 90% estimate assumes the task is on the hard end of the
                        > > > spectrum--it's not a "worst case" scenario because no one gets
                        > run
                        > > over by a
                        > > > bus or anything like that in this estimate.
                        > > >
                        > > > My project schedule is then the sum of the 50% unbuffered
                        > estimates
                        > > plus
                        > > > some buffer which is determined by looking at the differences
                        > > between the
                        > > > 50% and 90% estimates: take the square root of the sum of the
                        > > differences
                        > > > between each 50% and 90% estimate and that will give you a
                        > > reasonable
                        > > > project buffer. The approach is covered well in
                        > Leach's "Critical
                        > > Chain
                        > > > Project Management."
                        > > >
                        > > > This gives me a buffered schedule that takes into account
                        overall
                        > > > uncertainty (but isn't as huge as one from adding all the
                        > individual
                        > > > uncertainty, which would be wrong). I then round it up into a
                        > > number of
                        > > > sprints. If the team is new to Scrum I may add one more sprint
                        > > (month) to
                        > > > the end and use that as a "stabilization sprint" meaning the
                        > team
                        > > will need
                        > > > that extra month to work out any last bugs.
                        > > >
                        > > > I've been very successful with this in estimating and
                        committing
                        > to
                        > > projects
                        > > > out about 9 months into the future. (I haven't failed with it
                        at
                        > > longer
                        > > > ones; I've just been able to avoid longer commitments!)
                        > > >
                        > > > I realize I didn't have time to type in many details (it's a
                        > busy
                        > > month!)
                        > > > but I have written more about it on www.userstories.com if
                        you're
                        > > > interested. If so, go to
                        http://www.userstories.com/download.php
                        > > and take a
                        > > > look at "Principles of Estimating," "Estimating User
                        > Stories," "Why
                        > > Plans Go
                        > > > Wrong," and "Planning a Release."
                        > > >
                        > > > --Mike
                        > > >
                        > > > -----Original Message-----
                        > > > From: Dan Brown [mailto:kid_danomite@y...]
                        > > > Sent: Friday, April 11, 2003 9:56 PM
                        > > > To: scrumdevelopment@yahoogroups.com
                        > > > Subject: [scrumdevelopment] Planning a product release
                        > > >
                        > > > I could use some advice from the group.
                        > > >
                        > > > Our group adapted Scrum about 5 months ago in the middle of a
                        > > project
                        > > > that was failing. We since extended this to a couple other
                        > > projects
                        > > > that were failing and it has worked wonders and I have grown in
                        > > > experience leading some of these projects. What no one on our
                        > team
                        > > > has any experience with is STARTING a product release with
                        > Scrum.
                        > > >
                        > > > I read a recommendation several (hundred?) messages ago that
                        > > > advocated something like a planning sprint to bring teams into
                        > > > Scrum. Our team is already bought into Scrum, and would like
                        to
                        > > > evolve our design during many sprints with several Scrum teams
                        > > > working in parallel after which we will deliver our product.
                        > > > However, we are having a hard time telling management that we
                        > will
                        > > be
                        > > > able to deliver a product with XY&Z in it on date D, without
                        > first
                        > > > doing enough of a design analysis on the feature list to feel
                        > like
                        > > we
                        > > > really understand the complexities to give a solid estimate.
                        In
                        > > our
                        > > > industry, estimates are required because our business & our
                        > > customers
                        > > > need some planning to bring together many elements, of which
                        the
                        > > > software we will deliver is just one.
                        > > >
                        > > > I'm sure Scrum must be used places where these types of pre-
                        > project
                        > > > estimates must be given and contracted upon. What is done in
                        > this
                        > > > case? Is decomposing the user stories into what we feel are
                        > month-
                        > > > long product backlog bits in a planning sprint sufficient and
                        > > > recommended? Somehow I have a sinking feeling (clinging to my
                        > > false
                        > > > sense of security in waterfall) that this may just get me fired.
                        > > >
                        > > > Thanks so very much for any advice,
                        > > >
                        > > > Dan
                        > > >
                        > > >
                        > > >
                        > > >
                        > > > To Post a message, send it to: scrumdevelopment@e...
                        > > > To Unsubscribe, send a blank message to:
                        > > > scrumdevelopment-unsubscribe@e...
                        > > >
                        > > > Your use of Yahoo! Groups is subject to
                        > > http://docs.yahoo.com/info/terms/
                        > >
                        > >
                        > >
                        > > To Post a message, send it to: scrumdevelopment@e...
                        > > To Unsubscribe, send a blank message to:
                        > > scrumdevelopment-unsubscribe@e...
                        > >
                        > > Your use of Yahoo! Groups is subject to
                        > http://docs.yahoo.com/info/terms/
                        >
                        >
                        >
                        > To Post a message, send it to: scrumdevelopment@e...
                        > To Unsubscribe, send a blank message to:
                        > scrumdevelopment-unsubscribe@e...
                        >
                        > Your use of Yahoo! Groups is subject to
                        http://docs.yahoo.com/info/terms/
                      • Mike Cohn
                        Dan-- First, sorry for the greatly delayed response. I ve been buried and haven t had time to look at the chapter. Good point. I corrected the text (I d left
                        Message 11 of 13 , May 1 9:31 AM
                        • 0 Attachment
                          Dan--
                          First, sorry for the greatly delayed response. I've been buried and haven't
                          had time to look at the chapter. Good point. I corrected the text (I'd left
                          out a couple of words.)

                          No, I've never really tried averaging the numbers. I'll sometimes look at
                          both as a sanity check but I almost always use the square root of the sum of
                          the squared differences. There's more of a mathematical basis for that and
                          I've found that estimating is much easier when developers are given the
                          freedom to estimating stories and tasks in a range ("3-5 days"), just like
                          we'd like to be able to tell Product Owners a range ("4-6 sprints").

                          Thanks again for finding and pointing out my goof.

                          -Mike

                          -----Original Message-----
                          From: Dan Brown [mailto:kid_danomite@...]
                          Sent: Wednesday, April 16, 2003 11:30 PM
                          To: scrumdevelopment@yahoogroups.com
                          Subject: [scrumdevelopment] Re: Planning a product release

                          Mike & Ken:

                          Thanks! That makes a lot of sense, but it will take some practice to
                          decompose our stories into 3-4 day chunks instead of diving into the
                          design of a big task more quickly.

                          Mike - I hope the answer to the XXXXXXXX on c 7, p 48 comes out the
                          way you want it!

                          One final thing - I did notice a potential error on c9, p74, where
                          the text & the table are inconsistent about using the square root of
                          the sum of the squares (probably what you want) or the square root of
                          the sum. The other thing you may want to mention at the end of this
                          page (74) when comparing simple 50% buffers to square root sum of the
                          squares is that if you have a large number of tasks, the 50% buffer
                          grows much more quickly than the square root of the sum of squares
                          (i.e. for a very large program, this may represent very little
                          difference from the 50% case). Have you ever tried something like
                          taking the an average of the sum of the 50% & the sum of the 90% or
                          if you want to stick with the square of the difference approximating
                          the variance of the task you could even set confidence bounds on the
                          project by estimating the average of the sum(50%) & sum(90%) plus or
                          minus the square root of the sum of the squares of the differences.
                          This would have the added benefit of telling you if your confidence
                          bounds are, perhaps, longer than 1 Sprint-length.

                          Dan


                          --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                          wrote:
                          > John--
                          >
                          > The image on the page is from a simplified version of the
                          spreadsheet I was
                          > using at the time. There's a better version of the actual
                          spreadsheet at
                          > http://www.mountaingoatsoftware.com/resources.html. In that one
                          you'll see
                          > where I have columns for 50% and 90%. Developers have such an
                          easier time
                          > saying "that will take 4 or 5 days" instead of "that will take 4
                          days" that
                          > I have the team formalize what they mean by their low and high
                          estimates and
                          > then give both. Giving two estimates seems like twice the work of
                          giving one
                          > estimate but it's actually much easier. Even better--the two
                          estimates are
                          > more expressive so I can use them to size buffers early on.
                          >
                          > When a sprint is ongoing and we're tracking sprint backlog (as
                          shown at
                          > http://www.mountaingoatsoftware.com/scrum/sprintbacklog.html) we
                          just track
                          > a simple 50% estimate of the time left to completion. The work is
                          already in
                          > the sprint at that point so you don't have any real control over
                          the buffer
                          > (it's already sized) so there's no point in tracking 50% and 90%
                          numbers for
                          > items in the sprint backlog.
                          >
                          > I'm glad you enjoyed the user stories drafts. I'd appreciate any
                          specific
                          > feedback you have on it as I continue with it.
                          >
                          > --Mike
                          >
                          > -----Original Message-----
                          > From: gilmanj_2000 [mailto:jpgilman@m...]
                          > Sent: Wednesday, April 16, 2003 5:34 PM
                          > To: scrumdevelopment@yahoogroups.com
                          > Subject: [scrumdevelopment] Re: Planning a product release
                          >
                          > Mike, thanks for your response to Dan and I really enjoyed what
                          > you've written so far on your user stories book. Look forward to
                          > it's completion.
                          >
                          > Here is my question. I understand the importance of including a
                          > proper buffer in the project itself. But, when estimating work in
                          > the product backlog e.g.
                          > http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
                          > your individual estimates include a buffer based on your 50% and
                          90%
                          > task estimates? Or are these your 50% estimates?
                          >
                          > Thanks, John
                          >
                          > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                          > wrote:
                          > > Dan--
                          > > Dan--
                          > >
                          > > I've had a number of situations where I need to produce a
                          deadline
                          > I can
                          > > commit to but only have the beginnings of the requirements/tasks.
                          > Here's
                          > > what I do:
                          > >
                          > > I try to specify the requirements as XP user stories. I find
                          those
                          > to be the
                          > > best way to capture requirements for just about any agile
                          project.
                          > This way
                          > > they are not too small, not too big, but typically "just right"
                          for
                          > > estimating. Stories also avoid problems with task-estimating
                          where
                          > many of
                          > > the tasks are highly similar, which leads to a systematic error
                          in
                          > the
                          > > estimate (one mistake trickles through many estimates).
                          > >
                          > > For each story I estimate it at both 50% and 90% levels of
                          > confidence. My
                          > > 50% estimate is one I think I'll make half the time--if I coded
                          > that story
                          > > 20 times, 10 would finish ahead of this and 10 after. It has no
                          > padding in
                          > > it. The 90% estimate assumes the task is on the hard end of the
                          > > spectrum--it's not a "worst case" scenario because no one gets
                          run
                          > over by a
                          > > bus or anything like that in this estimate.
                          > >
                          > > My project schedule is then the sum of the 50% unbuffered
                          estimates
                          > plus
                          > > some buffer which is determined by looking at the differences
                          > between the
                          > > 50% and 90% estimates: take the square root of the sum of the
                          > differences
                          > > between each 50% and 90% estimate and that will give you a
                          > reasonable
                          > > project buffer. The approach is covered well in
                          Leach's "Critical
                          > Chain
                          > > Project Management."
                          > >
                          > > This gives me a buffered schedule that takes into account overall
                          > > uncertainty (but isn't as huge as one from adding all the
                          individual
                          > > uncertainty, which would be wrong). I then round it up into a
                          > number of
                          > > sprints. If the team is new to Scrum I may add one more sprint
                          > (month) to
                          > > the end and use that as a "stabilization sprint" meaning the team
                          > will need
                          > > that extra month to work out any last bugs.
                          > >
                          > > I've been very successful with this in estimating and committing
                          to
                          > projects
                          > > out about 9 months into the future. (I haven't failed with it at
                          > longer
                          > > ones; I've just been able to avoid longer commitments!)
                          > >
                          > > I realize I didn't have time to type in many details (it's a busy
                          > month!)
                          > > but I have written more about it on www.userstories.com if you're
                          > > interested. If so, go to http://www.userstories.com/download.php
                          > and take a
                          > > look at "Principles of Estimating," "Estimating User
                          Stories," "Why
                          > Plans Go
                          > > Wrong," and "Planning a Release."
                          > >
                          > > --Mike
                          > >
                          > > -----Original Message-----
                          > > From: Dan Brown [mailto:kid_danomite@y...]
                          > > Sent: Friday, April 11, 2003 9:56 PM
                          > > To: scrumdevelopment@yahoogroups.com
                          > > Subject: [scrumdevelopment] Planning a product release
                          > >
                          > > I could use some advice from the group.
                          > >
                          > > Our group adapted Scrum about 5 months ago in the middle of a
                          > project
                          > > that was failing. We since extended this to a couple other
                          > projects
                          > > that were failing and it has worked wonders and I have grown in
                          > > experience leading some of these projects. What no one on our
                          team
                          > > has any experience with is STARTING a product release with
                          Scrum.
                          > >
                          > > I read a recommendation several (hundred?) messages ago that
                          > > advocated something like a planning sprint to bring teams into
                          > > Scrum. Our team is already bought into Scrum, and would like to
                          > > evolve our design during many sprints with several Scrum teams
                          > > working in parallel after which we will deliver our product.
                          > > However, we are having a hard time telling management that we
                          will
                          > be
                          > > able to deliver a product with XY&Z in it on date D, without
                          first
                          > > doing enough of a design analysis on the feature list to feel
                          like
                          > we
                          > > really understand the complexities to give a solid estimate. In
                          > our
                          > > industry, estimates are required because our business & our
                          > customers
                          > > need some planning to bring together many elements, of which the
                          > > software we will deliver is just one.
                          > >
                          > > I'm sure Scrum must be used places where these types of pre-
                          project
                          > > estimates must be given and contracted upon. What is done in
                          this
                          > > case? Is decomposing the user stories into what we feel are
                          month-
                          > > long product backlog bits in a planning sprint sufficient and
                          > > recommended? Somehow I have a sinking feeling (clinging to my
                          > false
                          > > sense of security in waterfall) that this may just get me fired.
                          > >
                          > > Thanks so very much for any advice,
                          > >
                          > > Dan
                          > >
                          > >
                          > >
                          > >
                          > > To Post a message, send it to: scrumdevelopment@e...
                          > > To Unsubscribe, send a blank message to:
                          > > scrumdevelopment-unsubscribe@e...
                          > >
                          > > Your use of Yahoo! Groups is subject to
                          > http://docs.yahoo.com/info/terms/
                          >
                          >
                          >
                          > To Post a message, send it to: scrumdevelopment@e...
                          > To Unsubscribe, send a blank message to:
                          > scrumdevelopment-unsubscribe@e...
                          >
                          > Your use of Yahoo! Groups is subject to
                          http://docs.yahoo.com/info/terms/



                          To Post a message, send it to: scrumdevelopment@...
                          To Unsubscribe, send a blank message to:
                          scrumdevelopment-unsubscribe@...

                          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                        • Mike Beedle
                          ... From: Mike Cohn [mailto:mike@mountaingoatsoftware.com] ... Mike, Just to compare notes -- the numbers we use/like are substantially different. We typically
                          Message 12 of 13 , May 2 2:32 AM
                          • 0 Attachment
                            -----Original Message-----
                            From: Mike Cohn [mailto:mike@...]
                            > I've found that estimating is much easier when developers
                            > are given the freedom to estimating stories and tasks
                            > in a range ("3-5 days"), just like we'd like to be
                            > able to tell Product Owners a range ("4-6 sprints").

                            Mike,

                            Just to compare notes -- the numbers we use/like are
                            substantially different.

                            We typically don't have much restrictions on story size
                            i.e. entries in the Product Backlog, except that they
                            need to be contained within a Sprint (2+ weeks).

                            On the other hand, we prefer more granular tasks,
                            preferably 2-4 hrs, but ranging anywhere from 1/2 hr to
                            8 hrs. The idea with this granularity is that on
                            the average a Scrum team member can get on the average
                            4-5 tasks done per day, and feel comfortable
                            reporting estimates and progress at the Scrum meetings
                            _and_ delivering _visible_ daily chunks of functionality to
                            the Daily Build and/or automated test processes.

                            We use both story cards and task cards together
                            with spreadsheets and/or a variety of issue managers
                            to keep track of daily progress -- always measured
                            as time to completion and as of late, user acceptance
                            tests passed.

                            We typically have dozens if not hundreds of builds
                            per day but at least one build at the end of the day, the
                            "Daily Build", is published to stakeholders and/or
                            user acceptance people because we value people-to-
                            people, and people-to-software interactions. We
                            currently don't believe all user acceptance tests
                            can or should be automated despite the recent
                            interest in automated user acceptance:

                            http://www.fitnesse.org
                            http://fit.c2.com

                            These are very cool tools indeed but we still value
                            "people interactions" more over "processes and _tools".

                            Hm, where did I hear that before?

                            - Mike



                            -----Original Message-----
                            From: Dan Brown [mailto:kid_danomite@...]
                            Sent: Wednesday, April 16, 2003 11:30 PM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: [scrumdevelopment] Re: Planning a product release

                            Mike & Ken:

                            Thanks! That makes a lot of sense, but it will take some practice to
                            decompose our stories into 3-4 day chunks instead of diving into the
                            design of a big task more quickly.

                            Mike - I hope the answer to the XXXXXXXX on c 7, p 48 comes out the
                            way you want it!

                            One final thing - I did notice a potential error on c9, p74, where
                            the text & the table are inconsistent about using the square root of
                            the sum of the squares (probably what you want) or the square root of
                            the sum. The other thing you may want to mention at the end of this
                            page (74) when comparing simple 50% buffers to square root sum of the
                            squares is that if you have a large number of tasks, the 50% buffer
                            grows much more quickly than the square root of the sum of squares
                            (i.e. for a very large program, this may represent very little
                            difference from the 50% case). Have you ever tried something like
                            taking the an average of the sum of the 50% & the sum of the 90% or
                            if you want to stick with the square of the difference approximating
                            the variance of the task you could even set confidence bounds on the
                            project by estimating the average of the sum(50%) & sum(90%) plus or
                            minus the square root of the sum of the squares of the differences.
                            This would have the added benefit of telling you if your confidence
                            bounds are, perhaps, longer than 1 Sprint-length.

                            Dan


                            --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                            wrote:
                            > John--
                            >
                            > The image on the page is from a simplified version of the
                            spreadsheet I was
                            > using at the time. There's a better version of the actual
                            spreadsheet at
                            > http://www.mountaingoatsoftware.com/resources.html. In that one
                            you'll see
                            > where I have columns for 50% and 90%. Developers have such an
                            easier time
                            > saying "that will take 4 or 5 days" instead of "that will take 4
                            days" that
                            > I have the team formalize what they mean by their low and high
                            estimates and
                            > then give both. Giving two estimates seems like twice the work of
                            giving one
                            > estimate but it's actually much easier. Even better--the two
                            estimates are
                            > more expressive so I can use them to size buffers early on.
                            >
                            > When a sprint is ongoing and we're tracking sprint backlog (as
                            shown at
                            > http://www.mountaingoatsoftware.com/scrum/sprintbacklog.html) we
                            just track
                            > a simple 50% estimate of the time left to completion. The work is
                            already in
                            > the sprint at that point so you don't have any real control over
                            the buffer
                            > (it's already sized) so there's no point in tracking 50% and 90%
                            numbers for
                            > items in the sprint backlog.
                            >
                            > I'm glad you enjoyed the user stories drafts. I'd appreciate any
                            specific
                            > feedback you have on it as I continue with it.
                            >
                            > --Mike
                            >
                            > -----Original Message-----
                            > From: gilmanj_2000 [mailto:jpgilman@m...]
                            > Sent: Wednesday, April 16, 2003 5:34 PM
                            > To: scrumdevelopment@yahoogroups.com
                            > Subject: [scrumdevelopment] Re: Planning a product release
                            >
                            > Mike, thanks for your response to Dan and I really enjoyed what
                            > you've written so far on your user stories book. Look forward to
                            > it's completion.
                            >
                            > Here is my question. I understand the importance of including a
                            > proper buffer in the project itself. But, when estimating work in
                            > the product backlog e.g.
                            > http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
                            > your individual estimates include a buffer based on your 50% and
                            90%
                            > task estimates? Or are these your 50% estimates?
                            >
                            > Thanks, John
                            >
                            > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                            > wrote:
                            > > Dan--
                            > > Dan--
                            > >
                            > > I've had a number of situations where I need to produce a
                            deadline
                            > I can
                            > > commit to but only have the beginnings of the requirements/tasks.
                            > Here's
                            > > what I do:
                            > >
                            > > I try to specify the requirements as XP user stories. I find
                            those
                            > to be the
                            > > best way to capture requirements for just about any agile
                            project.
                            > This way
                            > > they are not too small, not too big, but typically "just right"
                            for
                            > > estimating. Stories also avoid problems with task-estimating
                            where
                            > many of
                            > > the tasks are highly similar, which leads to a systematic error
                            in
                            > the
                            > > estimate (one mistake trickles through many estimates).
                            > >
                            > > For each story I estimate it at both 50% and 90% levels of
                            > confidence. My
                            > > 50% estimate is one I think I'll make half the time--if I coded
                            > that story
                            > > 20 times, 10 would finish ahead of this and 10 after. It has no
                            > padding in
                            > > it. The 90% estimate assumes the task is on the hard end of the
                            > > spectrum--it's not a "worst case" scenario because no one gets
                            run
                            > over by a
                            > > bus or anything like that in this estimate.
                            > >
                            > > My project schedule is then the sum of the 50% unbuffered
                            estimates
                            > plus
                            > > some buffer which is determined by looking at the differences
                            > between the
                            > > 50% and 90% estimates: take the square root of the sum of the
                            > differences
                            > > between each 50% and 90% estimate and that will give you a
                            > reasonable
                            > > project buffer. The approach is covered well in
                            Leach's "Critical
                            > Chain
                            > > Project Management."
                            > >
                            > > This gives me a buffered schedule that takes into account overall
                            > > uncertainty (but isn't as huge as one from adding all the
                            individual
                            > > uncertainty, which would be wrong). I then round it up into a
                            > number of
                            > > sprints. If the team is new to Scrum I may add one more sprint
                            > (month) to
                            > > the end and use that as a "stabilization sprint" meaning the team
                            > will need
                            > > that extra month to work out any last bugs.
                            > >
                            > > I've been very successful with this in estimating and committing
                            to
                            > projects
                            > > out about 9 months into the future. (I haven't failed with it at
                            > longer
                            > > ones; I've just been able to avoid longer commitments!)
                            > >
                            > > I realize I didn't have time to type in many details (it's a busy
                            > month!)
                            > > but I have written more about it on www.userstories.com if you're
                            > > interested. If so, go to http://www.userstories.com/download.php
                            > and take a
                            > > look at "Principles of Estimating," "Estimating User
                            Stories," "Why
                            > Plans Go
                            > > Wrong," and "Planning a Release."
                            > >
                            > > --Mike
                            > >
                            > > -----Original Message-----
                            > > From: Dan Brown [mailto:kid_danomite@y...]
                            > > Sent: Friday, April 11, 2003 9:56 PM
                            > > To: scrumdevelopment@yahoogroups.com
                            > > Subject: [scrumdevelopment] Planning a product release
                            > >
                            > > I could use some advice from the group.
                            > >
                            > > Our group adapted Scrum about 5 months ago in the middle of a
                            > project
                            > > that was failing. We since extended this to a couple other
                            > projects
                            > > that were failing and it has worked wonders and I have grown in
                            > > experience leading some of these projects. What no one on our
                            team
                            > > has any experience with is STARTING a product release with
                            Scrum.
                            > >
                            > > I read a recommendation several (hundred?) messages ago that
                            > > advocated something like a planning sprint to bring teams into
                            > > Scrum. Our team is already bought into Scrum, and would like to
                            > > evolve our design during many sprints with several Scrum teams
                            > > working in parallel after which we will deliver our product.
                            > > However, we are having a hard time telling management that we
                            will
                            > be
                            > > able to deliver a product with XY&Z in it on date D, without
                            first
                            > > doing enough of a design analysis on the feature list to feel
                            like
                            > we
                            > > really understand the complexities to give a solid estimate. In
                            > our
                            > > industry, estimates are required because our business & our
                            > customers
                            > > need some planning to bring together many elements, of which the
                            > > software we will deliver is just one.
                            > >
                            > > I'm sure Scrum must be used places where these types of pre-
                            project
                            > > estimates must be given and contracted upon. What is done in
                            this
                            > > case? Is decomposing the user stories into what we feel are
                            month-
                            > > long product backlog bits in a planning sprint sufficient and
                            > > recommended? Somehow I have a sinking feeling (clinging to my
                            > false
                            > > sense of security in waterfall) that this may just get me fired.
                            > >
                            > > Thanks so very much for any advice,
                            > >
                            > > Dan
                            > >
                            > >
                            > >
                            > >
                            > > To Post a message, send it to: scrumdevelopment@e...
                            > > To Unsubscribe, send a blank message to:
                            > > scrumdevelopment-unsubscribe@e...
                            > >
                            > > Your use of Yahoo! Groups is subject to
                            > http://docs.yahoo.com/info/terms/
                            >
                            >
                            >
                            > To Post a message, send it to: scrumdevelopment@e...
                            > To Unsubscribe, send a blank message to:
                            > scrumdevelopment-unsubscribe@e...
                            >
                            > Your use of Yahoo! Groups is subject to
                            http://docs.yahoo.com/info/terms/



                            To Post a message, send it to: scrumdevelopment@...
                            To Unsubscribe, send a blank message to:
                            scrumdevelopment-unsubscribe@...

                            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




                            Yahoo! Groups Sponsor



                            To Post a message, send it to: scrumdevelopment@...
                            To Unsubscribe, send a blank message to:
                            scrumdevelopment-unsubscribe@...

                            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                          • Mike Cohn
                            I was referring to the estimating we do based on the very preliminary user stories in the product backlog. At that time we don t have enough detail to break
                            Message 13 of 13 , May 2 9:46 AM
                            • 0 Attachment
                              I was referring to the estimating we do based on the very preliminary user
                              stories in the product backlog. At that time we don't have enough detail to
                              break things down into 2-8 hour tasks. But, you're right, things need to be
                              much more granular when planning the work within a given sprint. Within a
                              sprint my approach seems consistent with yours.

                              --Mike

                              -----Original Message-----
                              From: Mike Beedle [mailto:beedlem@...]
                              Sent: Friday, May 02, 2003 3:33 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: RE: [scrumdevelopment] Re: Planning a product release



                              -----Original Message-----
                              From: Mike Cohn [mailto:mike@...]
                              > I've found that estimating is much easier when developers
                              > are given the freedom to estimating stories and tasks
                              > in a range ("3-5 days"), just like we'd like to be
                              > able to tell Product Owners a range ("4-6 sprints").

                              Mike,

                              Just to compare notes -- the numbers we use/like are
                              substantially different.

                              We typically don't have much restrictions on story size
                              i.e. entries in the Product Backlog, except that they
                              need to be contained within a Sprint (2+ weeks).

                              On the other hand, we prefer more granular tasks,
                              preferably 2-4 hrs, but ranging anywhere from 1/2 hr to
                              8 hrs. The idea with this granularity is that on
                              the average a Scrum team member can get on the average
                              4-5 tasks done per day, and feel comfortable
                              reporting estimates and progress at the Scrum meetings
                              _and_ delivering _visible_ daily chunks of functionality to
                              the Daily Build and/or automated test processes.

                              We use both story cards and task cards together
                              with spreadsheets and/or a variety of issue managers
                              to keep track of daily progress -- always measured
                              as time to completion and as of late, user acceptance
                              tests passed.

                              We typically have dozens if not hundreds of builds
                              per day but at least one build at the end of the day, the
                              "Daily Build", is published to stakeholders and/or
                              user acceptance people because we value people-to-
                              people, and people-to-software interactions. We
                              currently don't believe all user acceptance tests
                              can or should be automated despite the recent
                              interest in automated user acceptance:

                              http://www.fitnesse.org
                              http://fit.c2.com

                              These are very cool tools indeed but we still value
                              "people interactions" more over "processes and _tools".

                              Hm, where did I hear that before?

                              - Mike



                              -----Original Message-----
                              From: Dan Brown [mailto:kid_danomite@...]
                              Sent: Wednesday, April 16, 2003 11:30 PM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: [scrumdevelopment] Re: Planning a product release

                              Mike & Ken:

                              Thanks! That makes a lot of sense, but it will take some practice to
                              decompose our stories into 3-4 day chunks instead of diving into the
                              design of a big task more quickly.

                              Mike - I hope the answer to the XXXXXXXX on c 7, p 48 comes out the
                              way you want it!

                              One final thing - I did notice a potential error on c9, p74, where
                              the text & the table are inconsistent about using the square root of
                              the sum of the squares (probably what you want) or the square root of
                              the sum. The other thing you may want to mention at the end of this
                              page (74) when comparing simple 50% buffers to square root sum of the
                              squares is that if you have a large number of tasks, the 50% buffer
                              grows much more quickly than the square root of the sum of squares
                              (i.e. for a very large program, this may represent very little
                              difference from the 50% case). Have you ever tried something like
                              taking the an average of the sum of the 50% & the sum of the 90% or
                              if you want to stick with the square of the difference approximating
                              the variance of the task you could even set confidence bounds on the
                              project by estimating the average of the sum(50%) & sum(90%) plus or
                              minus the square root of the sum of the squares of the differences.
                              This would have the added benefit of telling you if your confidence
                              bounds are, perhaps, longer than 1 Sprint-length.

                              Dan


                              --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                              wrote:
                              > John--
                              >
                              > The image on the page is from a simplified version of the
                              spreadsheet I was
                              > using at the time. There's a better version of the actual
                              spreadsheet at
                              > http://www.mountaingoatsoftware.com/resources.html. In that one
                              you'll see
                              > where I have columns for 50% and 90%. Developers have such an
                              easier time
                              > saying "that will take 4 or 5 days" instead of "that will take 4
                              days" that
                              > I have the team formalize what they mean by their low and high
                              estimates and
                              > then give both. Giving two estimates seems like twice the work of
                              giving one
                              > estimate but it's actually much easier. Even better--the two
                              estimates are
                              > more expressive so I can use them to size buffers early on.
                              >
                              > When a sprint is ongoing and we're tracking sprint backlog (as
                              shown at
                              > http://www.mountaingoatsoftware.com/scrum/sprintbacklog.html) we
                              just track
                              > a simple 50% estimate of the time left to completion. The work is
                              already in
                              > the sprint at that point so you don't have any real control over
                              the buffer
                              > (it's already sized) so there's no point in tracking 50% and 90%
                              numbers for
                              > items in the sprint backlog.
                              >
                              > I'm glad you enjoyed the user stories drafts. I'd appreciate any
                              specific
                              > feedback you have on it as I continue with it.
                              >
                              > --Mike
                              >
                              > -----Original Message-----
                              > From: gilmanj_2000 [mailto:jpgilman@m...]
                              > Sent: Wednesday, April 16, 2003 5:34 PM
                              > To: scrumdevelopment@yahoogroups.com
                              > Subject: [scrumdevelopment] Re: Planning a product release
                              >
                              > Mike, thanks for your response to Dan and I really enjoyed what
                              > you've written so far on your user stories book. Look forward to
                              > it's completion.
                              >
                              > Here is my question. I understand the importance of including a
                              > proper buffer in the project itself. But, when estimating work in
                              > the product backlog e.g.
                              > http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
                              > your individual estimates include a buffer based on your 50% and
                              90%
                              > task estimates? Or are these your 50% estimates?
                              >
                              > Thanks, John
                              >
                              > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
                              > wrote:
                              > > Dan--
                              > > Dan--
                              > >
                              > > I've had a number of situations where I need to produce a
                              deadline
                              > I can
                              > > commit to but only have the beginnings of the requirements/tasks.
                              > Here's
                              > > what I do:
                              > >
                              > > I try to specify the requirements as XP user stories. I find
                              those
                              > to be the
                              > > best way to capture requirements for just about any agile
                              project.
                              > This way
                              > > they are not too small, not too big, but typically "just right"
                              for
                              > > estimating. Stories also avoid problems with task-estimating
                              where
                              > many of
                              > > the tasks are highly similar, which leads to a systematic error
                              in
                              > the
                              > > estimate (one mistake trickles through many estimates).
                              > >
                              > > For each story I estimate it at both 50% and 90% levels of
                              > confidence. My
                              > > 50% estimate is one I think I'll make half the time--if I coded
                              > that story
                              > > 20 times, 10 would finish ahead of this and 10 after. It has no
                              > padding in
                              > > it. The 90% estimate assumes the task is on the hard end of the
                              > > spectrum--it's not a "worst case" scenario because no one gets
                              run
                              > over by a
                              > > bus or anything like that in this estimate.
                              > >
                              > > My project schedule is then the sum of the 50% unbuffered
                              estimates
                              > plus
                              > > some buffer which is determined by looking at the differences
                              > between the
                              > > 50% and 90% estimates: take the square root of the sum of the
                              > differences
                              > > between each 50% and 90% estimate and that will give you a
                              > reasonable
                              > > project buffer. The approach is covered well in
                              Leach's "Critical
                              > Chain
                              > > Project Management."
                              > >
                              > > This gives me a buffered schedule that takes into account overall
                              > > uncertainty (but isn't as huge as one from adding all the
                              individual
                              > > uncertainty, which would be wrong). I then round it up into a
                              > number of
                              > > sprints. If the team is new to Scrum I may add one more sprint
                              > (month) to
                              > > the end and use that as a "stabilization sprint" meaning the team
                              > will need
                              > > that extra month to work out any last bugs.
                              > >
                              > > I've been very successful with this in estimating and committing
                              to
                              > projects
                              > > out about 9 months into the future. (I haven't failed with it at
                              > longer
                              > > ones; I've just been able to avoid longer commitments!)
                              > >
                              > > I realize I didn't have time to type in many details (it's a busy
                              > month!)
                              > > but I have written more about it on www.userstories.com if you're
                              > > interested. If so, go to http://www.userstories.com/download.php
                              > and take a
                              > > look at "Principles of Estimating," "Estimating User
                              Stories," "Why
                              > Plans Go
                              > > Wrong," and "Planning a Release."
                              > >
                              > > --Mike
                              > >
                              > > -----Original Message-----
                              > > From: Dan Brown [mailto:kid_danomite@y...]
                              > > Sent: Friday, April 11, 2003 9:56 PM
                              > > To: scrumdevelopment@yahoogroups.com
                              > > Subject: [scrumdevelopment] Planning a product release
                              > >
                              > > I could use some advice from the group.
                              > >
                              > > Our group adapted Scrum about 5 months ago in the middle of a
                              > project
                              > > that was failing. We since extended this to a couple other
                              > projects
                              > > that were failing and it has worked wonders and I have grown in
                              > > experience leading some of these projects. What no one on our
                              team
                              > > has any experience with is STARTING a product release with
                              Scrum.
                              > >
                              > > I read a recommendation several (hundred?) messages ago that
                              > > advocated something like a planning sprint to bring teams into
                              > > Scrum. Our team is already bought into Scrum, and would like to
                              > > evolve our design during many sprints with several Scrum teams
                              > > working in parallel after which we will deliver our product.
                              > > However, we are having a hard time telling management that we
                              will
                              > be
                              > > able to deliver a product with XY&Z in it on date D, without
                              first
                              > > doing enough of a design analysis on the feature list to feel
                              like
                              > we
                              > > really understand the complexities to give a solid estimate. In
                              > our
                              > > industry, estimates are required because our business & our
                              > customers
                              > > need some planning to bring together many elements, of which the
                              > > software we will deliver is just one.
                              > >
                              > > I'm sure Scrum must be used places where these types of pre-
                              project
                              > > estimates must be given and contracted upon. What is done in
                              this
                              > > case? Is decomposing the user stories into what we feel are
                              month-
                              > > long product backlog bits in a planning sprint sufficient and
                              > > recommended? Somehow I have a sinking feeling (clinging to my
                              > false
                              > > sense of security in waterfall) that this may just get me fired.
                              > >
                              > > Thanks so very much for any advice,
                              > >
                              > > Dan
                              > >
                              > >
                              > >
                              > >
                              > > To Post a message, send it to: scrumdevelopment@e...
                              > > To Unsubscribe, send a blank message to:
                              > > scrumdevelopment-unsubscribe@e...
                              > >
                              > > Your use of Yahoo! Groups is subject to
                              > http://docs.yahoo.com/info/terms/
                              >
                              >
                              >
                              > To Post a message, send it to: scrumdevelopment@e...
                              > To Unsubscribe, send a blank message to:
                              > scrumdevelopment-unsubscribe@e...
                              >
                              > Your use of Yahoo! Groups is subject to
                              http://docs.yahoo.com/info/terms/



                              To Post a message, send it to: scrumdevelopment@...
                              To Unsubscribe, send a blank message to:
                              scrumdevelopment-unsubscribe@...

                              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




                              Yahoo! Groups Sponsor



                              To Post a message, send it to: scrumdevelopment@...
                              To Unsubscribe, send a blank message to:
                              scrumdevelopment-unsubscribe@...

                              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


                              To Post a message, send it to: scrumdevelopment@...
                              To Unsubscribe, send a blank message to:
                              scrumdevelopment-unsubscribe@...

                              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                            Your message has been successfully submitted and would be delivered to recipients shortly.