1. Rapid Estimation for Agile and Conventional Projects cPrime, Inc. 4100 E. Third Ave, Suite 205 Foster City, CA 94404 650-931-1651 www.cprime.com The leader in training and consulting for project management and agile development

2. Overview 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” 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

3. Outline The Relationship between Uncertainty and Estimation Techniques for Expert Estimation Example of the “Planning Poker®” method

4. Outline The Relationship between Uncertainty and Estimation Techniques for Expert Estimation Example of the “Planning Poker®” method

5. Estimation is Necessary for any Planning Process We can estimate anything that can be quantified Time Resources Materials Common examples: Waterfall projects estimate effort in order to predict the schedule and cost of a project Agile projects estimate effort in order to predict scope that can be implemented for a fixed schedule and known resources We may estimate effort required for Scope: A set of features, or requirements Task: An activities performed to accomplish necessary work For convenience, we will use “task” throughout

6. We Create Schedules Based on Task Estimates A schedule contains a set of tasks Example: Remodel a House Remodel Kitchen Remodel Bedroom Remodel Living Room Each task takes time. To plan a schedule, we need to know Effort required per task Resources available per task The logical sequencing of tasks We will focus on effort estimates in this course

7. Estimating a Single Task is Challenging Uncertainties arise in many ways. Some examples: Incomplete understanding of scope What features are assumed but not understood? Incomplete understanding of work per scope What bits of work did we omit? Imperfect understanding of how much work is required even when the task is well understood Variance due to skill level, materials issues, etc. Inability to forecast the unexpected What if the paint is out of stock?

8. Uncertainty Decreases as Scope Decreases Big tasks have more uncertainty than small tasks We can reduce uncertainty by breaking big tasks into smaller tasks, and estimating smaller tasks. “Remodel Bedroom” becomes Remove old carpet Paint room Cut new carpet to fit Install new carpet If we study and estimate each smaller task, we can get a better estimate for the larger task to “Remodel Bedroom”

9. So why not Make Tasks very Small? Isn’t it better to make lots of small tasks? Won’t we get much better estimates this way? Only to a point Two factors limit the usefulness of breaking work into a large number of small tasks First, estimating many small tasks takes too long 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. We’ll address the issue of “granularity” next

10. We Need to Pick the Right Granularity “Granularity” means size, or level of detail. Choose a granularity that is practical for estimation Too big: We can’t estimate with any reliability Too small: Estimation of all items takes too long to be practical Choose granularity appropriate to the project’s stage Initial planning needs reasonable estimates quickly Select “coarse-grained“ tasks that are small enough to estimate with moderate confidence, large enough to work through all of them in reasonable time Detailed planning may be required at a later stage Break coarse-grained subsets into fine-grained tasks Estimate fine-grained tasks Aggregate to improve coarse-grained estimates Adjust plans based on results

11. Estimation Errors Behave in Surprising Ways Each task estimate has some uncertainty Tasks are more likely to take longer than estimated, than shorter First reason is logistical: We omitted some work in our estimation Second reason is mathematical: There is more room for work to grow (be over estimate) than shrink (be under estimate) Example: Suppose we estimate “Paint Bedroom” at 3 person-days Work can never be under the estimate by more than 3 days Work can easily be over the estimate by more than 3 days This observation has important implications for scheduling

12. Think of Uncertainties as Factors, not Increments We cannot say a task should complete in “X plus or minus Y days,” and have this work for any X and Y 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 Example: “Paint Bedroom” is estimated at 3 days, with an uncertainty factor of 2 Most likely case is 3 days Best case is 1.5 days (under by 1.5 days) Worst case is 6 days (over by 3 days) More sophisticated models rely on lognormal probability distributions and Monte Carlo methods, but this simple model shows the right kind of behavior

13. Errors Add Up in Surprising Ways Suppose 10 tasks have the same estimate of 10 days The sum is 100 days. Call this the “naïve schedule.” Now say each task has an uncertainty factor F = 2 The worst case is when every task is slow by 2: This means the project takes 200 days Ratio of Actual to Expected = F Not good, but not very likely A more typical case will have some tasks under, some over Assume half are faster by 2, at 5 days (under by 5) Assume half are slower by 2, at 20 days (over by 15) Total time is 5 x 5 + 5 x 20 = 125 days Still significantly over the naïve schedule of 100 days

14. Errors Add Up in Surprising Ways The factor-of-two uncertainty for tasks added 25% to the actual time, compared to estimate Ratio of Actual to Expected = (F + 1/F) / 2 Conclusion: Actual schedule will always exceed sum of most-likely task durations if uncertainty exists We see this in a simple scenario Expect real-life cases to be more complex, but not better Remember, the worst case has no upper bound!

15. How do we Deal with Uncertainty? We cannot eliminate uncertainty, only cope with it We cope by reducing it to a practical minimum We design our process to handle uncertainty gracefully How we deal with uncertainty depends on the process We add buffers to waterfall schedules to preserve scope We adjust scope for agile projects to preserve schedule

16. What Lessons should we Learn about Uncertainty? Estimation is prone to uncertainty Smaller things are easier to estimate than bigger things Breaking work into many small tasks helps, but only to a point We may not have the time to estimate many small tasks If breaking a task into smaller tasks doesn’t decrease the uncertainty factor, there is no benefit to the additional breakdown Uncertainties for small tasks do not cancel. They accumulate, which limits the value of breaking large tasks down. The process we are using must take uncertainty into account, and not assume that the future can be predicted accurately

17. Outline The Relationship between Uncertainty and Estimation Techniques for Expert Estimation Example of the “Planning Poker®” method

18. Practical Guidance for Estimation We will now provide some practical guidance for effective estimation We will cover Standard tools and techniques for estimation, from the PMBOK® The Delphi and Wideband Delphi methods A modern, and fast, version of the Wideband Delphi method known as “Planning Poker®”

19. When we Estimate, we Rely on Expertise and Experience We rely on three basic (and overlapping) tools to produce estimates These are described in the PMBOK® All rely on past experience The three tools are Expert Judgment Analogous Estimating Parametric Estimating

20. The Three Tools for Estimation Expert Judgment Experts with experience in the field produce estimates based on their knowledge and history of past projects Analogous Estimating Estimators identify specific analogs to the work, in past projects, and estimate based on known effort for those analogs Sometimes called “Affinity Estimating,” when used to estimate many tasks quickly by comparison to known tasks Parametric Modeling Estimators build quantitative models that predict effort, based on historical data Useful when inputs are quantitative: Square feet of carpet, linear miles of road, etc. Often not possible: Software development, unique projects, etc

22. More effort doesn’t always yield better results

23. Avoid “analysis paralysis!”

24. Good enough, now, beats best possible, later

25. We want to get reasonable estimates quickly

26. How do we get good practical results from a set of experts?

28. Delphi Methods Tap “Collective Wisdom” Important characteristics of this approach include Reliance on a Team of experts, not individuals, for estimation Avoidance of expert bias (“anchoring”) Focus on variance to improve estimates

29. Reliance on a Team We draw on a team of estimators, not a single person, for each estimate The Team has more knowledge than any individual Tapping the Team’s “collective wisdom” yields greater understanding and better estimates than one person can provide Best case: Estimators are the people who will also do the work Do this whenever possible

30. Avoidance of Expert Bias “Anchoring” refers to the tendency of estimators to defer to the judgment of someone they believe to be an expert Team members often have different degrees of expertise in different areas, and are aware of this If the “expert” gives his opinion first, other estimators may say nothing, or simply agree We aren’t tapping collective wisdom when this happens We’re just getting one estimate, several times We reduce the problem of anchoring by gathering all responses anonymously before revealing the results

31. Focus on Variance to Improve Estimates Different estimators have different backgrounds, different areas of expertise, and consider different factors for each item estimated These differences usually lead to a range of estimates Discussion about why the estimates differ produces insights into assumptions and issues These insights, once shared, usually produce convergence of estimates over time, to more reliable values Failure to converge indicates unresolved issues that require further study

32. The Planning Poker® Method Taps Wisdom Quickly This version of Wideband Delphi is very quick It is popular for Agile projects, but useful for any kind Planning Poker® is a Team-based iterative voting process that converges to an estimate Purpose is to find “good enough” estimate quickly, not best possible estimate It uses Planning Poker® cards (or equivalent) to show individual estimates Cards are not anonymous, but do prevent anchoring PLANNING POKER® is a reg. trademark of Mountain Goat Software, LLC

33. Estimates are Restricted to a Pre-defined Set Only allowed values are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ? Initial integer values are from the Fibonacci sequence “?” means “I don’t know enough to estimate” “∞”(infinity) means “It’s so big there’s no point in estimating it” Spacing increases with size because absolute uncertainty increases with size We restrict allowed values to discourage unproductive debate (“Is it 13 or 14?” Who cares?) Granularity may be too large if estimates are at 20 or above Consider breaking the item into smaller pieces The specific sequence of values is © 2007 by Mountain Goat Software, LLC

34. Estimates have Units Everything that we estimate has some kind of unit Material goods have weight in pounds, volume in liters, length in miles, and so forth Tasks have effort-based units (e.g., person-days) Requirements (“Stories,” in agile terms) do not have unique units. Possibilities include Person-days (for total implementation effort) Function points (for complexity of software) Story points (for complexity of agile Stories) Units should be chosen to be what works best for the organization, especially the estimators and implementers

35. Three Roles Participate in the Estimation Process Facilitator Often provides quality control for specifications to be estimated Runs the estimation meeting, enforces schedule, and keeps the Team focused and moving Keeps discussions short and productive in meetings Re-focuses or terminates non-productive discussions Requirements Owner Authors and/or is the authority on the items to be estimated Answers questions to clarify requirements Team Members (Estimators) Provide estimates Discuss issues and ask questions to improve their understanding

36. Estimation Meetings have Pre-requisites Time, date, and duration of meeting are set Decide duration (“Time box”) in advance (e.g., one hour), and stick to it Items to estimate have been identified Team members have reviewed and discussed all items prior to the meeting Time is allocated to review the items in advance They investigate items, as appropriate They bring open issues and questions about requirements and implementation to the meeting

37. How to Conduct a Planning-Poker® Estimation Meeting Facilitator reads item to be estimated, moderates brief discussion to clarify details, and calls for estimates. Each Estimator places estimate face down, hiding the value. Facilitator calls for vote, and all Estimators turn over cards at the same time. If all cards agree, their value is recorded as the estimate. Otherwise, Facilitator asks high and low Estimators to explain their reasoning, and moderates brief discussion to clarify issues. Repeat 2-5 until estimates converge.

38. Outline The Relationship between Uncertainty and Estimation Techniques for Expert Estimation Example of the “Planning Poker®” method

39. Example Walk-Through for Planning Poker® We will use this technique to estimate, “How many chickens are required for a dinner party for twenty people?” The Facilitator is Ralph Runner The Requirements Owner is Debbie Diner The Estimation Team has three members Bob Cook Sue Chef Ted Baker We begin with the first round of voting, and follow the process through to a final estimate

40. Round 1 Vote Ralph reads the description, and the Team has a short discussion to clarify a few issues. Ralph counts down: “5, 4, 3, 2, 1, Vote!” Bob has 20 Sue has 13 Ted has 5 Ralph asks high and low voters for their reasoning. Bob says, “I can eat a whole chicken, so we need one per person.” Ted says, “I thought one chicken would feed three people, and we’d have some vegetarians.” Sue has nothing to add.

41. Discussion after Round 1 Ralph asks Patty to respond. 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.” Sue asks, “What’s a squab?” Patty says, “It’s what you call a pigeon when you cook it.” 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!” Bob asks, “How many squabs does one person eat?” Patty says, “It’s one squab per person.” There are no more questions, so Ralph calls for a new vote.

42. Round 2 Ralph counts down: “5, 4, 3, 2, 1, Vote!” Bob has 5 Sue has 13 Ted has 20 Ralph asks high and low voters for their reasoning. Bob says, “Ted was right last time. Most people won’t eat pigeons. They’ll have risotto.” Ted says, “Bob was right last time. We need 20 to cover late-comers and spoilage.” Sue adds, “Thirteen is just right for one-third vegetarians.”

43. Discussion after Round 2 Ralph asks Patty to respond. 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.” Sue asks, “What kind of wine do you serve with squab? White or red?” 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. There are no more questions, so Ralph calls for a new vote.

44. Round 3 Ralph counts down: “5, 4, 3, 2, 1, Vote!” Bob has 13 Sue has 13 Ted has 13 Ralph says, “Great! Thirteen it is!” He records the result, and the group moves on to the next item to estimate

45. What we Learn from this Example Written requirements that make sense to the writer often mean something else to the reader Is it a chicken, or a squab? Implicit assumptions are revealed during discussion of high-low results. Note that none of these were mentioned in the requirements: One squab feeds one person A third of the guests are vegetarians Squab is expensive, so buy no more than necessary Squab lovers who don’t get a squab will be content risotto Some may hate squab, but only squab-lovers are attending Distractions beckon, but time is limited, so the facilitator needs to keep the group focused

46. Try it! Use the Planning Poker® method for your next estimation session Try it, and compare to your existing process Did this take less time, or more? Is confidence in the results higher? Lower? The same? Some Predictions This method may seem awkward at first It may feel like a game, and not serious Everyone will quickly discover that the resulting discussions are more enlightening than before The process will move faster and provide results of higher confidence No one will want to go back to the old way

47. Conclusion Estimation cannot be made perfect Smaller items are easier to estimate than larger items Taking more time does not always mean that estimates are more accurate Estimation errors do not cancel, but accumulate The process must take uncertainty into account Planning Poker® provides “good enough” estimates quickly It taps collective wisdom, and avoids expert bias through voting Discussion of high-low results forces assumptions, issues to surface This method improves understanding of requirements It produces useful results quickly

48. Closing cPrime provides Estimation card decks for use in estimation (four sets per box) or Individually priced at $4.50/deck. Please visit our free online elearning Rapid Estimation for Agile & Conventional Projects at: http://cprime.eleapcourses.com/courses/view?id=11059