Your SlideShare is downloading. ×
0
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
 Agile Estimating and Planning
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Estimating and Planning

4,895

Published on

Published in: Business, Technology, Sports
2 Comments
23 Likes
Statistics
Notes
  • @Chintan Patel Thanks. You can see how to forecast velocity when team size is changing in the last section of the presentation here: https://www.mountaingoatsoftware.com/presentations/advanced-topics-in-agile-planning That is also video recorded so you can watch the video. Note that the technique does require you to have some data--but that shouldn't be surprising. You won't be able to just magically make up an answer. Good luck.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Very informative article Mike Cohn. However i have question over the scenario shared below, would appreciate your answer to that. I have a team of 6 people (1 iOS client dev, 1 Web client dev, 1 API, 1 BA, 2 QA) working on a single product build on two platform. The team velocity is say 20 story points. I have defined the Product roadmap for next 3 months using these sprint velocity. Now there is a business requirement to have that developed withing 2 months. The way to achieve this is to increase the velocity of the team which means adding more resources to the team. Is there an agile way to identify the additional no. of resources needed with needed skills? Or i would have to go ahead and do analysis based on traditional method to identify the effort hours needs for each stories for each platform and based on that identify the no. of resources needed and from which dept. I am finding it difficult to identify the no. of resources needed upfront as we are not detailing out the next 3 month roadmap upfront and identify the effort needed.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
4,895
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
445
Comments
2
Likes
23
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. © 2009 Mountain Goat Software© Copyright Mountain Goat Software®Agile EstimatingandPlanningMike Cohnmike@mountaingoatsoftware.comJune 8, 20101
  • 2. © Copyright Mountain Goat Software®®Mike CohnFounding member anddirector of Agile Allianceand Scrum AllianceFounder of MountainGoat SoftwareDoing Scrum since 1995Started my career as aprogrammer; worked asVP Engineering in 4companies2
  • 3. © Copyright Mountain Goat Software®®ScrumCancelGift wrapReturnSprint2-4 weeksReturnSprint goalSprintbacklogPotentially shippableproduct incrementProductbacklogCouponsGift wrapCouponsCancel24 hours3
  • 4. © Copyright Mountain Goat Software®®What’s a good plan?A good plan is one that supports reliabledecision-makingWill go fromWe’ll be done in the third quarterWe’ll be done in AugustWe’ll be done August 18thJohn Maynard Keynes“It’s better to be roughly rightthan precisely wrong.”4
  • 5. © Copyright Mountain Goat Software®®What makes planning agile?Is more focused onplanning than the planEncourages changeResults in plans that areeasily changedIs spread throughout theproject5
  • 6. © Copyright Mountain Goat Software®®Product, release, iteration planningRelease Plan8 hoursTask A16 hoursTask B5 hoursTask C8 hoursTask DIteration 1 Iteration 2 Iteration 3 Iteration 4–7Release 1 Release 2 Release 3We’ll focushere today6
  • 7. © Copyright Mountain Goat Software®®AgendaProduct backlog estimationunitsStory pointsIdeal timeTechniques for estimatingIteration planningRelease planning7
  • 8. © Copyright Mountain Goat Software®®want to…3want to…5want to…5want to…8want to…5Code the UI 86Code middle tier 12Write tests 5Automate tests 4Product Backlog Iteration BacklogWe’re talkingabout theseright now8
  • 9. © Copyright Mountain Goat Software®®How long will it take......to read the latestHarry Potter book?...to drive toMilwaukee?9
  • 10. © Copyright Mountain Goat Software®®Estimate size; derive durationSize Calculation Duration300kilogramsVelocity =20300/20 =15 iterations10
  • 11. © Copyright Mountain Goat Software®®Measures of sizeTraditional and agile measure size differentlyTraditionalmeasuresof sizeLines of CodeFunction PointsAgilemeasuresof sizeStory pointsIdeal days11
  • 12. © Copyright Mountain Goat Software®®Story pointsThe “bigness” of a taskHow hard it isHow much there isRelative values are what is important:A login screen is a 2.A search feature is an 8.Points are unit-lessBasic math properties should hold, e.g., 5+5 = 10As a user, I want to beable to have some but notall items in my cart giftwrapped.812
  • 13. © Copyright Mountain Goat Software®®Dog pointsAssign “dog points” to the following breeds.Labrador retrieverDachshundGreat DanePoodleGerman ShepherdTerrierSt. BernardBulldog13
  • 14. © Copyright Mountain Goat Software®®One order of magnitudeWe’re good over one order of magnitudeSo think about where to place it on yourproduct backlogA typo1 10The largestnew feature14
  • 15. © Copyright Mountain Goat Software®®AgendaProduct backlog estimationunitsStory pointsIdeal timeTechniques for estimatingIteration planningRelease planning15
  • 16. © Copyright Mountain Goat Software®®Ideal timeHow long something would take ifit’s all you worked onyou had no interruptionsand everything you need is availableThe ideal time of a football game is 60minutesFour 15-minute quartersThe elapsed time is much longer (3+ hours)16
  • 17. © Copyright Mountain Goat Software®®Ideal time vs. elapsed timeIt’s easier to estimate in ideal timeIt’s too hard to estimate directly in elapsedtimeNeed to consider all the factors that affectelapsed time at the same time you’reestimating17
  • 18. © Copyright Mountain Goat Software®®Comparing the approachesStory 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 days18
  • 19. © Copyright Mountain Goat Software®®Three levels of planning…Release plan…Iteration planDailyplanDailyplanDailyplan…Iteration planDailyplanDailyplanDailyplan…19
  • 20. © 2009 Mountain Goat Software© Copyright Mountain Goat Software®®…three levels of precisionwant to…3want to…5want to…5want to…2want to…2Code the UI 86Code middle tier 12Write tests 5Automate tests 4“Yesterday I started on theend of today.”305050202020
  • 21. © Copyright Mountain Goat Software®®What I usually doI prefer story points, but they make some teamsuncomfortable, so I’llStart with ideal timeGives the team a nice foundation for the initial storiesHelps team get startedThenGradually convert team to thinking in unit-less story points“This story is like that story.”Stop talking about how long it will take21
  • 22. © Copyright Mountain Goat Software®®AgendaProduct backlog estimationunitsStory pointsIdeal timeTechniques for estimatingIteration planningRelease planning22
  • 23. © Copyright Mountain Goat Software®®Estimate by analogyComparing 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 standardTriangulate insteadCompare the story being estimated tomultiple other stories23
  • 24. © Copyright Mountain Goat Software®®Triangulationother stories.Group like-sized stories on table or whiteboard3points2points1pointStory AStory CStory B Story EStory D Story F24
  • 25. © Copyright Mountain Goat Software®®DisaggregationBreaking a big story into smaller stories ortasksYou know how long the smaller tasks takeSo, disaggregating to something you know letsyou estimate something bigger you don’t knowSometimes very usefulBut disaggregating too far causes problemsForgotten tasks25
  • 26. © 2009 Mountain Goat Software© Copyright Mountain Goat Software®®How much effort?A little efforts helps a lotA lot of effort only helps a little moreEffortAccuracy26
  • 27. © Copyright Mountain Goat Software®®Can you distinguish a 1-point story from a 2?How about a 17 from an 18?Use a set of numbers that make sense; I like:1, 2, 3, 5, 8, 13Stay mostly in a 1-10 rangeNature agrees:Musical tones and volume are distinguishableon a logarithmic scaleUse the right units, 20, 40, 100Include 0and ½ ifyou want27
  • 28. © Copyright Mountain Goat Software®®Planning Poker®An iterative approach to estimatingStepsEach estimator is given a deck of cards, each card has avalid estimate written on itCustomer/Product owner reads a story and it’sEach 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 converge28
  • 29. © Copyright Mountain Goat Software®®Planning Poker®Estimator Round 1Vadim 8Susan 3Ann 2Chris 5Round 2555829
  • 30. © Copyright Mountain Goat Software®®Estimate theseProduct backlog item EstimateARead a high-level, 10-page overview of agile softwaredevelopment in People magazine.BRead a densely written 5-page research paper about agilesoftware development in an academic journal.CWrite the product backlog for a simple eCommerce sitethat sells only clocks.D Recruit, interview, and hire a new member for your team.ECreate a 60-minute presentation about agile softwaredevelopment for your coworkers.FG Read a 150-page book on agile software development.HWrite an 8-page summary of this conference for yourboss.30
  • 31. © Copyright Mountain Goat Software®®Why Planning Poker worksThose who will do the work, estimate thework1Estimators are required to justify estimates2, 3one order of magnitude4, 51Jørgensen, Magne. 2004. A Review of Studies on Expert Estimation of SoftwareDevelopment Effort.2Hagafors, R., and B. Brehmer. 1983. Does Having to Justify One’s Decisions Changethe Nature of the Decision Process?3Brenner, et al. 1996. On the Evaluation of One-sided Evidence.4Miranda, Eduardo. 2001. Improving Subjective Estimates Using PairedComparisons.5Saaty,Thomas. 1996. Multicriteria Decision Making:The Analytic Hierarchy Process.31
  • 32. © Copyright Mountain Goat Software®®Why Planning Poker worksCombining of individual estimates6 through groupdiscussion7 leads to better estimatesEmphasizes relative rather than absolute estimatingEstimates are constrained to a set of values so wedon’t waste time in meaningless argumentsEveryone’s opinion is heardIt’s quick and fun6Hoest, Martin, and Claes Wohlin. 1998. An Experimental Study of IndividualSubjective Effort Estimations and Combinations of the Estimates.7Jørgensen, Magne, and Kjetil Moløkken. 2002. Combination of SoftwareDevelopment Effort Prediction Intervals:Why,When and How?32
  • 33. © Copyright Mountain Goat Software®®www.PlanningPoker.comFree,or Iwouldn’tmention it33
  • 34. © Copyright Mountain Goat Software®®AgendaProduct backlog estimationunitsStory pointsIdeal timeTechniques for estimatingIteration planningRelease planning34
  • 35. © Copyright Mountain Goat Software®®want to…3want to…5want to…5want to…8want to…5Code the UI 86Code middle tier 12Write tests 5Automate tests 4Product Backlog Iteration BacklogTasks HoursCreating thislist is iterationplanning35
  • 36. © Copyright Mountain Goat Software®®Two approachesTwo approachesVelocity-driven iteration planningstory points this time.”Very unreliable in what will be accomplished duringan iterationVelocity is mostly useful over the long term136
  • 37. © Copyright Mountain Goat Software®®Commitment-driven iteration planningDiscuss the highest priority item on the productbacklogDecompose it into tasksEstimate each taskWhole team estimates each taskAsk ourselves,“Can we commit to this?”If yes, see if we can add another backlog itemIf not, remove this item but see if we can addanother smaller one237
  • 38. © Copyright Mountain Goat Software®®Estimate personal availabilityhow many hours each person has availableFor later iterations, we’ll make adjustments towhat we did this time rather than start overPerson Hours/Day Hours / IterationSergey 4–6 40–60Yuri 5–7 50–70Carina 2–3 20–30TTotal 110–16038
  • 39. © Copyright Mountain Goat Software®®It looks something like thisAs a user, I want…2Code the abc class (8 hours)Code the user interface (4)Update performance tests (4)The team can commit, so they continue…Prototype the UI (8 hours)Demo UI to 3 outside users (3)Code new UI (12)Update documentation (3)As a user, I want…339
  • 40. © 2009 Mountain Goat Software© Copyright Mountain Goat Software®®time12time40
  • 41. © Copyright Mountain Goat Software®®A cautionThe purpose of the iteration planningmeeting is to arrive at a commitment toan iteration goal or set of productbacklog items.The purpose of the meeting is not tocome up with a list of tasks and hours.The tasks and estimates are a tool fordetermining what we can commit to.41
  • 42. © Copyright Mountain Goat Software®®AgendaProduct backlog estimationunitsStory pointsIdeal timeTechniques for estimatingIteration planningRelease planning42
  • 43. © Copyright Mountain Goat Software®®Release planningRelease Planning MeetingRelease planIteration 1 Iteration 2 Iteration 3Iterations4–743
  • 44. © Copyright Mountain Goat Software®®VelocityTo do a release plan, you need to know orhave an estimate of velocityThree ways to get velocity:1. Use historical averages2. Run 1-2 iterations and see what you get3. Forecast itSize of range depends on familiarity of team,domain, and technologies44
  • 45. © Copyright Mountain Goat Software®®Forecasting velocityJust like commitment-driven iterationplanningEstimate available hours for the iterationRepeat until full:Pick a story, break into tasks, estimate each task45
  • 46. © Copyright Mountain Goat Software®®Person Hours/DayAvailable Hours /IterationSergey 4–6 40–60Yuri 5–7 50–70Carina 2–3 20–30ToTotal 110–16046
  • 47. © Copyright Mountain Goat Software®®What is the velocity if this team canwork 110–160 hours per iteration?As a frequentAs a visitor, Ican…As a vacationplanner, I can…As a frequent3552Code…Design…Document…Decide…12888Analyze… 4Automate… 8 … 48Code…Test…Design…Test…86125… 2231484822Story Points47
  • 48. © Copyright Mountain Goat Software®®Predicting release contentsDetermine your median velocityPredicts “best case” and “worst case”010203040501 2 3 4 5 6 7 8 948
  • 49. © Copyright Mountain Goat Software®®273435383940404145Medianintervalteam’s historical velocity data.SortedVelocities # ofHistoricalIterationsnth Highest& LowestIteration toUse5 18 211 313 416 518 621 723 826 9ofiterationsifyoudon’thaveUse the online velocity range calculator atwww.mountaingoatsoftware.com/tools49
  • 50. © 2009 Mountain Goat Software© Copyright Mountain Goat Software®®At our median velocity we’ll get here (5×39)We’ll almost certainly get here (5×34)(5×41)Assume:There are fiveiterations left.50
  • 51. © Copyright Mountain Goat Software®®Mike Cohnmike@mountaingoatsoftware.comwww.mountaingoatsoftware.comtwitter: mikewcohn(720) 890−611051

×