Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Like this presentation? Why not share!

- Agile Scrum Estimation by Prasad Prabhakaran 4447 views
- Agile Estimating by Mike Cohn 1119 views
- Agile Estimation Techniques by Mikalai Alimenkou 16104 views
- Agile Project Management for PMP's by VersionOne 17445 views
- Lean Startup + Story Mapping = Awes... by Brad Swanson 10136 views
- User Story Mapping in Practice by Steve Rogalsky 59175 views

6,786 views

Published on

No Downloads

Total views

6,786

On SlideShare

0

From Embeds

0

Number of Embeds

59

Shares

0

Downloads

268

Comments

0

Likes

3

No embeds

No notes for slide

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

No public clipboards found for this slide

Be the first to comment