Agile Planning

What’s a good plan? • A good plan is one that supports reliable decision-making • Will go from • We’ll be done in the third quarter • We’ll be done in August • We’ll be done August 18th © 2003–2009 Artem Marchenko and Mountain Goat Software®

What makes planning agile? Is more focused on planning than the plan Encourages change Results in plans that are easily changed Is spread throughout the project © 2003–2009 Artem Marchenko and Mountain Goat Software®

Starting assumptions • We have a product backlog (prioritized feature list) • Items on the product backlog (user stories is my preference) have been estimated in story points or ideal days • We have a team with a known velocity • We’ll relax this assumption shortly © 2003–2009 Artem Marchenko and Mountain Goat Software®

An example with velocity=14 Story A Story F Sprint 1 Sprints 3-4 5 5 Story B Story G 8 1 Story C Story H Sprint 2 3 13 Story D Story I 5 5 Story E Story J 1 8 © 2003–2009 Artem Marchenko and Mountain Goat Software®

Velocity-driven sprint planning • “We finished 15 story points last time, let’s plan on 15 story points this time.” • Very unreliable in what will be accomplished during an iteration • Velocity is mostly useful over the long term © 2003–2009 Artem Marchenko and Mountain Goat Software®

Commitment-driven sprint planning • Discuss the highest priority item on the product backlog • Decompose it into tasks • Estimate 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 another smaller one. Possibly by splitting the original story © 2003–2009 Artem Marchenko and Mountain Goat Software®

It looks something like this As a user, I want ... • Code the abc class (8 hours) • Code the user interface (4) • Write test fixtures (4) 26 • Code the xyz class (6) 2 • Update performance tests (4) Team can commit, so they continue... As a user, I want ... • Prototype the UI (8 hours) • Demo UI to 3 outside users (3) • Code new UI (12) 26 • Update documentation (3) 3 © 2003–2009 Artem Marchenko and Mountain Goat Software®

Forecasting velocity • Just like commitment-driven sprint planning • Estimate available hours for the sprint • Repeat until full: • Pick a story, break into tasks, estimate each task © 2003–2009 Artem Marchenko and Mountain Goat Software®

An example At 110-160 available hours per sprint, what is the team’s velocity? Code the ... 12 Code the UI 8 Do the... 8 As a frequent flyer, I Write test fixture 6 48 Document the... 8 want to... 3 31 Code middle tier 12 Test the... 8 Write tests 5 Analyze the... 4 As a user, I want to... 5 Document ... 8 As a vacation planner, I want to... 5 50 ... 50 As a frequent flyer, I 20 ... 20 want to... 2 © 2003–2009 Artem Marchenko and Mountain Goat Software®

Put a range around it • You’re unlikely to have precisely forecasted the exact velocity the team will average • So, put a range around your velocity estimate: Known team, domain, +5% technology −10% +10% −25% Unknown team, +25% domain, technology −50% †Numbers based on PMI advice on progressive accuracy of estimates. © 2003–2009 Artem Marchenko and Mountain Goat Software®

Expressing velocity as a range 1.10 20 200 ÷ 20 = 10 Estimated velocity = 18 .75 14 200 ÷ 14 = 15 Adjustments Total of from prior page estimates on or intuition product backlog “Right now, before we start this project, our best estimate is that it will take between 10 and 15 sprints.” © 2003–2009 Artem Marchenko and Mountain Goat Software®

Predicting where we finish At 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 Artem Marchenko and Mountain Goat Software®

Planning on contracted projects Fixed-date projects Fixed-scope projects A caveat • There are times you need to do this • So let’s look at some good techniques • Better though is try for a collaborative relationship with your customer • “You’ll have this team for each sprint, can direct them at the start of each, and stop when you have enough” © 2003–2009 Artem Marchenko and Mountain Goat Software®

Fixed-date planning How much can I get by <date>? 1. Determine how many sprints you have 2. Estimate velocity as a range 3. Multiply low velocity × number of sprints • Count off that many points • These are “Will Have” items 4. Multiply high velocity × number of sprints • Count off that many more points • These are “Might Have items” © 2003–2009 Artem Marchenko and Mountain Goat Software®

Fixed-date planning: an example Desired 30 June release date Will have Today’s Date 1 January Number of 6×15 6 (monthly) Might sprints have Low 6×20 15 velocity High 20 Won’t have velocity © 2003–2009 Artem Marchenko and Mountain Goat Software®

Fixed-date contracting If you write a contract for just the will haves: • You won’t likely win the contract Will have • But you’ll probably make money if you do 6×15 If you write a contract that Might includes the might haves: have • You will likely win the contract 6×20 • But probably not make money on it Won’t have It’s a risk issue Where do you want to be? © 2003–2009 Artem Marchenko and Mountain Goat Software®

Fixed-scope planning When will all of this be done? 1. Sum all the backlog items the customer needs 2. Estimate velocity as a range 3. Divide total story points by high velocity • This is the shortest number of sprints it could take 4. Divide total story points by low velocity • This is the “most” sprints it could take © 2003–2009 Artem Marchenko and Mountain Goat Software®

Fixed-scope contracting If you write a contract for the short duration: • You’ll likely win the contract • But may not make any money If you write a contract for the long duration: • You probably won’t win the contract • But will make money if you It’s a risk issue Where do you want to be? © 2003–2009 Artem Marchenko and Mountain Goat Software®

Ranges • Notice in both cases we had a range • For a fixed date project, use a scope range: • “By that date you’ll have all of these features and some of these.” • For a fixed-scope project, use a date range: • “It will take us between 5 and 8 sprints to deliver all of those features.” © 2003–2009 Artem Marchenko and Mountain Goat Software®

http://agileee.org	130
http://lib.custis.ru	38
http://team.custis.ru	36
http://www.slideshare.net	12
http://wiki.office.custis.ru	2

Agile Planning

by Agileee on Oct 12, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 218

Statistics

Agile Planning — Presentation Transcript