1.
Rapid Estimation for Agile and Conventional Projects<br />cPrime, Inc.<br />4100 E. Third Ave, Suite 205<br />Foster City, CA 94404<br />650-931-1651<br />www.cprime.com<br />The leader in training and consulting for project management and agile development<br />
2.
Overview<br />The purpose of this course is to teach you how to provide good estimates for project tasks, quickly, using some best practices in “expert estimation”<br />You will also learn how uncertainty limits our ability to make accurate estimates, and how we can reduce the effects of uncertainty to produce better estimates<br />
3.
Outline<br />The Relationship between Uncertainty and Estimation<br />Techniques for Expert Estimation<br />Example of the “Planning Poker®” method<br />
4.
Outline<br />The Relationship between Uncertainty and Estimation<br />Techniques for Expert Estimation<br />Example of the “Planning Poker®” method<br />
5.
Estimation is Necessary for any Planning Process<br />We can estimate anything that can be quantified<br />Time<br />Resources<br />Materials<br />Common examples:<br />Waterfall projects estimate effort in order to predict the schedule and cost of a project<br />Agile projects estimate effort in order to predict scope that can be implemented for a fixed schedule and known resources<br />We may estimate effort required for<br />Scope: A set of features, or requirements<br />Task: An activities performed to accomplish necessary work<br />For convenience, we will use “task” throughout<br />
6.
We Create Schedules Based on Task Estimates<br />A schedule contains a set of tasks<br />Example: Remodel a House<br />Remodel Kitchen<br />Remodel Bedroom<br />Remodel Living Room<br />Each task takes time. To plan a schedule, we need to know <br />Effort required per task<br />Resources available per task<br />The logical sequencing of tasks<br />We will focus on effort estimates in this course<br />
7.
Estimating a Single Task is Challenging<br />Uncertainties arise in many ways. Some examples:<br />Incomplete understanding of scope<br />What features are assumed but not understood?<br />Incomplete understanding of work per scope<br />What bits of work did we omit?<br />Imperfect understanding of how much work is required even when the task is well understood<br />Variance due to skill level, materials issues, etc.<br />Inability to forecast the unexpected<br />What if the paint is out of stock?<br />
8.
Uncertainty Decreases as Scope Decreases<br />Big tasks have more uncertainty than small tasks<br />We can reduce uncertainty by breaking big tasks into smaller tasks, and estimating smaller tasks.<br />“Remodel Bedroom” becomes<br />Remove old carpet<br />Paint room<br />Cut new carpet to fit<br />Install new carpet<br />If we study and estimate each smaller task, we can get a better estimate for the larger task to “Remodel Bedroom”<br />
9.
So why not Make Tasks very Small?<br />Isn’t it better to make lots of small tasks?<br />Won’t we get much better estimates this way?<br />Only to a point<br />Two factors limit the usefulness of breaking work into a large number of small tasks<br />First, estimating many small tasks takes too long<br />Second, relative error decreases with scope only so far. There is little benefit to breaking a task with a 20% relative error into five smaller tasks which also have 20% errors.<br />We’ll address the issue of “granularity” next<br />
10.
We Need to Pick the Right Granularity<br />“Granularity” means size, or level of detail.<br />Choose a granularity that is practical for estimation<br />Too big: We can’t estimate with any reliability<br />Too small: Estimation of all items takes too long to be practical<br />Choose granularity appropriate to the project’s stage<br />Initial planning needs reasonable estimates quickly<br />Select “coarse-grained“ tasks that are small enough to estimate with moderate confidence, large enough to work through all of them in reasonable time<br />Detailed planning may be required at a later stage<br />Break coarse-grained subsets into fine-grained tasks<br />Estimate fine-grained tasks<br />Aggregate to improve coarse-grained estimates<br />Adjust plans based on results<br />
11.
Estimation Errors Behave in Surprising Ways<br />Each task estimate has some uncertainty<br />Tasks are more likely to take longer than estimated, than shorter<br />First reason is logistical: We omitted some work in our estimation<br />Second reason is mathematical: There is more room for work to grow (be over estimate) than shrink (be under estimate)<br />Example: Suppose we estimate “Paint Bedroom” at 3 person-days<br />Work can never be under the estimate by more than 3 days<br />Work can easily be over the estimate by more than 3 days<br />This observation has important implications for scheduling<br />
12.
Think of Uncertainties as Factors, not Increments<br />We cannot say a task should complete in “X plus or minus Y days,” and have this work for any X and Y<br />We can say that a task should complete in the range described by an uncertainty factor F, between “X/F” and “X × F,” and have this work for any F<br />Example: “Paint Bedroom” is estimated at 3 days, with an uncertainty factor of 2<br />Most likely case is 3 days<br />Best case is 1.5 days (under by 1.5 days)<br />Worst case is 6 days (over by 3 days)<br />More sophisticated models rely on lognormal probability distributions and Monte Carlo methods, but this simple model shows the right kind of behavior<br />
13.
Errors Add Up in Surprising Ways<br />Suppose 10 tasks have the same estimate of 10 days<br />The sum is 100 days. Call this the “naïve schedule.”<br />Now say each task has an uncertainty factor F = 2<br />The worst case is when every task is slow by 2:<br />This means the project takes 200 days<br />Ratio of Actual to Expected = F<br />Not good, but not very likely<br />A more typical case will have some tasks under, some over<br />Assume half are faster by 2, at 5 days (under by 5)<br />Assume half are slower by 2, at 20 days (over by 15)<br />Total time is 5 x 5 + 5 x 20 = 125 days<br />Still significantly over the naïve schedule of 100 days<br />
14.
Errors Add Up in Surprising Ways<br />The factor-of-two uncertainty for tasks added 25% to the actual time, compared to estimate<br />Ratio of Actual to Expected = (F + 1/F) / 2<br />Conclusion: Actual schedule will always exceed sum of most-likely task durations if uncertainty exists<br />We see this in a simple scenario<br />Expect real-life cases to be more complex, but not better<br />Remember, the worst case has no upper bound!<br />
15.
How do we Deal with Uncertainty?<br />We cannot eliminate uncertainty, only cope with it<br />We cope by reducing it to a practical minimum<br />We design our process to handle uncertainty gracefully<br />How we deal with uncertainty depends on the process<br />We add buffers to waterfall schedules to preserve scope<br />We adjust scope for agile projects to preserve schedule<br />
16.
What Lessons should we Learn about Uncertainty?<br />Estimation is prone to uncertainty<br />Smaller things are easier to estimate than bigger things<br />Breaking work into many small tasks helps, but only to a point<br />We may not have the time to estimate many small tasks<br />If breaking a task into smaller tasks doesn’t decrease the uncertainty factor, there is no benefit to the additional breakdown<br />Uncertainties for small tasks do not cancel. They accumulate, which limits the value of breaking large tasks down.<br />The process we are using must take uncertainty into account, and not assume that the future can be predicted accurately<br />
17.
Outline<br />The Relationship between Uncertainty and Estimation<br />Techniques for Expert Estimation<br />Example of the “Planning Poker®” method<br />
18.
Practical Guidance for Estimation<br />We will now provide some practical guidance for effective estimation<br />We will cover<br />Standard tools and techniques for estimation, from the PMBOK®<br />The Delphi and Wideband Delphi methods<br />A modern, and fast, version of the Wideband Delphi method known as “Planning Poker®”<br />
19.
When we Estimate, we Rely on Expertise and Experience<br />We rely on three basic (and overlapping) tools to produce estimates<br />These are described in the PMBOK®<br />All rely on past experience<br />The three tools are<br />Expert Judgment<br />Analogous Estimating<br />Parametric Estimating<br />
20.
The Three Tools for Estimation<br />Expert Judgment<br />Experts with experience in the field produce estimates based on their knowledge and history of past projects<br />Analogous Estimating<br />Estimators identify specific analogs to the work, in past projects, and estimate based on known effort for those analogs<br />Sometimes called “Affinity Estimating,” when used to estimate many tasks quickly by comparison to known tasks<br />Parametric Modeling<br />Estimators build quantitative models that predict effort, based on historical data<br />Useful when inputs are quantitative: Square feet of carpet, linear miles of road, etc.<br />Often not possible: Software development, unique projects, etc<br />
21.
How do we Use Time wisely when Estimating?<br />Estimation is time-consuming—Be aware of the cost!<br />Trade off between cost and benefits of estimation efforts<br /><ul><li>Understand that accuracy improves with effort only to a point
22.
More effort doesn’t always yield better results
26.
How do we get good practical results from a set of experts?
27.
How do we get those results quickly?</li></li></ul><li>The Delphi Methods<br />The Rand Corporation developed the original Delphi method for expert estimation in the 1940s<br />It is an anonymous, group-based, iterative forecasting method<br />Estimators answer questionnaires in Round 1<br />Estimators review anonymous answers, revise their answers<br />Process repeats until stopping criterion is met<br />Number of rounds<br />Consensus or stability of results<br />In the 1970s, Barry Boehm and John Farqhuar designed a variant that makes greater use of communication and collaboration, and named it Wideband Delphi<br />Like Delphi, but done in group meetings, with discussion<br />Holds one meeting per round, until time to stop<br />
28.
Delphi Methods Tap “Collective Wisdom”<br />Important characteristics of this approach include<br />Reliance on a Team of experts, not individuals, for estimation<br />Avoidance of expert bias (“anchoring”)<br />Focus on variance to improve estimates<br />
29.
Reliance on a Team<br />We draw on a team of estimators, not a single person, for each estimate<br />The Team has more knowledge than any individual<br />Tapping the Team’s “collective wisdom” yields greater understanding and better estimates than one person can provide<br />Best case: Estimators are the people who will also do the work<br />Do this whenever possible<br />
30.
Avoidance of Expert Bias<br />“Anchoring” refers to the tendency of estimators to defer to the judgment of someone they believe to be an expert<br />Team members often have different degrees of expertise in different areas, and are aware of this<br />If the “expert” gives his opinion first, other estimators may say nothing, or simply agree<br />We aren’t tapping collective wisdom when this happens<br />We’re just getting one estimate, several times<br />We reduce the problem of anchoring by gathering all responses anonymously before revealing the results<br />
31.
Focus on Variance to Improve Estimates<br />Different estimators have different backgrounds, different areas of expertise, and consider different factors for each item estimated<br />These differences usually lead to a range of estimates<br />Discussion about why the estimates differ produces insights into assumptions and issues<br />These insights, once shared, usually produce convergence of estimates over time, to more reliable values<br />Failure to converge indicates unresolved issues that require further study<br />
32.
The Planning Poker® Method Taps Wisdom Quickly<br />This version of Wideband Delphi is very quick<br />It is popular for Agile projects, but useful for any kind<br />Planning Poker® is a Team-based iterative voting process that converges to an estimate<br />Purpose is to find “good enough” estimate quickly, not best possible estimate<br />It uses Planning Poker® cards (or equivalent) to show individual estimates<br />Cards are not anonymous, but do prevent anchoring<br />PLANNING POKER® is a reg. trademark of Mountain Goat Software, LLC<br />
34.
Estimates have Units<br />Everything that we estimate has some kind of unit<br />Material goods have weight in pounds, volume in liters, length in miles, and so forth<br />Tasks have effort-based units (e.g., person-days)<br />Requirements (“Stories,” in agile terms) do not have unique units. Possibilities include<br />Person-days (for total implementation effort)<br />Function points (for complexity of software)<br />Story points (for complexity of agile Stories)<br />Units should be chosen to be what works best for the organization, especially the estimators and implementers<br />
35.
Three Roles Participate in the Estimation Process<br />Facilitator<br />Often provides quality control for specifications to be estimated<br />Runs the estimation meeting, enforces schedule, and keeps the Team focused and moving<br />Keeps discussions short and productive in meetings<br />Re-focuses or terminates non-productive discussions<br />Requirements Owner<br />Authors and/or is the authority on the items to be estimated<br />Answers questions to clarify requirements<br />Team Members (Estimators)<br />Provide estimates<br />Discuss issues and ask questions to improve their understanding<br />
36.
Estimation Meetings have Pre-requisites<br />Time, date, and duration of meeting are set<br />Decide duration (“Time box”) in advance (e.g., one hour), and stick to it<br />Items to estimate have been identified<br />Team members have reviewed and discussed all items prior to the meeting<br />Time is allocated to review the items in advance<br />They investigate items, as appropriate<br />They bring open issues and questions about requirements and implementation to the meeting<br />
37.
How to Conduct a Planning-Poker® Estimation Meeting<br />Facilitator reads item to be estimated, moderates brief discussion to clarify details, and calls for estimates.<br />Each Estimator places estimate face down, hiding the value.<br />Facilitator calls for vote, and all Estimators turn over cards at the same time.<br />If all cards agree, their value is recorded as the estimate.<br />Otherwise, Facilitator asks high and low Estimators to explain their reasoning, and moderates brief discussion to clarify issues.<br />Repeat 2-5 until estimates converge.<br />
38.
Outline<br />The Relationship between Uncertainty and Estimation<br />Techniques for Expert Estimation<br />Example of the “Planning Poker®” method<br />
39.
Example Walk-Through for Planning Poker®<br />We will use this technique to estimate, “How many chickens are required for a dinner party for twenty people?”<br />The Facilitator is Ralph Runner<br />The Requirements Owner is Debbie Diner<br />The Estimation Team has three members<br />Bob Cook<br />Sue Chef<br />Ted Baker<br />We begin with the first round of voting, and follow the process through to a final estimate<br />
40.
Round 1 Vote<br />Ralph reads the description, and the Team has a short discussion to clarify a few issues.<br />Ralph counts down: “5, 4, 3, 2, 1, Vote!”<br />Bob has 20<br />Sue has 13<br />Ted has 5<br />Ralph asks high and low voters for their reasoning.<br />Bob says, “I can eat a whole chicken, so we need one per person.”<br />Ted says, “I thought one chicken would feed three people, and we’d have some vegetarians.”<br />Sue has nothing to add. <br />
41.
Discussion after Round 1<br />Ralph asks Patty to respond.<br />Patty says, “Oh, I wrote ‘chicken,’ but I was thinking ‘squab,’ so use squab instead of chicken. And we’ll probably have one-third vegetarians, who will get mushroom risotto.”<br />Sue asks, “What’s a squab?”<br />Patty says, “It’s what you call a pigeon when you cook it.”<br />Ted says he doesn’t want to eat a pigeon. He starts to tell a long joke about pigeons, but Ralph says, “Hey, folks, let’s stay focused!”<br />Bob asks, “How many squabs does one person eat?”<br />Patty says, “It’s one squab per person.”<br />There are no more questions, so Ralph calls for a new vote.<br />
42.
Round 2<br />Ralph counts down: “5, 4, 3, 2, 1, Vote!”<br />Bob has 5<br />Sue has 13<br />Ted has 20<br />Ralph asks high and low voters for their reasoning.<br />Bob says, “Ted was right last time. Most people won’t eat pigeons. They’ll have risotto.”<br />Ted says, “Bob was right last time. We need 20 to cover late-comers and spoilage.”<br />Sue adds, “Thirteen is just right for one-third vegetarians.”<br />
43.
Discussion after Round 2<br />Ralph asks Patty to respond.<br />Patty says, “I know who will be coming, and the non-vegetarians will love the squab. I don’t want to buy extras, because the squabs are very expensive. Also, the risotto is very good, we’ll have plenty, and I’ve told everyone that it’s first-come, first-served.”<br />Sue asks, “What kind of wine do you serve with squab? White or red?”<br />When the wine discussion threatens to drag on, Ralph reminds everyone that they have a lot of estimation to do in a short time, and need to move quickly.<br />There are no more questions, so Ralph calls for a new vote.<br />
44.
Round 3<br />Ralph counts down: “5, 4, 3, 2, 1, Vote!”<br />Bob has 13<br />Sue has 13<br />Ted has 13<br />Ralph says, “Great! Thirteen it is!”<br />He records the result, and the group moves on to the next item to estimate<br />
45.
What we Learn from this Example<br />Written requirements that make sense to the writer often mean something else to the reader<br />Is it a chicken, or a squab?<br />Implicit assumptions are revealed during discussion of high-low results. Note that none of these were mentioned in the requirements:<br />One squab feeds one person<br />A third of the guests are vegetarians<br />Squab is expensive, so buy no more than necessary<br />Squab lovers who don’t get a squab will be content risotto<br />Some may hate squab, but only squab-lovers are attending<br />Distractions beckon, but time is limited, so the facilitator needs to keep the group focused<br />
46.
Try it!<br />Use the Planning Poker® method for your next estimation session<br />Try it, and compare to your existing process<br />Did this take less time, or more?<br />Is confidence in the results higher? Lower? The same?<br />Some Predictions<br />This method may seem awkward at first<br />It may feel like a game, and not serious<br />Everyone will quickly discover that the resulting discussions are more enlightening than before<br />The process will move faster and provide results of higher confidence<br />No one will want to go back to the old way<br />
47.
Conclusion<br />Estimation cannot be made perfect<br />Smaller items are easier to estimate than larger items<br />Taking more time does not always mean that estimates are more accurate<br />Estimation errors do not cancel, but accumulate<br />The process must take uncertainty into account<br />Planning Poker® provides “good enough” estimates quickly<br />It taps collective wisdom, and avoids expert bias through voting<br />Discussion of high-low results forces assumptions, issues to surface<br />This method improves understanding of requirements<br />It produces useful results quickly<br />
48.
Closing<br />cPrime provides Estimation card decks for use in estimation (four sets per box) or Individually priced at $4.50/deck.<br />Please visit our free online elearning Rapid Estimation for Agile & Conventional Projects at:<br />http://cprime.eleapcourses.com/courses/view?id=11059<br />
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.
Be the first to comment