The document describes a method called "Planning Poker" for quickly estimating project tasks through group discussion and iterative voting. A facilitator leads a team in estimating how many chickens are needed for a dinner party for 20 people. Through three rounds of voting and discussion to clarify assumptions, the team converges on an estimate of 13 chickens. Planning Poker aims to leverage collective expertise while avoiding biases from individual experts.

1. Rapid Estimation for Agile and Conventional ProjectscPrime, Inc.4100 E. Third Ave, Suite 205Foster City, CA 94404650-931-1651www.cprime.comThe leader in training and consulting for project management and agile development

2. OverviewThe 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. OutlineThe Relationship between Uncertainty and EstimationTechniques for Expert EstimationExample of the “Planning Poker®” method

4. OutlineThe Relationship between Uncertainty and EstimationTechniques for Expert EstimationExample of the “Planning Poker®” method

5. Estimation is Necessary for any Planning ProcessWe can estimate anything that can be quantifiedTimeResourcesMaterialsCommon examples:Waterfall projects estimate effort in order to predict the schedule and cost of a projectAgile projects estimate effort in order to predict scope that can be implemented for a fixed schedule and known resourcesWe may estimate effort required forScope: A set of features, or requirementsTask: An activities performed to accomplish necessary workFor convenience, we will use “task” throughout

6. We Create Schedules Based on Task EstimatesA schedule contains a set of tasksExample: Remodel a HouseRemodel KitchenRemodel BedroomRemodel Living RoomEach task takes time. To plan a schedule, we need to know Effort required per taskResources available per taskThe logical sequencing of tasksWe will focus on effort estimates in this course

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

8. Uncertainty Decreases as Scope DecreasesBig tasks have more uncertainty than small tasksWe can reduce uncertainty by breaking big tasks into smaller tasks, and estimating smaller tasks.“Remodel Bedroom” becomesRemove old carpetPaint roomCut new carpet to fitInstall new carpetIf 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 pointTwo factors limit the usefulness of breaking work into a large number of small tasksFirst, estimating many small tasks takes too longSecond, 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 estimationToo big: We can’t estimate with any reliabilityToo small: Estimation of all items takes too long to be practicalChoose granularity appropriate to the project’s stageInitial planning needs reasonable estimates quicklySelect “coarse-grained“ tasks that are small enough to estimate with moderate confidence, large enough to work through all of them in reasonable timeDetailed planning may be required at a later stageBreak coarse-grained subsets into fine-grained tasksEstimate fine-grained tasksAggregate to improve coarse-grained estimatesAdjust plans based on results

11. Estimation Errors Behave in Surprising WaysEach task estimate has some uncertaintyTasks are more likely to take longer than estimated, than shorterFirst reason is logistical: We omitted some work in our estimationSecond 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-daysWork can never be under the estimate by more than 3 daysWork can easily be over the estimate by more than 3 daysThis observation has important implications for scheduling

12. Think of Uncertainties as Factors, not IncrementsWe cannot say a task should complete in “X plus or minus Y days,” and have this work for any X and YWe 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 FExample: “Paint Bedroom” is estimated at 3 days, with an uncertainty factor of 2Most likely case is 3 daysBest 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 WaysSuppose 10 tasks have the same estimate of 10 daysThe sum is 100 days. Call this the “naïve schedule.”Now say each task has an uncertainty factor F = 2The worst case is when every task is slow by 2:This means the project takes 200 daysRatio of Actual to Expected = FNot good, but not very likelyA more typical case will have some tasks under, some overAssume 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 daysStill significantly over the naïve schedule of 100 days

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

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

16. What Lessons should we Learn about Uncertainty?Estimation is prone to uncertaintySmaller things are easier to estimate than bigger thingsBreaking work into many small tasks helps, but only to a pointWe may not have the time to estimate many small tasksIf breaking a task into smaller tasks doesn’t decrease the uncertainty factor, there is no benefit to the additional breakdownUncertainties 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. OutlineThe Relationship between Uncertainty and EstimationTechniques for Expert EstimationExample of the “Planning Poker®” method

18. Practical Guidance for EstimationWe will now provide some practical guidance for effective estimationWe will coverStandard tools and techniques for estimation, from the PMBOK®The Delphi and Wideband Delphi methodsA modern, and fast, version of the Wideband Delphi method known as “Planning Poker®”

19. When we Estimate, we Rely on Expertise and ExperienceWe rely on three basic (and overlapping) tools to produce estimatesThese are described in the PMBOK®All rely on past experienceThe three tools areExpert JudgmentAnalogous EstimatingParametric Estimating

20. The Three Tools for EstimationExpert JudgmentExperts with experience in the field produce estimates based on their knowledge and history of past projectsAnalogous EstimatingEstimators identify specific analogs to the work, in past projects, and estimate based on known effort for those analogsSometimes called “Affinity Estimating,” when used to estimate many tasks quickly by comparison to known tasksParametric ModelingEstimators build quantitative models that predict effort, based on historical dataUseful when inputs are quantitative: Square feet of carpet, linear miles of road, etc.Often not possible: Software development, unique projects, etc

21. How do we Use Time wisely when Estimating?Estimation is time-consuming—Be aware of the cost!Trade off between cost and benefits of estimation effortsUnderstand that accuracy improves with effort only to a point

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?

27. How do we get those results quickly?The Delphi MethodsThe Rand Corporation developed the original Delphi method for expert estimation in the 1940sIt is an anonymous, group-based, iterative forecasting methodEstimators answer questionnaires in Round 1Estimators review anonymous answers, revise their answersProcess repeats until stopping criterion is metNumber of roundsConsensus or stability of resultsIn the 1970s, Barry Boehm and John Farqhuar designed a variant that makes greater use of communication and collaboration, and named it Wideband DelphiLike Delphi, but done in group meetings, with discussionHolds one meeting per round, until time to stop

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

29. Reliance on a TeamWe draw on a team of estimators, not a single person, for each estimateThe Team has more knowledge than any individualTapping the Team’s “collective wisdom” yields greater understanding and better estimates than one person can provideBest case: Estimators are the people who will also do the workDo 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 expertTeam members often have different degrees of expertise in different areas, and are aware of thisIf the “expert” gives his opinion first, other estimators may say nothing, or simply agreeWe aren’t tapping collective wisdom when this happensWe’re just getting one estimate, several timesWe reduce the problem of anchoring by gathering all responses anonymously before revealing the results

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

32. The Planning Poker® Method Taps Wisdom QuicklyThis version of Wideband Delphi is very quickIt is popular for Agile projects, but useful for any kindPlanning Poker® is a Team-based iterative voting process that converges to an estimatePurpose is to find “good enough” estimate quickly, not best possible estimateIt uses Planning Poker® cards (or equivalent) to show individual estimatesCards are not anonymous, but do prevent anchoringPLANNING POKER® is a reg. trademark of Mountain Goat Software, LLC

33. Estimates are Restricted to a Pre-defined SetOnly 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 sizeWe 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 aboveConsider breaking the item into smaller piecesThe specific sequence of values is © 2007 by Mountain Goat Software, LLC

34. Estimates have UnitsEverything that we estimate has some kind of unitMaterial goods have weight in pounds, volume in liters, length in miles, and so forthTasks have effort-based units (e.g., person-days)Requirements (“Stories,” in agile terms) do not have unique units. Possibilities includePerson-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 ProcessFacilitatorOften provides quality control for specifications to be estimatedRuns the estimation meeting, enforces schedule, and keeps the Team focused and movingKeeps discussions short and productive in meetingsRe-focuses or terminates non-productive discussionsRequirements OwnerAuthors and/or is the authority on the items to be estimatedAnswers questions to clarify requirementsTeam Members (Estimators)Provide estimatesDiscuss issues and ask questions to improve their understanding

36. Estimation Meetings have Pre-requisitesTime, date, and duration of meeting are setDecide duration (“Time box”) in advance (e.g., one hour), and stick to itItems to estimate have been identifiedTeam members have reviewed and discussed all items prior to the meetingTime is allocated to review the items in advanceThey investigate items, as appropriateThey bring open issues and questions about requirements and implementation to the meeting

37. How to Conduct a Planning-Poker® Estimation MeetingFacilitator 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. OutlineThe Relationship between Uncertainty and EstimationTechniques for Expert EstimationExample 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 RunnerThe Requirements Owner is Debbie DinerThe Estimation Team has three membersBob CookSue ChefTed BakerWe begin with the first round of voting, and follow the process through to a final estimate

40. Round 1 VoteRalph 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 20Sue has 13Ted has 5Ralph 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 1Ralph 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 2Ralph counts down: “5, 4, 3, 2, 1, Vote!”Bob has 5Sue has 13Ted has 20Ralph 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 2Ralph 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.