Transcription
Agile Estimating andPlanningMike Cohn26 August 20091Mike Cohn - background 2003–2009 Mountain Goat Software 2
What’s a good plan? A good plan is one that supports reliable decision-makingWill go from We’ll be done in the third quarterWe’ll be done in AugustWe’ll be done August 18th John Maynard Keynes 2003–2009 Mountain Goat Software 3What makes planning agile? 2003–2009 Mountain Goat Software 4
Release and iteration planningRelease Plan 2003–2009 Mountain Goat Software 5Agenda Product backlog estimation units Story points Ideal time Techniques for estimating Iteration planning Release planning 2003–2009 Mountain Goat Software 6
2003–2009 Mountain Goat Software Product Backlog 7Iteration Backlog 2003–2009 Mountain Goat Software 8
How long will it take. .to read the latest Harry Potter book? .to drive to Phoenix? 2003–2009 Mountain Goat Software 9Estimate size; derive duration 2003–2009 Mountain Goat Software 10
Measures of size Traditional and agile measure size differentlyTraditionalmeasuresof sizeLines of CodeFunction Points Agilemeasuresof sizeStory pointsIdeal days 2003–2009 Mountain Goat Software 11Story pointsAs a user, I want to be ableto have some but not allitems in my cart giftwrapped.8 The “bigness” of a task Influenced by How hard it is How much there is Relative values are what is important: A login screen is a 2. A search feature is an 8. Points are unit-less Basic math properties should hold, e.g., 5 5 10 2003–2009 Mountain Goat Software 12
Zoo pointsAssign “zoopoints” to thefollowing animals 2003–2009 Mountain Goat Software 13One order of magnitude We’re good over one order of magnitude So think about where to place it on yourproduct backlog 2003–2009 Mountain Goat Software 14
2003–2009 Mountain Goat Software 15Ideal time How long something would take if it’s all you worked on Four 15-minute quartersyou had no interruptionsand everything you need is available The ideal time of a football game is 60 minutes The elapsed time is much longer (3 hours) 2003–2009 Mountain Goat Software 16
Ideal time vs. elapsed time It’s easier to estimate in ideal time It’s too hard to estimate directly in elapsedtime Need to consider all the factors that affectelapsed time at the same time you’re estimating 2003–2009 Mountain Goat Software 17Comparing the approaches Story points help drive cross-functional behaviorStory point estimates do not decayStory points are a pure measure of sizeEstimating in story points is typically fasterMy ideal days cannot be added to your ideal daysIdeal days are easier to explain outside the teamIdeal days are easier to estimate at first 2003–2009 Mountain Goat Software 18
Three levels of planning. 2003–2009 Mountain Goat Software 19.three levels of precisionProduct Backlog Iteration Backlog 2003–2009 Mountain Goat Software 20
What I usually do I prefer story points.but they make some teams uncomfortable, so I’ll Start with ideal time Gives the team a nice foundation for the initial storiesHelps team get startedDefine “1 story point 1 ideal day”Then Gradually convert team to thinking in unit-less story points“This story is like that story.”Stop talking about how long it will take 2003–2009 Mountain Goat Software 21 2003–2009 Mountain Goat Software 22
Irrelevant information Irrelevant information has an impact on estimates: Specification length to avoid clearly irrelevant informationUnnecessary detailUnneeded “requirements”It’s importantto acknowledge that we’re all affected by thisto not dilute highly relevant information with informationof marginal valueSource: How to avoid impact from irrelevant and misleading information on your cost estimates,Magne Jørgensen and Stein Grimstad, Simula Research Laboratory,Simula Research Labs Estimation Seminar, Oslo, Norway 2006. 2003–2009 Mountain Goat Software 23Specification lengthGroup A Given a one-page spec. 117 hoursGroup B Given a spec with exactly the sametext but was 7 pages long Increased length achieved through double line space wide margins larger font size more space between paragraphs 173 hoursSource: How to avoid impact from irrelevant and misleading information on your cost estimates,Magne Jørgensen and Stein Grimstad, Simula Research Laboratory,Simula Research Labs Estimation Seminar, Oslo, Norway 2006. 2003–2009 Mountain Goat Software 24
Irrelevant informationGroup A Given project spec. 20 hoursGroup B Given same spec but withestimation-irrelevant details added: 39 hours end users’ desktop applications user passwords, etc.Source: How to avoid impact from irrelevant and misleading information on your cost estimates,Magne Jørgensen and Stein Grimstad, Simula Research Laboratory,Simula Research Labs Estimation Seminar, Oslo, Norway 2006. 2003–2009 Mountain Goat Software 25Extra requirementsGroup A Given requirements R1–R4 4 hoursGroup B Given requirements R1–R5 4 hoursGroup C Given requirements R1–R5 but told to estimate R1–R4 only 8 hours!Source: How to avoid impact from irrelevant and misleading information on your cost estimates,Magne Jørgensen and Stein Grimstad, Simula Research Laboratory,Simula Research Labs Estimation Seminar, Oslo, Norway 2006. 2003–2009 Mountain Goat Software 26
Estimate by analogy Comparing a user story to others “This story is like that story, so its estimate iswhat that story’s estimate was.” Don’t use a single gold standard Triangulate instead Compare the story being estimated to multipleother stories 2003–2009 Mountain Goat Software 27Triangulation Confirm estimates by comparing the story tomultiple other stories.Group like-sized stories on table or whiteboard3pts2pts1pts 2003–2009 Mountain Goat Software 28
Disaggregation Breaking a big story into smaller stories ortasks You know how long the smaller tasks take So, disaggregating to something you know lets youestimate something bigger you don’t know Sometimes very useful But disaggregating too far causes problems Forgotten tasks 2003–2009 Mountain Goat Software 29How much effort?Accuracy A little efforts helps a lot A lot of effort only helps a little moreEffort 2003–2009 Mountain Goat Software 30
Use the right units Can you distinguish a 1-point story from a 2? How about a 17 from an 18? 1, 2, 3, 5, 8, 13, 20, 40, 100 Musical tones and volume are distinguishable on alogarithmic scale Use a set of numbers that make sense; I like: Stay mostly in a 1-10 range Nature agrees: 2003–2009 Mountain Goat Software 31Planning poker An iterative approach to estimating Steps Each estimator is given a deck of cards, each card has a validestimate written on it Customer/Product owner reads a story and it’s discussedbriefly Each estimator selects a card that’s his or her estimateCards are turned over so all can see themDiscuss differences (especially outliers)Re-estimate until estimates converge 2003–2009 Mountain Goat Software 32
Planning poker - an exampleEstimatorSusanVadimAnnChris Round 1Round 238255558 2003–2009 Mountain Goat Software 33 2003–2009 Mountain Goat Software 34Estimate these
Why planning poker works1Jørgensen, Magne. 2004. AReview of Studies on Expert Estimation of Software DevelopmentEffort.2Hagafors, R., and B. Brehmer. 1983. Does Having to Justify One’s Decisions Change the Nature ofthe Decision Process?3Brenner, et al. 1996. On the Evaluation of One-sided Evidence.4Miranda, Eduardo. 2001. Improving Subjective Estimates Using Paired Comparisons.5Saaty, Thomas. 1996. Multicriteria Decision Making: The Analytic Hierarchy Process. 2003–2009 Mountain Goat Software 35Why planning poker works6Hoest, Martin, andClaes Wohlin. 1998. An Experimental Study of Individual Subjective EffortEstimations and Combinations of the Estimates.7Jørgensen, Magne, and Kjetil Moløkken. 2002. Combination of Software DevelopmentEffort Prediction Intervals: Why, When and How? 2003–2009 Mountain Goat Software 36
www.planningpoker.com 2003–2009 Mountain Goat Software 37 2003–2009 Mountain Goat Software 38
Product BacklogIteration Backlog 2003–2009 Mountain Goat Software 39Two approaches1 Velocity-driven iteration planning 2003–2009 Mountain Goat Software 40
2 Commitment-driven iteration planning 2003–2009 Mountain Goat Software 41Estimate availability 2003–2009 Mountain Goat Software 42
It looks something like this 2003–2009 Mountain Goat Software 431time2time 2003–2009 Mountain Goat Software 44
A caution 2003–2009 Mountain Goat Software 45 2003–2009 Mountain Goat Software 46
Release planningRelease plan 2003–2009 Mountain Goat Software 47Velocity To do a release plan, you need to know or havean estimate of velocityThree ways to get velocity:1. Use historical averages2. Run 1-2 iterations and see what you get3. Forecast itShould be expressed as a range Size of range depends on familiarity of team, domain,and technologies 2003–2009 Mountain Goat Software 48
Forecasting velocity Just like commitment-driven iteration planning Estimate available hours for the iterationRepeat until full: Pick a story, break into tasks, estimate each task 2003–2009 Mountain Goat Software 49 2003–2009 Mountain Goat Software 50An example Estimating available hours
An example 2003–2009 Mountain Goat Software 51Updating the release plan Revisit the release plan at the end of everyiteration Update it based on: Current understanding of velocityCurrent prioritization of the product backlog This should be a very short and sweet process 2003–2009 Mountain Goat Software 52
Use actual velocities oncethey’re available40Mean (Best 3) 37Mean (Last 8) 3330Mean (Worst 3) 2820100123456789Iterations 2003–2009 Mountain Goat Software 53Extrapolate from velocityAt our slowest velocity we’ll finish here (5 28)At our long-term average we’ll finish here (5 33)At our best velocity we’ll finish here (5 37) 2003–2009 Mountain Goat Software 54
Upcoming public classesInformationandregistration atoftware.comtsaogintanuom soe al don,rases n LonsalC led iolm.hkudocsche and St,Oslo 2003–2009 Mountain Goat Software 55Mike oftware.com(720) 890 6110twitter: mikewcohn 2003–2009 Mountain Goat Software 56
Agile Estimating and Planning 26 August 2009 Mike Cohn Mike Cohn - background . Mike Cohn mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890 6110 twitter: mikewcohn 55 56. Title: untitled Created Date: 7/18/2009 8:54:43 AM .
