Agile Estimating And Planning - Semantic Scholar

Transcription

Agile Estimatingand PlanningMike CohnDecember 4, 20071Mike Cohn - background Mountain Goat Software, LLC2

Release and sprint planningRelease Plan Mountain Goat Software, LLC3What’s a good plan? A good plan is one that supports reliable decision-makingWill go from We’ll be done in the second quarterWe’ll be done in MarchWe’ll be done March 7th John Maynard Keynes Mountain Goat Software, LLC4

What makes planning agile? Mountain Goat Software, LLC5Agenda Estimating in story points Estimating in ideal time Techniques for estimating Iteration planning Estimating velocity Release planning Mountain Goat Software, LLC6

Mountain Goat Software, LLC7Which we’re talking aboutIteration BacklogIteration 2Iteration 1Product Backlog Mountain Goat Software, LLC8

How long will it take. .to read the latest Harry Potter book? .to drive to Seattle? Mountain Goat Software, LLC9Estimate size; derive duration Mountain Goat Software, LLC10

Measures of size Traditional and agile measure size differentlyTraditionalmeasuresof sizeLines of CodeFunction PointsAgilemeasuresof sizeStory pointsIdeal days Mountain Goat Software, LLC11Story points The “bigness” of a task Influenced by How hard it is How much of it there is 5 Relative values are what is important: A login screen is a 2. A search feature is an 8. Points are unit-less Mountain Goat Software, LLC12

Dog pointsAssign “dogpoints” to thefollowing breeds Mountain Goat Software, LLC Mountain Goat Software, LLC1314

Ideal 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?) Mountain Goat Software, LLC15Elapsed time vs. ideal timeIdeallyBut instead. Mountain Goat Software, LLC16

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 Mountain Goat Software, LLC17Comparing 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 firstIdeal days can force companies to confront timewasting activities Mountain Goat Software, LLC18

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 Mountain Goat Software, LLC19Three levels of planning. Mountain Goat Software, LLC20

.three levels of precisionIteration BacklogIteration 2Iteration 1Product Backlog Mountain Goat Software, LLC Mountain Goat Software, LLC2122

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 Mountain Goat Software, LLC23Triangulation Confirm estimates by comparing the story tomultiple other stories.Group like-sized stories on table or whiteboard3pts2pts1pts Mountain Goat Software, LLC24

Disaggregation Breaking a big story into smaller stories or tasks 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 Summing lots of small errors can be big number Mountain Goat Software, LLC25How much effort?Accuracy A little efforts helps a lot A lot of effort only helps a little moreEffort Mountain Goat Software, LLC26

Use the right units Can you distinguish a 1-point story from a 2? Can you distinguish a 17 from an 18? Use units that make sense, such as 1, 2, 3, 5, 8, 131, 2, 4, 8 Stay mostly in a 1-10 range Mountain Goat Software, LLC27Planning 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 Mountain Goat Software, LLC28

Planning poker - an exampleEstimatorSusanVadimAnnChrisRound 1Round 238255558 Mountain Goat Software, LLC29Estimate these Mountain Goat Software, LLC30

Why planning poker works Emphasizes relative estimating Focuses most estimates within an approximateone order of magnitude Everyone’s opinion is heard Estimators are required to justify estimates It’s quick It’s fun Mountain Goat Software, LLC31www.planningpoker.com Mountain Goat Software, LLC32

Mountain Goat Software, LLCIteration BacklogIteration 2Iteration 1Product Backlog33 Mountain Goat Software, LLC34

Two approaches Velocity-driven iteration planning “We finished 15 story points last time, let’s planon 15 story points this time.” Very unreliable in what will be accomplishedduring an iteration Velocity is mostly useful over the long term Commitment-driven iteration planning More likely to lead to realistic iterationcommitments Mountain Goat Software, LLC35Commitment-driven iteration planning Discuss the highest priority item on the productbacklog Decompose it into tasks Estimate each task Whole team estimates each task Ask ourselves, “Can we commit to this?” If yes, see if we can add another backlog item If not, remove this item but see if we can add anothersmaller one Mountain Goat Software, LLC36

Commitment-driven iteration planning Discuss the highest priority item on the productbacklog Decompose it into tasks Estimate each task Whole team estimates each task Ask ourselves, “Can we commit to this?” If yes, see if we can add another backlog item If not, remove this item but see if we can add anothersmaller one Mountain Goat Software, LLC37Estimate availability Mountain Goat Software, LLC38

It looks something like this Mountain Goat Software, LLC391time2time Mountain Goat Software, LLC40

Mountain Goat Software, LLC41How to estimate velocity Mountain Goat Software, LLC42

Forecasting velocity Just like commitment-driven sprint planning Estimate available hours for the sprintRepeat until full: Pick a story, break into tasks, estimate each task Mountain Goat Software, LLC43An example Estimating available hours Mountain Goat Software, LLC44

An example Mountain Goat Software, LLC45Put a range around it You’re unlikely to have precisely forecasted theexact velocity the team will average So, put a range around your velocity estimate:Known team andknown domainUnknown team orunknown domain 5% 10% 10% 25% 25% 50%†Numbers based on PMI advice on progressive accuracyof estimates. Mountain Goat Software, LLC46

Expressing velocity as a range1.10.75Adjustmentsfrom prior pageor intuitionTotal ofestimates onproduct backlog Mountain Goat Software, LLC Mountain Goat Software, LLC4748

Release planningRelease Plan Mountain Goat Software, LLC49Updating 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 Mountain Goat Software, LLC50

Track velocity multiple ways40Last Observation 36Mean (Last 8) 3330Mean (Worst 3) 282010012345Iterations6789 Mountain Goat Software, LLC51Extrapolate from velocityAt our slowest velocity we’ll finish here (5 28)At our long-term average we’ll finish here (5 33)At current velocity we’ll finish here (5 36) Mountain Goat Software, LLC52

Fixed-date planning1. Determine how many sprints you have2. Estimate velocity as a range3. Multiply low velocity number of sprints Count off that many points These are “Will Have” items4. Multiply high velocity number of sprints Count off that many more points These are “Might Have items” Mountain Goat Software, LLC53Fixed-date planning: an exampleWill have6 15Might have6 20Won’t have Mountain Goat Software, LLC54

A fixed-date plan1. Using the product backlog on the next page, determinewhich backlog items your team (Sergei,Yuri, and Carina)can commit to delivering in five iterations.2. The product backlog has been prioritized by yourproduct owner (me).3. Members of this team have worked together in variouscombinations in the past but not recently so they don’thave a historical velocity4. They know the technologies well and the domain isfamiliar.5. The team has already held their first iteration planningmeeting. Results are on the next page.6. Reminder: Make velocity a range! Mountain Goat Software, LLC55Intentionally blank Mountain Goat Software, LLC56

Results of sprint planning Mountain Goat Software, LLC Mountain Goat Software, LLC5758

Upcoming public classes Mountain Goat Software, LLC59Mike Cohn contact info Mountain Goat Software, LLC60

Agile Estimating and Planning Mike Cohn December 4, 2007 Mike Cohn - background Mountain Goat Software, LLC 1 2