Agile Planning
Upcoming SlideShare
Loading in...5
×
 

Agile Planning

on

  • 1,253 views

http://agiledays.ru

http://agiledays.ru

Statistics

Views

Total Views
1,253
Views on SlideShare
1,200
Embed Views
53

Actions

Likes
4
Downloads
29
Comments
0

4 Embeds 53

http://www.agiledays.ru 29
http://agiledays.ru 22
http://www.lmodules.com 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile Planning Agile Planning Document Transcript

    • 24.11.2009 Agile Planning Artem Marchenko AgilDays.ru, December 9, 2009 © 2003–2009 Artem Marchenko and Mountain Goat Software® Artem Marchenko - background © 2003–2009 Artem Marchenko and Mountain Goat Software® 1
    • 24.11.2009 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® 2
    • 24.11.2009 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® 3
    • 24.11.2009 Release and sprint planning Release Plan Sprint Sprint Sprint Sprints 4–7 1 2 3 Task A 8 hours Task B 16 hours Task C 5 hours Task D 8 hours © 2003–2009 Artem Marchenko and Mountain Goat Software® Agenda • Sprint planning • Estimating velocity • Release planning • Contracting on fixed-date & fixed-scope projects © 2003–2009 Artem Marchenko and Mountain Goat Software® 4
    • 24.11.2009 © 2003–2009 Artem Marchenko and Mountain Goat Software® Two approaches • Velocity-driven sprint planning • Commitment-driven sprint planning © 2003–2009 Artem Marchenko and Mountain Goat Software® 5
    • 24.11.2009 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® 6
    • 24.11.2009 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® 1 2 time time © 2003–2009 Artem Marchenko and Mountain Goat Software® 7
    • 24.11.2009 © 2003–2009 Artem Marchenko and Mountain Goat Software® How to estimate velocity 1 Use historical values 2 Don’t, until you’ve run a sprint or two 3 Forecast it © 2003–2009 Artem Marchenko and Mountain Goat Software® 8
    • 24.11.2009 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 • Estimating available hours Person Hours per Day Hours per Sprint Sergey 4-6 40-60 Kimmo 5-7 50-70 Jarmo 2-3 20-30 Total 110-160 © 2003–2009 Artem Marchenko and Mountain Goat Software® 9
    • 24.11.2009 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® 10
    • 24.11.2009 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® © 2003–2009 Artem Marchenko and Mountain Goat Software® 11
    • 24.11.2009 Create a range from historical data Mean (Best 3) = 37 Mean (Last 8) = 33 Mean (Worst 3) = 28 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® 12
    • 24.11.2009 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® 13
    • 24.11.2009 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® 14
    • 24.11.2009 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 planning: an example Total story points desired 120 Low velocity 15 High velocity 20 120÷20= 120÷15= © 2003–2009 Artem Marchenko and Mountain Goat Software® 15
    • 24.11.2009 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® 16
    • 24.11.2009 Artem Marchenko contact info artem.marchenko@gmail.com http://AgileSoftwareDevelopment.com http://twitter.com/AgileArtem © 2003–2009 Artem Marchenko and Mountain Goat Software® 17