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

Scheduling buffers

Expand Messages
  • Peter Stevens (calendar)
    Hi everyone, In Mike Cohn s Agile Planning and Estimating books, he writes about using 50% estimates (50/50 chance that the story will be finished in time
    Message 1 of 21 , Apr 16, 2009
    • 0 Attachment
      Hi everyone,

      In Mike Cohn's Agile Planning and Estimating books, he writes about
      using 50% estimates (50/50 chance that the story will be finished in
      time <= estimate) and 90% estimates (90% that t <= e ). He goes further
      to calculate a project buffer, based on the square root of the sum of
      the squares of the differences between e(50) and e(90). (page 195 for
      someone want to look up the reference).

      Does anyone out there use these techniques to estimate the actual
      completion time of a project? What experience have you had with them?

      Thanks in advance,

      Peter

      --
      Peter Stevens, CSM, CSP
      http://tinyurl.com/Scrum-In-House-Training
      http://scrum-breakfast.com
      tel: +41 44 586 6450
    • Ron Jeffries
      ... I do not. On most projects we already know what deadline is wanted. It is the job of the Product Owner to hit that date with the best possible combination
      Message 2 of 21 , Apr 17, 2009
      • 0 Attachment
        Hello, Peter. On Friday, April 17, 2009, at 2:46:33 AM, you wrote:

        > Does anyone out there use these techniques to estimate the actual
        > completion time of a project? What experience have you had with them?

        I do not. On most projects we already know what deadline is wanted.
        It is the job of the Product Owner to hit that date with the best
        possible combination of features. The best way I know to do that is
        to do multiple thin slices across the necessary epics, making first
        a "walking skeleton" of the product, and then filling it in as best
        one can.

        To get a rough look at how much we'll get done, I'd look at a burnup
        chart, which would show the count of features likely to be done. I'd
        add error bars in number of features my eyeball. It's possible that
        in my mind I'd be doing something like the 50-90 split.

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        If you're not throwing some gravel once in a while,
        you're not using the whole road.
      • Ilja Preuß
        ... If I remember my statistics correctly, e(100) = infinity. With other words, there is no way to have an actual (guaranteed) completion time. All you can do
        Message 3 of 21 , Apr 17, 2009
        • 0 Attachment
          2009/4/17 Peter Stevens (calendar) <peterstev@...>:
          > Hi everyone,
          >
          > In Mike Cohn's Agile Planning and Estimating books, he writes about
          > using 50% estimates (50/50 chance that the story will be finished in
          > time <= estimate) and 90% estimates (90% that t <= e ). He goes further
          > to calculate a project buffer, based on the square root of the sum of
          > the squares of the differences between e(50) and e(90). (page 195 for
          > someone want to look up the reference).
          >
          > Does anyone out there use these techniques to estimate the actual
          > completion time of a project? What experience have you had with them?

          If I remember my statistics correctly, e(100) = infinity. With other
          words, there is no way to have an actual (guaranteed) completion time.
          All you can do is increase the probability of actually being finished
          by moving the date further into the future - that is, use e(99),
          e(99.9) etc. pp.

          Cheers, Ilja
        • davenicolette
          Hi Peter, I ve used similar techniques for projecting likely completion dates, but not for estimating the actual (?) completion date. I usually push it out
          Message 4 of 21 , Apr 17, 2009
          • 0 Attachment
            Hi Peter,

            I've used similar techniques for projecting likely completion dates, but not for "estimating the actual" (?) completion date. I usually push it out one standard deviation from the point you're labeling as e(50) and call that a reasonable projection for general planning purposes, but I also give a range of dates from best case to worst case.

            (BTW, I don't mean "worst case" in the sense of "never" - I think someone posted something whimsical about e(100) earlier in the thread. In my experience, once you've delivered 90% or more of the scope - and often far less than that - the customer decides they've obtained all the value they really need and they'd rather not pay for development of the remaining "nice to have" features, anyway. To me, this is another reason not to worry excessively about guessing the exact completion date. You just can't know what's going to happen between now and then.)

            IMHO whether this approach is relevant depends on how you're managing the Iron Triangle on the particular project. When scope has to be fixed and you need to try and determine when it's likely to be completed, you might use this sort of approach. For example, I worked on a project to rewrite an application that involves hardware installation at thousands of locations in several countries. To plan the rollout, the company needed at least a general idea of when to start various procedures to order hardware, obtain local government approvals, and make arrangements with unionized contractors to install wiring and so forth. Incremental delivery of the software was done to a staging environment and not all the way to production, for logistical reasons and also because it would have been largely meaningless to deploy just a portion of the replacement application to the field. So in that case, scope was fixed and we needed to know the approximate delivery date. The 50/90 percent estimation approach was a good fit for that situation.

            The more general case for agile projects is to fix the delivery date and vary the scope to fit within the available time. I don't think the 50/90 estimation approach is useful in those cases. Instead, I'd go with a technique like the ones elaborated by Jeff Patton, Koen Van Exem, and Dean Leffingwell (each using his own terminology) in which you collaborate with the customer to identify the most critical bits of the solution and deliver those first. If you have some observations of the team's velocity, you can get a pretty good idea of approximately how many iterations it will take them to deliver the results for the initial release. I think that works better than time-based estimation in these cases.

            I worked on a project last year that was managed in that way. We were able to deliver on an aggressive schedule by just delivering the most critical features in the first release, and then filled in the gaps in subsequent releases. We didn't use the time-based estimation technique you mention to handle that situation. We projected forward based on observed velocity, using adjustment factors like the ones you learn about in CSM classes for the first couple of iterations, since we didn't have enough data points for a straight projection until the end of iteration 3. It worked quite well in that situation. There's an example here http://davenicolette.wikispaces.com/Agile+Metrics. Download the zip file for "version 4" of the workshop, and it's in one of the spreadsheets.

            I hope that helps.

            Cheers,
            Dave

            --- In scrumdevelopment@yahoogroups.com, "Peter Stevens (calendar)" <peterstev@...> wrote:
            >
            > Hi everyone,
            >
            > In Mike Cohn's Agile Planning and Estimating books, he writes about
            > using 50% estimates (50/50 chance that the story will be finished in
            > time <= estimate) and 90% estimates (90% that t <= e ). He goes further
            > to calculate a project buffer, based on the square root of the sum of
            > the squares of the differences between e(50) and e(90). (page 195 for
            > someone want to look up the reference).
            >
            > Does anyone out there use these techniques to estimate the actual
            > completion time of a project? What experience have you had with them?
            >
            > Thanks in advance,
            >
            > Peter
            >
            > --
            > Peter Stevens, CSM, CSP
            > http://tinyurl.com/Scrum-In-House-Training
            > http://scrum-breakfast.com
            > tel: +41 44 586 6450
            >
          • Peter Stevens (calendar)
            Hi Ilja, I agree with your definition of e(100). How often have you experienced it? Mike is trying to find an estimate where he has 90% certainty that the
            Message 5 of 21 , Apr 17, 2009
            • 0 Attachment
              Hi Ilja,

              I agree with your definition of e(100). How often have you experienced it?

              Mike is trying to find an estimate where he has 90% certainty that the *project* will be finished at or before the quoted time. Obviously there is no certainty. And summing up a large number of e(100)'s doesn't really help.

              So the question remains, if you have to achieve a date or a price, how do you do so? The answer is obviously non-trivial, and getting a good estimate is only part of the solution.

              As a vendor selling development services, I think this kind of mathematical analysis is useful for understanding my negotiating position. How much risk is there in the estimates my team has given me?

              I'm thinking a simpler version might work nearly as well:
              • Estimate each story on the Cohn scale: 1, 2, 3, 5, 8...
              • Planning poker produces one number, say a 5 - that average case
              • Worst case e(90) is therefore an 8 (the next point on the cohn scale, an overshoot of 50 to 60% )
              • Sum the teams estimate, sum the square of the deltas between e(90)-e(50) )
              • The square root is you buffer, add to the sum of the e(50)'s to get you project worst case estimate.
              Turns out, if you estimate a lot of little stories, the buffer is smaller than if you estimate a small number of big stories. Not too surprising, I suppose...

              Cheers,

              Peter

              Ilja Preuß wrote:

              2009/4/17 Peter Stevens (calendar) <peterstev@gmail. com>:
              > Hi everyone,
              >
              > In Mike Cohn's Agile Planning and Estimating books, he writes about
              > using 50% estimates (50/50 chance that the story will be finished in
              > time <= estimate) and 90% estimates (90% that t <= e ). He goes further
              > to calculate a project buffer, based on the square root of the sum of
              > the squares of the differences between e(50) and e(90). (page 195 for
              > someone want to look up the reference).
              >
              > Does anyone out there use these techniques to estimate the actual
              > completion time of a project? What experience have you had with them?

              If I remember my statistics correctly, e(100) = infinity. With other
              words, there is no way to have an actual (guaranteed) completion time.
              All you can do is increase the probability of actually being finished
              by moving the date further into the future - that is, use e(99),
              e(99.9) etc. pp.

              Cheers, Ilja



              -- 
              Peter Stevens, CSM, CSP
              http://tinyurl.com/Scrum-In-House-Training
              http://scrum-breakfast.com
              tel: +41 44 586 6450
              
            • Peter Stevens (calendar)
              Hi Ron, I like the name walking skeleton . I think satisfying the real customer (i.e the sponsors of the project) and the purchasing department (who are
              Message 6 of 21 , Apr 17, 2009
              • 0 Attachment
                Hi Ron,

                I like the name 'walking skeleton'. I think satisfying the real customer (i.e the sponsors of the project) and the purchasing department (who are mostly involved in the bidding phase) are two different things.

                My experience has actually been similar to yours:
                1. create a wish list
                2. estimate & price the wish list
                3. haggle over price and scope (which usually produces a reduction of both)
                4. start implementation
                5. get the most important features done (a minimum marketable feature set)
                6. add subsequent features until budget and/or time are exhausted
                7. along the way, P-O & team work closely together to get the best business value for the available time & money
                If the P-O has prioritized well, the customer will be happy,.

                Cheers,

                Peter

                Ron Jeffries wrote:

                Hello, Peter. On Friday, April 17, 2009, at 2:46:33 AM, you wrote:

                > Does anyone out there use these techniques to estimate the actual
                > completion time of a project? What experience have you had with them?

                I do not. On most projects we already know what deadline is wanted.
                It is the job of the Product Owner to hit that date with the best
                possible combination of features. The best way I know to do that is
                to do multiple thin slices across the necessary epics, making first
                a "walking skeleton" of the product, and then filling it in as best
                one can.

                To get a rough look at how much we'll get done, I'd look at a burnup
                chart, which would show the count of features likely to be done. I'd
                add error bars in number of features my eyeball. It's possible that
                in my mind I'd be doing something like the 50-90 split.

                Ron Jeffries
                www.XProgramming. com
                www.xprogramming. com/blog
                If you're not throwing some gravel once in a while,
                you're not using the whole road.



                -- 
                Peter Stevens, CSM, CSP
                http://tinyurl.com/Scrum-In-House-Training
                http://scrum-breakfast.com
                tel: +41 44 586 6450
                
              • Gerard Meszaros
                Peter Stevens (calendar) wrote: I m thinking a simpler version might work nearly as well: Estimate each story on the Cohn scale: 1, 2, 3, 5, 8... Planning
                Message 7 of 21 , Apr 17, 2009
                • 0 Attachment
                  Peter Stevens (calendar) wrote:
                  I'm thinking a simpler version might work nearly as well:
                  • Estimate each story on the Cohn scale: 1, 2, 3, 5, 8...
                  • Planning poker produces one number, say a 5 - that average case
                  • Worst case e(90) is therefore an 8 (the next point on the cohn scale, an overshoot of 50 to 60% )
                  • Sum the teams estimate, sum the square of the deltas between e(90)-e(50) )
                  • The square root is you buffer, add to the sum of the e(50)'s to get you project worst case estimate.
                  Turns out, if you estimate a lot of little stories, the buffer is smaller than if you estimate a small number of big stories. Not too surprising, I suppose...
                  True, but we rarely have the stories broken down to this level when the budget is being set and even if we do, we rarely have all of them. So no matter what we do, we end up managing scope (at the individual story level) to make the dates that were committed based on the original guesstimates of what would be needed and how much effort it would take to build. I'm not saying that is a bad thing, though, just that we need to be careful not to delude ourselves into thinking we can get anything resembling an accurate projection (a.k.a. estimate) of the completion date given fixed scope. Which is why the ever-more-fleshy walking skeleton is the safest way to ensure the customer/PO doesn't get P.O.ed at us.

                  Gerard

                  -- 
                  Gerard Meszaros
                  Lean/Agile Coach/Mentor/Trainer
                  http://www.gerardmeszaros.com 
                  1-403-827-2967
                  
                  Author of the Jolt Productivity Award winning book "xUnit Test Patterns - Refactoring Test Code". Learn more at http://xunitpatterns.com/index.html
                  
                  
                  
                  
                • Peter Stevens (calendar)
                  Hi Dave, ... Your phrasing is definitely better than mine! Thanks! It s interesting that you talk about the iron triangle. I prefer to to think of it as having
                  Message 8 of 21 , Apr 17, 2009
                  • 0 Attachment
                    Hi Dave,

                    > likely completion date vs. estimated actual completion date.

                    Your phrasing is definitely better than mine! Thanks!

                    It's interesting that you talk about the iron triangle. I prefer to to think of it as having four points, which makes it a square or a cross, depending on how you connect the dots. Quality is the fourth point. I believe that not accumulating technical debt is one of the keys to hitting a goal reliably. If you have to do hardening or test phases (which may discover design or requirements defects) you may have a long period of zero velocity in front of you.

                    Right now, I am looking at the problem from the perspective of a "salesman" (who may well be a consultant or project leader in real life) who is selling a project to a customer who may or may not know or care about agile. Either cost ceilings or fixed price and scope show up frequently in this context. For example, public sector projects (at least in Switzeland) require a cost ceiling by law.

                    So the problem is two fold:
                    1. before the sale, come up with a good estimate of the time, effort and risk of the project - which will determine the negotiating position of the salesman - what should be fixed price be, how low can s/he bid and still be reasonably assured of a profitable project.
                    2. after the sale, how to guide the project to a successful conclusion, staying in the limits set by the contract.
                    A closely related topic is how to manage the competitive game that arises out of a fixed price project - the customer wants more, the vendor wants to do less.

                    I am working my way through your presentation on metrics - if you ever come to Switzerland, I'd love to have you present it at a Scrum Breakfast! Re: Jeff Patten et al: Is there work documented on the net anywhere?

                    Cheers,

                    Peter


                    davenicolette wrote:

                    Hi Peter,

                    I've used similar techniques for projecting likely completion dates, but not for "estimating the actual" (?) completion date. I usually push it out one standard deviation from the point you're labeling as e(50) and call that a reasonable projection for general planning purposes, but I also give a range of dates from best case to worst case.

                    (BTW, I don't mean "worst case" in the sense of "never" - I think someone posted something whimsical about e(100) earlier in the thread. In my experience, once you've delivered 90% or more of the scope - and often far less than that - the customer decides they've obtained all the value they really need and they'd rather not pay for development of the remaining "nice to have" features, anyway. To me, this is another reason not to worry excessively about guessing the exact completion date. You just can't know what's going to happen between now and then.)

                    IMHO whether this approach is relevant depends on how you're managing the Iron Triangle on the particular project. When scope has to be fixed and you need to try and determine when it's likely to be completed, you might use this sort of approach. For example, I worked on a project to rewrite an application that involves hardware installation at thousands of locations in several countries. To plan the rollout, the company needed at least a general idea of when to start various procedures to order hardware, obtain local government approvals, and make arrangements with unionized contractors to install wiring and so forth. Incremental delivery of the software was done to a staging environment and not all the way to production, for logistical reasons and also because it would have been largely meaningless to deploy just a portion of the replacement application to the field. So in that case, scope was fixed and we needed to know the approximate delivery date. The 50/90 percent estimation approach was a good fit for that situation.

                    The more general case for agile projects is to fix the delivery date and vary the scope to fit within the available time. I don't think the 50/90 estimation approach is useful in those cases. Instead, I'd go with a technique like the ones elaborated by Jeff Patton, Koen Van Exem, and Dean Leffingwell (each using his own terminology) in which you collaborate with the customer to identify the most critical bits of the solution and deliver those first. If you have some observations of the team's velocity, you can get a pretty good idea of approximately how many iterations it will take them to deliver the results for the initial release. I think that works better than time-based estimation in these cases.

                    I worked on a project last year that was managed in that way. We were able to deliver on an aggressive schedule by just delivering the most critical features in the first release, and then filled in the gaps in subsequent releases. We didn't use the time-based estimation technique you mention to handle that situation. We projected forward based on observed velocity, using adjustment factors like the ones you learn about in CSM classes for the first couple of iterations, since we didn't have enough data points for a straight projection until the end of iteration 3. It worked quite well in that situation. There's an example here http://davenicolett e.wikispaces. com/Agile+ Metrics. Download the zip file for "version 4" of the workshop, and it's in one of the spreadsheets.

                    I hope that helps.

                    Cheers,
                    Dave

                    --- In scrumdevelopment@ yahoogroups. com, "Peter Stevens (calendar)" <peterstev@. ..> wrote:
                    >
                    > Hi everyone,
                    >
                    > In Mike Cohn's Agile Planning and Estimating books, he writes about
                    > using 50% estimates (50/50 chance that the story will be finished in
                    > time <= estimate) and 90% estimates (90% that t <= e ). He goes further
                    > to calculate a project buffer, based on the square root of the sum of
                    > the squares of the differences between e(50) and e(90). (page 195 for
                    > someone want to look up the reference).
                    >
                    > Does anyone out there use these techniques to estimate the actual
                    > completion time of a project? What experience have you had with them?
                    >
                    > Thanks in advance,
                    >
                    > Peter
                    >
                    > --
                    > Peter Stevens, CSM, CSP
                    > http://tinyurl. com/Scrum- In-House- Training
                    > http://scrum- breakfast. com
                    > tel: +41 44 586 6450
                    >



                    -- 
                    Peter Stevens, CSM, CSP
                    http://tinyurl.com/Scrum-In-House-Training
                    http://scrum-breakfast.com
                    tel: +41 44 586 6450
                    
                  • Peter Stevens (calendar)
                    Hi Gerard, Are you talking about projects that come from within a company? Or are you talking about Requests for Proposals that you have received? I have seen
                    Message 9 of 21 , Apr 17, 2009
                    • 0 Attachment
                      Hi Gerard,

                      Are you talking about projects that come from within a company? Or are you talking about Requests for Proposals that you have received?

                      I have seen projects in which the size of the spec was measured in 3 ring binders (8, if memory services). I have also gotten a one liner - 'what should a state of the art real estate portal be capable of?' The latter was easier, because we wrote the stories ourselves.

                      But your point is taken: at the early phases, the stories wont be too small and breaking them down too much, without feedback from the customer and without the learning experience seeing the meat developing on that walking skeleton, is likely to produce wrong stories and therefore wrong estimates.

                      Cheers,
                      Peter

                      Gerard Meszaros wrote:

                      Peter Stevens (calendar) wrote:

                      I'm thinking a simpler version might work nearly as well:
                      • Estimate each story on the Cohn scale: 1, 2, 3, 5, 8...
                      • Planning poker produces one number, say a 5 - that average case
                      • Worst case e(90) is therefore an 8 (the next point on the cohn scale, an overshoot of 50 to 60% )
                      • Sum the teams estimate, sum the square of the deltas between e(90)-e(50) )
                      • The square root is you buffer, add to the sum of the e(50)'s to get you project worst case estimate.
                      Turns out, if you estimate a lot of little stories, the buffer is smaller than if you estimate a small number of big stories. Not too surprising, I suppose...
                      True, but we rarely have the stories broken down to this level when the budget is being set and even if we do, we rarely have all of them. So no matter what we do, we end up managing scope (at the individual story level) to make the dates that were committed based on the original guesstimates of what would be needed and how much effort it would take to build. I'm not saying that is a bad thing, though, just that we need to be careful not to delude ourselves into thinking we can get anything resembling an accurate projection (a.k.a. estimate) of the completion date given fixed scope. Which is why the ever-more-fleshy walking skeleton is the safest way to ensure the customer/PO doesn't get P.O.ed at us.

                      Gerard

                      -- 
                      Gerard Meszaros
                      Lean/Agile Coach/Mentor/ Trainer
                      http://www.gerardme szaros.com 
                      1-403-827-2967
                      
                      Author of the Jolt Productivity Award winning book "xUnit Test Patterns - Refactoring Test Code". Learn more at http://xunitpattern s.com/index. html
                      
                      
                      
                        


                      -- 
                      Peter Stevens, CSM, CSP
                      http://tinyurl.com/Scrum-In-House-Training
                      http://scrum-breakfast.com
                      tel: +41 44 586 6450
                      
                    • Ilja Preuß
                      Hi Peter, ... I m not sure what you are asking here... ... I m not sure, but have a hunch that my project manager takes my estimate(s) and uses gut feel to add
                      Message 10 of 21 , Apr 17, 2009
                      • 0 Attachment
                        Hi Peter,

                        > I agree with your definition of e(100). How often have you experienced it?

                        I'm not sure what you are asking here...

                        > So the question remains, if you have to achieve a date or a price, how do
                        > you do so? The answer is obviously non-trivial, and getting a good estimate
                        > is only part of the solution.

                        I'm not sure, but have a hunch that my project manager takes my
                        estimate(s) and uses gut feel to add a buffer.

                        > As a vendor selling development services, I think this kind of mathematical
                        > analysis is useful for understanding my negotiating position. How much risk
                        > is there in the estimates my team has given me?

                        Joel has an interesting approach to this problem, called Evidence
                        Based Scheduling. Never tried it, though.
                        http://www.joelonsoftware.com/items/2007/10/26.html

                        Cheers, Ilja
                      • davenicolette
                        Hi Peter, I don t consider quality a variable, so I don t treat it in the same way as scope, schedule, and resources. I m not so sure about your statement (in
                        Message 11 of 21 , Apr 17, 2009
                        • 0 Attachment
                          Hi Peter,

                          I don't consider quality a variable, so I don't treat it in the same way as scope, schedule, and resources.

                          I'm not so sure about your statement (in another message) that the buffer is smaller when you have many estimates of small things than it is when you have a few estimates of big things. Seems to me the cumulative error in a large set of small estimates tends to be big. The reason is that when you're looking for a ballpark number to use in contract negotiation, you want to work with large values that have low variation. A technical team's estimates of individual tasks will consist of a set of small values with high variation. The more of those you add up, the less reliable your estimate becomes.

                          For your purpose, you might consider using historical data about past projects of similar scope and make a high-level estimate using a formal estimation technique such as COCOMO II.

                          > A closely related topic is how to manage the competitive game that
                          > arises out of a fixed price project - the customer wants more, the
                          > vendor wants to do less.

                          This comes back around to Iron Triangle management. In your position, I would try to convey to the prospect that it's not realistic to fix scope, schedule, and resources in advance. I would try to understand their needs well enough to help them decide how best to manage that reality; which factor(s) can be variable and still result in a satisfactory outcome. A fixed-price agreement is certainly feasible, as long as everyone understands which aspects of the project can be flexible and which cannot. I think it's important that the prospect understand this and agree with the proposed approach. I don't think it's a good idea to try and add enough buffers that we can pretend we've fixed scope, schedule, and resources. Instead, it's better if the client can understand the reality and how we are proposing to manage it.

                          >
                          > I am working my way through your presentation on metrics - if you ever
                          > come to Switzerland, I'd love to have you present it at a Scrum
                          > Breakfast!

                          If you can find a sponsor, I would love to come. If you'll be at XP 2009, let's talk there.

                          > Re: Jeff Patten et al: Is there work documented on the net
                          > anywhere?

                          Jeff Patton - User Story Mapping. http://agileproductdesign.com/presentations/user_story_mapping/index.html

                          Koen Van Exem - Dimensional Planning Fixed Price Projects. http://www.xpday.net/Xpday2008/sessions/Dimensional%20Planning%20Fixed%20Price%20Projects.html

                          Dean Leffingwell - Scaling Software Agility: Best Practices for Large Enterprises (book), ISBN-10: 0321458192, 978-0321458193. He describes a similar technique.

                          Cheers,
                          Dave
                        • Dave Smith
                          On Thu, Apr 16, 2009 at 11:46 PM, Peter Stevens (calendar)
                          Message 12 of 21 , Apr 17, 2009
                          • 0 Attachment
                            On Thu, Apr 16, 2009 at 11:46 PM, Peter Stevens (calendar) <peterstev@...> wrote:
                            Hi everyone,

                            In Mike Cohn's Agile Planning and Estimating books, he writes about
                            using 50% estimates (50/50 chance that the story will be finished in
                            time <= estimate) and 90% estimates (90% that t <= e ). He goes further
                            to calculate a project buffer, based on the square root of the sum of
                            the squares of the differences between e(50) and e(90). (page 195 for
                            someone want to look up the reference).

                            Does anyone out there use these techniques to estimate the actual
                            completion time of a project? What experience have you had with them?

                            A past XP team did something similar at the iteration level, using a "risk"
                            estimate that we associated with each task. A weighting formula gave us a
                            risk buffer for the iteration. Our Product Owner used that for planning and
                            communication to other stake holders about when they could expect certain
                            features to roll out.

                            We found our way to this practice through a technical retrospective in which
                            we were discussing estimates vs. actuals over time, and how certain actuals
                            varied depending on some X. (X in this case was the upstream vendor
                            was providing a firmware drop that we had to accommodate. One of them had
                            just moved their development offshore, and quality had taking a dive, which
                            was screwing up our ability to use "yesterday's weather" when making
                            estimates.)

                            It worked well for us, with the caveat that we were already a high functioning
                            team and we had a lot of historical data to support our making this process
                            change.

                            Dave


                          • Brad Appleton
                            Ive had to do this before on more than one occasion. The stage/gate framework the organization is subject to required that a schedule+scope commitment be made
                            Message 13 of 21 , Apr 17, 2009
                            • 0 Attachment
                              Ive had to do this before on more than one occasion. The stage/gate
                              framework the organization is subject to required that a schedule+scope
                              commitment be made early on in the project based on so called "budgetary
                              estimates" (this of course is after the project's "business case" and
                              "marketing requirements" have been established but before the "system
                              requirements" are underway")

                              That early "commitment" is only expected to be accurate within a certain
                              range (e.g., plus or minus a calendar month worth of time and/or
                              team-effort). A Later "gate" in the framework occurs right after the
                              system requirements have been fully specified, and at that time one is
                              expected to give a much more accurate scope+schedule commitment (within
                              a calendar week or less).

                              Of course it was based on Waterfall/V-Model lifecycle thinking, but even
                              iterative and agile projects are still subject to that governance
                              framework (for now anyway :-)

                              There is actually apaper out there somewhere about various CCPM Buffer
                              Sizing techniques (e.g.,
                              http://findarticles.com/p/articles/mi_qa5491/is_200805/ai_n25501281/, a
                              google-search willgive you more) but most of them are pretty involved or
                              else require detailed task-level planning and dependencies.

                              One that I have used before is the square-root of the sum of the squares
                              method, that can work fine with an Agile backlog without the detailed
                              tasks and networks. It involves getting an average-case and worse-case
                              estimate for each backlog item and then taking the square-root of the
                              sum of the squares of the differences to arrive at a "buffer size" (in
                              staff effort).

                              But what I find is simpler and works much better for me is the following:
                              - the cone-of-uncertainty and what it says is a reasonable "percentage"
                              range of accuracy for the current stage of the project. (see
                              http://blog.bradapp.net/2006/12/cone-of-uncertainty.html)

                              - any "range" values afforded by the stage/gate framework that is
                              demanding that commitment at that time (e.g., "at stage #n thou shalt
                              produce an estimate and scope/schedule commitment that must be accurate
                              within +/- yy%")

                              - existing data from previous iterations & projects as to how far off
                              the teams initial "raw" (unadjusted) estimates are from actuals
                              (typically expressed as a percentage)

                              For example, if the team has historically been off by ~25% in its
                              initial estimates at that early stage, I consider using a buffer size of
                              25%. Unless it falls outside the range that the cone-of-uncertainty at
                              that time. Then I try to use the greater of that number and whatever
                              range# the stage-gate framework "mandates".


                              --
                              Brad Appleton <brad {AT} bradapp.net>
                              Agile CM Environments (http://blog.bradapp.net/)
                              & Software CM Patterns (www.scmpatterns.com)
                              "And miles to go before I sleep" -- Robert Frost
                            • Roy Morien
                              Oh, isn t the world of words wonderful! We can talk about scheduling buffers when we mean we haven t got a clue, so we ll add some extra time to our
                              Message 14 of 21 , Apr 19, 2009
                              • 0 Attachment
                                Oh, isn't the world of words wonderful! We can talk about 'scheduling buffers' when we mean 'we haven't got a clue, so we'll add some extra time to our estimate and hope like hell we are somewhere in the ballpark'.

                                I do hope that the PM's (by whatever name) are keeping the client fully informed of these 'scheduling buffers'. It seems to me to be rather unethical to add some arbitrary time period to our guess (another more correct word for estimate) and not tell the client that we are doing it, because we really don't know how long it is actually going to take.
                                 
                                Of course, we can always be scientific about this and apply a square root or a COCOMO estimate or whatever, but in the final analysis all we are doing is trying to make our guess respectable.
                                 
                                But, I suppose if the client, or management, insists on an accurate 'estimate' and will apply penalties for failure to achieve, then they deserve whatever buffered guess we give them. If our ass is gonna be grass, then we must cover it the best way we can.
                                 
                                Regards,
                                Roy Morien  
                                 

                                To: scrumdevelopment@yahoogroups.com
                                From: iljapreuss@...
                                Date: Fri, 17 Apr 2009 18:17:47 +0200
                                Subject: Re: [scrumdevelopment] Scheduling buffers



                                Hi Peter,

                                > I agree with your definition of e(100). How often have you experienced it?

                                I'm not sure what you are asking here...

                                > So the question remains, if you have to achieve a date or a price, how do
                                > you do so? The answer is obviously non-trivial, and getting a good estimate
                                > is only part of the solution.

                                I'm not sure, but have a hunch that my project manager takes my
                                estimate(s) and uses gut feel to add a buffer.

                                > As a vendor selling development services, I think this kind of mathematical
                                > analysis is useful for understanding my negotiating position. How much risk
                                > is there in the estimates my team has given me?

                                Joel has an interesting approach to this problem, called Evidence
                                Based Scheduling. Never tried it, though.
                                http://www.joelonso ftware.com/ items/2007/ 10/26.html

                                Cheers, Ilja



                                Let ninemsn property search for you. Need a new place to rent, share or buy?
                              • Ron Jeffries
                                Hello, Roy. This posting strikes me as personally disrespectful and ridiculing to those who use scheduling buffers . I do not use them, so do not concern
                                Message 15 of 21 , Apr 20, 2009
                                • 0 Attachment
                                  Hello, Roy.

                                  This posting strikes me as personally disrespectful and ridiculing
                                  to those who use "scheduling buffers". I do not use them, so do not
                                  concern yourself that I myself might feel abused.

                                  Your posting seems to miss entirely some ways that a scheduling
                                  buffer might be entirely appropriate. For example, suppose that
                                  through some amazing technique we knew /exactly/ how long the
                                  stories provided would take. And suppose we knew from experience
                                  that most projects discover about ten percent more work over and
                                  above the initial stories. Then a scheduling buffer of some size,
                                  predicting the end of the project, might be appropriate.

                                  Nor have you offered any advice on what one might do better. As much
                                  as I'd like to see all projects just start spending money and stop
                                  when things are good enough, I doubt that that approach is going to
                                  catch on. Most anyone contemplating spending on anything needs to
                                  have some kind of idea what it will cost. (If that's not the case, I
                                  have a car I would like to sell you.)

                                  Some people think a good way to do an estimate is to estimate
                                  stories at a couple of levels of certainty. Mike Cohn recommends 50%
                                  and 90%, if I'm not mistaken. Then we could provide a range: "This
                                  project could cost five months or 5*N dollars, with probability 0.5,
                                  and there is a 90% chance it can be done in thirteen months or 13*N
                                  dollars." Note that in this case, the 100% certainty number can
                                  never be determined in principle, despite that it is 100% certain
                                  that they'll terminate the project well before the universe runs out
                                  of Time.

                                  Neither this approach, nor any of the approaches I know, are
                                  entirely satisfactory. It seems to me to be that we need to
                                  understand that estimates are inaccurate but not necessarily
                                  completely wrong, and that the current list of features desired is
                                  probably not complete.

                                  I'd like to have a better way to do things than we know now, and I
                                  think that the ways we know now are not entirely worthy of ridicule.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  www.xprogramming.com/blog
                                  In times of stress, I like to turn to the wisdom of my Portuguese waitress,
                                  who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
                                  -- after Mark Vaughn, Autoweek.

                                  On Monday, April 20, 2009, at 1:05:23 AM, you wrote:

                                  > Oh, isn't the world of words wonderful! We can talk about
                                  > 'scheduling buffers' when we mean 'we haven't got a clue, so we'll
                                  > add some extra time to our estimate and hope like hell we are
                                  > somewhere in the ballpark'.

                                  > I do hope that the PM's (by whatever name) are keeping the client
                                  > fully informed of these 'scheduling buffers'. It seems to me to be
                                  > rather unethical to add some arbitrary time period to our guess
                                  > (another more correct word for estimate) and not tell the client
                                  > that we are doing it, because we really don't know how long it is
                                  > actually going to take.

                                  > Of course, we can always be scientific about this and apply a
                                  > square root or a COCOMO estimate or whatever, but in the final
                                  > analysis all we are doing is trying to make our guess respectable.

                                  > But, I suppose if the client, or management, insists on an
                                  > accurate 'estimate' and will apply penalties for failure to
                                  > achieve, then they deserve whatever buffered guess we give them.
                                  > If our ass is gonna be grass, then we must cover it the best way
                                  > we can.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  www.xprogramming.com/blog
                                  In times of stress, I like to turn to the wisdom of my Portuguese waitress,
                                  who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
                                  -- after Mark Vaughn, Autoweek.
                                • Mike Polen
                                  ... I have used them many times as many projects I work on are run from the top like a waterfall project and the head guy wants a date (no ranges please). If
                                  Message 16 of 21 , Apr 20, 2009
                                  • 0 Attachment
                                    --- In scrumdevelopment@yahoogroups.com, "Peter Stevens (calendar)" <peterstev@...> wrote:
                                    >
                                    > Hi everyone,
                                    >
                                    > In Mike Cohn's Agile Planning and Estimating books, he writes about
                                    > using 50% estimates (50/50 chance that the story will be finished in
                                    > time <= estimate) and 90% estimates (90% that t <= e ). He goes further
                                    > to calculate a project buffer, based on the square root of the sum of
                                    > the squares of the differences between e(50) and e(90). (page 195 for
                                    > someone want to look up the reference).
                                    >
                                    > Does anyone out there use these techniques to estimate the actual
                                    > completion time of a project? What experience have you had with them?
                                    >
                                    I have used them many times as many projects I work on are run from the top like a waterfall project and the head guy wants a date (no ranges please). If you want a more technical treatment of them look into Critical Chain (CCPM - http://en.wikipedia.org/wiki/Critical_chain). I prefer Mike Cohn's way as it is simple and I usually don't need the overhead of CCPM.

                                    -Mike
                                  • Roy Morien
                                    Well Ron, if those who feel disrespected and ridiculed wish to advise me of their hurt, which is entirely unintended by me, then I will apologise to them.
                                    Message 17 of 21 , Apr 23, 2009
                                    • 0 Attachment
                                      Well Ron, if those who feel disrespected and ridiculed wish to advise me of their hurt, which is entirely unintended by me, then I will apologise to them. However, I must admit to a little surprise at such fine sensitivities.

                                      Regards,
                                      Roy Morien


                                      To: scrumdevelopment@yahoogroups.com
                                      From: ronjeffries@...
                                      Date: Mon, 20 Apr 2009 06:25:23 -0400
                                      Subject: Re: [scrumdevelopment] Scheduling buffers



                                      Hello, Roy.

                                      This posting strikes me as personally disrespectful and ridiculing
                                      to those who use "scheduling buffers". I do not use them, so do not
                                      concern yourself that I myself might feel abused.

                                      Your posting seems to miss entirely some ways that a scheduling
                                      buffer might be entirely appropriate. For example, suppose that
                                      through some amazing technique we knew /exactly/ how long the
                                      stories provided would take. And suppose we knew from experience
                                      that most projects discover about ten percent more work over and
                                      above the initial stories. Then a scheduling buffer of some size,
                                      predicting the end of the project, might be appropriate.

                                      Nor have you offered any advice on what one might do better. As much
                                      as I'd like to see all projects just start spending money and stop
                                      when things are good enough, I doubt that that approach is going to
                                      catch on. Most anyone contemplating spending on anything needs to
                                      have some kind of idea what it will cost. (If that's not the case, I
                                      have a car I would like to sell you.)

                                      Some people think a good way to do an estimate is to estimate
                                      stories at a couple of levels of certainty. Mike Cohn recommends 50%
                                      and 90%, if I'm not mistaken. Then we could provide a range: "This
                                      project could cost five months or 5*N dollars, with probability 0.5,
                                      and there is a 90% chance it can be done in thirteen months or 13*N
                                      dollars." Note that in this case, the 100% certainty number can
                                      never be determined in principle, despite that it is 100% certain
                                      that they'll terminate the project well before the universe runs out
                                      of Time.

                                      Neither this approach, nor any of the approaches I know, are
                                      entirely satisfactory. It seems to me to be that we need to
                                      understand that estimates are inaccurate but not necessarily
                                      completely wrong, and that the current list of features desired is
                                      probably not complete.

                                      I'd like to have a better way to do things than we know now, and I
                                      think that the ways we know now are not entirely worthy of ridicule.

                                      Ron Jeffries
                                      www.XProgramming. com
                                      www.xprogramming. com/blog
                                      In times of stress, I like to turn to the wisdom of my Portuguese waitress,
                                      who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
                                      -- after Mark Vaughn, Autoweek.

                                      On Monday, April 20, 2009, at 1:05:23 AM, you wrote:

                                      > Oh, isn't the world of words wonderful! We can talk about
                                      > 'scheduling buffers' when we mean 'we haven't got a clue, so we'll
                                      > add some extra time to our estimate and hope like hell we are
                                      > somewhere in the ballpark'.

                                      > I do hope that the PM's (by whatever name) are keeping the client
                                      > fully informed of these 'scheduling buffers'. It seems to me to be
                                      > rather unethical to add some arbitrary time period to our guess
                                      > (another more correct word for estimate) and not tell the client
                                      > that we are doing it, because we really don't know how long it is
                                      > actually going to take.

                                      > Of course, we can always be scientific about this and apply a
                                      > square root or a COCOMO estimate or whatever, but in the final
                                      > analysis all we are doing is trying to make our guess respectable.

                                      > But, I suppose if the client, or management, insists on an
                                      > accurate 'estimate' and will apply penalties for failure to
                                      > achieve, then they deserve whatever buffered guess we give them.
                                      > If our ass is gonna be grass, then we must cover it the best way
                                      > we can.

                                      Ron Jeffries
                                      www.XProgramming. com
                                      www.xprogramming. com/blog
                                      In times of stress, I like to turn to the wisdom of my Portuguese waitress,
                                      who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
                                      -- after Mark Vaughn, Autoweek.




                                      Find car news, reviews and more Looking to change your car this year?
                                    • Eric Deslauriers
                                      Hi Peter, I had just that discussion several weeks ago with a peer. I would (and did) suggest that Quality is part of Scope. Delivering a broken widget does
                                      Message 18 of 21 , Apr 23, 2009
                                      • 0 Attachment
                                        Hi Peter,

                                        I had just that discussion several weeks ago with a peer. 

                                        I would (and did) suggest that Quality is part of Scope. Delivering a broken widget does not satisfy Scope.

                                        Set your target scope (which includes level of quality), then generate the Schedule to hit it given the Resources you can apply.

                                        Regards,
                                        Eric D

                                        On Fri, Apr 17, 2009 at 7:59 AM, Peter Stevens (calendar) <peterstev@...> wrote:


                                        Hi Dave,

                                        > likely completion date vs. estimated actual completion date.

                                        Your phrasing is definitely better than mine! Thanks!

                                        It's interesting that you talk about the iron triangle. I prefer to to think of it as having four points, which makes it a square or a cross, depending on how you connect the dots. Quality is the fourth point. I believe that not accumulating technical debt is one of the keys to hitting a goal reliably. If you have to do hardening or test phases (which may discover design or requirements defects) you may have a long period of zero velocity in front of you.
                                        <snip>

                                        Cheers,

                                        Peter



                                        davenicolette wrote:

                                        Hi Peter,

                                        I've used similar techniques for projecting likely completion dates, but not for "estimating the actual" (?) completion date. I usually push it out one standard deviation from the point you're labeling as e(50) and call that a reasonable projection for general planning purposes, but I also give a range of dates from best case to worst case.

                                        (BTW, I don't mean "worst case" in the sense of "never" - I think someone posted something whimsical about e(100) earlier in the thread. In my experience, once you've delivered 90% or more of the scope - and often far less than that - the customer decides they've obtained all the value they really need and they'd rather not pay for development of the remaining "nice to have" features, anyway. To me, this is another reason not to worry excessively about guessing the exact completion date. You just can't know what's going to happen between now and then.)

                                        IMHO whether this approach is relevant depends on how you're managing the Iron Triangle on the particular project. When scope has to be fixed and you need to try and determine when it's likely to be completed, you might use this sort of approach. For example, I worked on a project to rewrite an application that involves hardware installation at thousands of locations in several countries. To plan the rollout, the company needed at least a general idea of when to start various procedures to order hardware, obtain local government approvals, and make arrangements with unionized contractors to install wiring and so forth. Incremental delivery of the software was done to a staging environment and not all the way to production, for logistical reasons and also because it would have been largely meaningless to deploy just a portion of the replacement application to the field. So in that case, scope was fixed and we needed to know the approximate delivery date. The 50/90 percent estimation approach was a good fit for that situation.

                                        The more general case for agile projects is to fix the delivery date and vary the scope to fit within the available time. I don't think the 50/90 estimation approach is useful in those cases. Instead, I'd go with a technique like the ones elaborated by Jeff Patton, Koen Van Exem, and Dean Leffingwell (each using his own terminology) in which you collaborate with the customer to identify the most critical bits of the solution and deliver those first. If you have some observations of the team's velocity, you can get a pretty good idea of approximately how many iterations it will take them to deliver the results for the initial release. I think that works better than time-based estimation in these cases.

                                        I worked on a project last year that was managed in that way. We were able to deliver on an aggressive schedule by just delivering the most critical features in the first release, and then filled in the gaps in subsequent releases. We didn't use the time-based estimation technique you mention to handle that situation. We projected forward based on observed velocity, using adjustment factors like the ones you learn about in CSM classes for the first couple of iterations, since we didn't have enough data points for a straight projection until the end of iteration 3. It worked quite well in that situation. There's an example here http://davenicolette.wikispaces.com/Agile+Metrics. Download the zip file for "version 4" of the workshop, and it's in one of the spreadsheets.

                                        I hope that helps.

                                        Cheers,
                                        Dave

                                        --- In scrumdevelopment@yahoogroups.com, "Peter Stevens (calendar)" <peterstev@...> wrote:
                                        >
                                        > Hi everyone,
                                        >
                                        > In Mike Cohn's Agile Planning and Estimating books, he writes about
                                        > using 50% estimates (50/50 chance that the story will be finished in
                                        > time <= estimate) and 90% estimates (90% that t <= e ). He goes further
                                        > to calculate a project buffer, based on the square root of the sum of
                                        > the squares of the differences between e(50) and e(90). (page 195 for
                                        > someone want to look up the reference).
                                        >
                                        > Does anyone out there use these techniques to estimate the actual
                                        > completion time of a project? What experience have you had with them?
                                        >
                                        > Thanks in advance,
                                        >
                                        > Peter
                                        >
                                        > --
                                        > Peter Stevens, CSM, CSP
                                        > http://tinyurl.com/Scrum-In-House-Training
                                        > http://scrum-breakfast.com
                                        > tel: +41 44 586 6450
                                        >



                                        -- 
                                        Peter Stevens, CSM, CSP
                                        http://tinyurl.com/Scrum-In-House-Training
                                        http://scrum-breakfast.com
                                        tel: +41 44 586 6450
                                        




                                        --
                                        Eric D
                                        08 K1200S Tricolor (phreowww)
                                        06 Husqvarna TE610
                                        Sandy Eggo, CA (Ramona)
                                      • Eric Deslauriers
                                        Hi Peter, Some teams benefit from using PERT, especially if they struggle to provide good estimates, if for no other reason than it makes them walk through
                                        Message 19 of 21 , Apr 23, 2009
                                        • 0 Attachment
                                          Hi Peter,

                                          Some teams benefit from using PERT, especially if they struggle to provide good estimates, if for no other reason than it makes them walk through their inferences.

                                          We start with "thumb-in-the-air" estimates, which we pin at 50% likely to be accurate for some projects. After going through the initial sessions, we should be able to deliver estimates in the 90% range when we have strong experience in the domain (for sure). 

                                          One way team members can do that is to define their "number". One of my team members knows his initial-estimates are very frequently appx 2/3 the size of the actuals. So he just takes his initial estimate, multiplies it by his number (1.5), and ends up being pretty close much of the time. Personally, I don't get that - my estimates are usually right in the ballpark, but I can't really explain how I do it (unconscious competence) and since this mechanism works for a lot of folks, sounds like a good deal to me. :)

                                          Re your buffer question - 
                                          - Some teams prefer optimistic schedules - set an attractive date, then push it out as needed. Seems to be a preference when doing consulting. I see some schedules sometimes that have no accommodation for resolving defects and regression testing the subsequent builds (it's not all automated).
                                          - Other teams prefer pessimistic schedules - deliver early.
                                          - I prefer realistic schedules with a slight lean towards pessimism. It's always better to deliver a little early than a little late. <grin> This means that we estimate 1-2 more builds than we think it will take at the outset, then reset expectations if our quality is different than what we assumed when we started.

                                          Regards,
                                          Eric 


                                          On Thu, Apr 16, 2009 at 11:46 PM, Peter Stevens (calendar) <peterstev@...> wrote:


                                          Hi everyone,

                                          In Mike Cohn's Agile Planning and Estimating books, he writes about
                                          using 50% estimates (50/50 chance that the story will be finished in
                                          time <= estimate) and 90% estimates (90% that t <= e ). He goes further
                                          to calculate a project buffer, based on the square root of the sum of
                                          the squares of the differences between e(50) and e(90). (page 195 for
                                          someone want to look up the reference).

                                          Does anyone out there use these techniques to estimate the actual
                                          completion time of a project? What experience have you had with them?

                                          Thanks in advance,

                                          Peter

                                          --
                                          Peter Stevens, CSM, CSP
                                          http://tinyurl.com/Scrum-In-House-Training
                                          http://scrum-breakfast.com
                                          tel: +41 44 586 6450




                                          --
                                          Eric D
                                          08 K1200S Tricolor (phreowww)
                                          06 Husqvarna TE610
                                          Sandy Eggo, CA (Ramona)
                                        • Michael James
                                          This reminds me I promised to write more about this. Where are people getting the idea Scrum dev teams are responsible for schedule ? Managing scope to hit a
                                          Message 20 of 21 , Apr 24, 2009
                                          • 0 Attachment
                                            This reminds me I promised to write more about this.

                                            Where are people getting the idea Scrum dev teams are responsible for
                                            "schedule"? Managing scope to hit a release date is largely the
                                            Product Owner's job. Teams commit a negotiated amount of work (PBIs)
                                            from one Sprint to the next. I suppose they can "schedule" tasks
                                            within the Sprint if they want.


                                            On 4/24/09, Eric Deslauriers <eric.deslauriers@...> wrote:
                                            > Hi Peter,
                                            > Some teams benefit from using PERT, especially if they struggle to provide
                                            > good estimates, if for no other reason than it makes them walk through their
                                            > inferences.
                                            > http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique
                                            >
                                            > We start with "thumb-in-the-air" estimates, which we pin at 50% likely to be
                                            > accurate for some projects. After going through the initial sessions, we
                                            > should be able to deliver estimates in the 90% range when we have strong
                                            > experience in the domain (for sure).
                                            >
                                            > One way team members can do that is to define their "number". One of my team
                                            > members knows his initial-estimates are very frequently appx 2/3 the size of
                                            > the actuals. So he just takes his initial estimate, multiplies it by his
                                            > number (1.5), and ends up being pretty close much of the time. Personally, I
                                            > don't get that - my estimates are usually right in the ballpark, but I can't
                                            > really explain how I do it (unconscious competence) and since this mechanism
                                            > works for a lot of folks, sounds like a good deal to me. :)
                                            >
                                            > Re your buffer question -
                                            > - Some teams prefer optimistic schedules - set an attractive date, then push
                                            > it out as needed. Seems to be a preference when doing consulting. I see some
                                            > schedules sometimes that have no accommodation for resolving defects and
                                            > regression testing the subsequent builds (it's not all automated).
                                            > - Other teams prefer pessimistic schedules - deliver early.
                                            > - I prefer realistic schedules with a slight lean towards pessimism. It's
                                            > always better to deliver a little early than a little late. <grin> This
                                            > means that we estimate 1-2 more builds than we think it will take at the
                                            > outset, then reset expectations if our quality is different than what we
                                            > assumed when we started.
                                            >
                                            > Regards,
                                            > Eric
                                            >
                                            >
                                            > On Thu, Apr 16, 2009 at 11:46 PM, Peter Stevens (calendar) <
                                            > peterstev@...> wrote:
                                            >
                                            >>
                                            >>
                                            >> Hi everyone,
                                            >>
                                            >> In Mike Cohn's Agile Planning and Estimating books, he writes about
                                            >> using 50% estimates (50/50 chance that the story will be finished in
                                            >> time <= estimate) and 90% estimates (90% that t <= e ). He goes further
                                            >> to calculate a project buffer, based on the square root of the sum of
                                            >> the squares of the differences between e(50) and e(90). (page 195 for
                                            >> someone want to look up the reference).
                                            >>
                                            >> Does anyone out there use these techniques to estimate the actual
                                            >> completion time of a project? What experience have you had with them?
                                            >>
                                            >> Thanks in advance,
                                            >>
                                            >> Peter
                                            >>
                                            >> --
                                            >> Peter Stevens, CSM, CSP
                                            >> http://tinyurl.com/Scrum-In-House-Training
                                            >> http://scrum-breakfast.com
                                            >> tel: +41 44 586 6450
                                            >>
                                            >>
                                            >>
                                            >
                                            >
                                            >
                                            > --
                                            > Eric D
                                            > 08 K1200S Tricolor (phreowww)
                                            > 06 Husqvarna TE610
                                            > Sandy Eggo, CA (Ramona)
                                            >

                                            --
                                            Sent from my mobile device
                                          • Michael James
                                            I think I see where the disconnect in that other thread is coming from. As far as I m concerned, the effort estimation of PBIs serves three purposes: 1) Help
                                            Message 21 of 21 , Apr 24, 2009
                                            • 0 Attachment
                                              I think I see where the disconnect in that other thread is coming from.

                                              As far as I'm concerned, the effort estimation of PBIs serves three purposes:
                                              1) Help the Product Owner prioritize, considering ROI
                                              2) Help the Product Owner readjust release planning expectations
                                              3) (the one I've noticed more and more with the Planning Poker
                                              approach) cause the PO and team to have discussions about the scope of
                                              the items, revising them if possible.

                                              The team may also use them as guidelines of what to commit to in one
                                              Sprint, but that's up to them.

                                              On 4/24/09, Michael James <michael@...> wrote:
                                              > This reminds me I promised to write more about this.
                                              >
                                              > Where are people getting the idea Scrum dev teams are responsible for
                                              > "schedule"? Managing scope to hit a release date is largely the
                                              > Product Owner's job. Teams commit a negotiated amount of work (PBIs)
                                              > from one Sprint to the next. I suppose they can "schedule" tasks
                                              > within the Sprint if they want.
                                              >
                                              >
                                              > On 4/24/09, Eric Deslauriers <eric.deslauriers@...> wrote:
                                              >> Hi Peter,
                                              >> Some teams benefit from using PERT, especially if they struggle to
                                              >> provide
                                              >> good estimates, if for no other reason than it makes them walk through
                                              >> their
                                              >> inferences.
                                              >> http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique
                                              >>
                                              >> We start with "thumb-in-the-air" estimates, which we pin at 50% likely to
                                              >> be
                                              >> accurate for some projects. After going through the initial sessions, we
                                              >> should be able to deliver estimates in the 90% range when we have strong
                                              >> experience in the domain (for sure).
                                              >>
                                              >> One way team members can do that is to define their "number". One of my
                                              >> team
                                              >> members knows his initial-estimates are very frequently appx 2/3 the size
                                              >> of
                                              >> the actuals. So he just takes his initial estimate, multiplies it by his
                                              >> number (1.5), and ends up being pretty close much of the time. Personally,
                                              >> I
                                              >> don't get that - my estimates are usually right in the ballpark, but I
                                              >> can't
                                              >> really explain how I do it (unconscious competence) and since this
                                              >> mechanism
                                              >> works for a lot of folks, sounds like a good deal to me. :)
                                              >>
                                              >> Re your buffer question -
                                              >> - Some teams prefer optimistic schedules - set an attractive date, then
                                              >> push
                                              >> it out as needed. Seems to be a preference when doing consulting. I see
                                              >> some
                                              >> schedules sometimes that have no accommodation for resolving defects and
                                              >> regression testing the subsequent builds (it's not all automated).
                                              >> - Other teams prefer pessimistic schedules - deliver early.
                                              >> - I prefer realistic schedules with a slight lean towards pessimism. It's
                                              >> always better to deliver a little early than a little late. <grin> This
                                              >> means that we estimate 1-2 more builds than we think it will take at the
                                              >> outset, then reset expectations if our quality is different than what we
                                              >> assumed when we started.
                                              >>
                                              >> Regards,
                                              >> Eric
                                              >>
                                              >>
                                              >> On Thu, Apr 16, 2009 at 11:46 PM, Peter Stevens (calendar) <
                                              >> peterstev@...> wrote:
                                              >>
                                              >>>
                                              >>>
                                              >>> Hi everyone,
                                              >>>
                                              >>> In Mike Cohn's Agile Planning and Estimating books, he writes about
                                              >>> using 50% estimates (50/50 chance that the story will be finished in
                                              >>> time <= estimate) and 90% estimates (90% that t <= e ). He goes further
                                              >>> to calculate a project buffer, based on the square root of the sum of
                                              >>> the squares of the differences between e(50) and e(90). (page 195 for
                                              >>> someone want to look up the reference).
                                              >>>
                                              >>> Does anyone out there use these techniques to estimate the actual
                                              >>> completion time of a project? What experience have you had with them?
                                              >>>
                                              >>> Thanks in advance,
                                              >>>
                                              >>> Peter
                                              >>>
                                              >>> --
                                              >>> Peter Stevens, CSM, CSP
                                              >>> http://tinyurl.com/Scrum-In-House-Training
                                              >>> http://scrum-breakfast.com
                                              >>> tel: +41 44 586 6450
                                              >>>
                                              >>>
                                              >>>
                                              >>
                                              >>
                                              >>
                                              >> --
                                              >> Eric D
                                              >> 08 K1200S Tricolor (phreowww)
                                              >> 06 Husqvarna TE610
                                              >> Sandy Eggo, CA (Ramona)
                                              >>
                                              >
                                              > --
                                              > Sent from my mobile device
                                              >

                                              --
                                              Sent from my mobile device
                                            Your message has been successfully submitted and would be delivered to recipients shortly.