Planning and Tracking Agile Projects

"Agile teams don't plan.” At least that’s what some people say. In this session we’ll blow that myth out of the water by looking at how agile teams do plan. Along the way you’ll see why story points have become the most popular unit for estimating work on agile teams. You’ll hear how the popular Planning Poker technique along with story points help eliminate common estimating problems. You’ll also gain insights into predicting project completion using velocity and confidence intervals, including how to plan a fixed-date agile project. Also covered will be three issues all teams need to address on large, multi-team projects.

View Mike giving this presentation at Google available in two parts: part one and part two.

Transcript

1. Planning and Tracking Agile Projects 1
2. Founding member and director of Agile Alliance, Scrum Alliance, and Agile Project Leadership Network Founder of Mountain Goat Software Consultant, author, and speaker Mike Cohn - background © Mountain Goat Software, LLC 2
3. © Mountain Goat Software, LLC Imagine... J That you’re fed up with software development as a career J And you decide to go into the landscaping business J -=C@
   Q@AB
   8=0
   7A
   moving this pile of rock from the front of my house to the back 3
4. © Mountain Goat Software, LLC How might you estimate this? J One way: J Look at the pile of rock and estimate how many wheelbarrow loads it represents J After an hour, see how many wheelbarrow loads you’ve moved then extrapolate the total duration JI think that’s 80 wheelbarrow loads JAfter an hour I’ve moved 20 loads JSo, I’ll be done in a total of 4 hours 4
5. © Mountain Goat Software, LLC My landscaping 0 20 40 60 80 0900 1000 1100 1200 1300 Wheelbarrow Loads Time 5
6. © Mountain Goat Software, LLC 2 2 3 3 3 2 JAn iteration is a short, constrained period of time JTypically 1-4 weeks 2 4 3 2 1 2 2 2 3 3 3 2 A release typically comprises more than one iteration Velocity is the amount of work planned or completed in an iteration. 6
7. © Mountain Goat Software, LLC Strategy Portfolio Product Release Iteration The planning onion Daily • Agile teams plan at the innermost three levels. • Others (on the team in the company) plan at the outer levels. 7
8. © Mountain Goat Software, LLC Relating the different planning levels A
   /
   4@3?C3<B
   RG3@
   I want to... A
   /
   4@3?C3<B
   RG3@
   I want to... A
   /
   4@3?C3<B
   RG3@
   I want to... A
   /
   4@3?C3<B
   RG3@
   I want to... A
   /
   4@3?C3<B
   RG3@
   I want to... 3 5 5 2 2 Iteration 2 Iteration 1 “Yesterday I started on the UI; I should Q<7A6
   034=@3
   B63
   3<2
   of today.” Code the UI 8 ,@7B3
   B3AB
   QFBC@3 6 Code middle tier 12 Write tests 5 Automate tests 4 Product Backlog Iteration Backlog 8
9. © Mountain Goat Software, LLC Iteration Conditions of Satisfaction (scope) An agile approach to planning Release Conditions of Satisfaction (scope, schedule, resources) Release planning Iteration planning Feedback Feedback Development Product increment 9
10. © Mountain Goat Software, LLC Estimating Release planning Burndown charts Agenda 10
11. © Mountain Goat Software, LLC Story points J Probably the most commonly used estimating unit among agile teams today J Name is derived from agile teams commonly expressing requirements as “user stories” J Based on a combination of the size and complexity of the work J Unitless but numerically relevant estimates J A 10-point user story is expected to take twice as long as a 5-point user story 11
12. © Mountain Goat Software, LLC Consider these two piles of work What story point values might we put on these? 12
13. © Mountain Goat Software, LLC Zoo points Assign “zoo points” to the following breeds Lion Kangaroo Rhinocerus Bear Giraffe Gorilla Hippopotamus Tiger 13
14. © Mountain Goat Software, LLC Three key advantages J Estimating in story points: 1. Forces the use of relative estimating J Studies have shown we’re better at this† 2. Focuses us on estimating the size, not the duration J We derive duration empirically by seeing how much we complete per iteration 3. Puts estimates in units that we can add together J Time based estimates are not additive †Lederer and Prasad, 1998. A Causal Model for Software Cost Estimating Error and Vicinanza et al., 1991. Software Effort Estimation: An Exploratory Study of Expert Performance. 14
15. © Mountain Goat Software, LLC “Yesterday I started on the UI; I should Q<7A6
    034=@3
    B63
    3<2
    of today.” Comparing apples to apples A
    /
    4@3?C3<B
    RG3@
    I want to... A
    /
    4@3?C3<B
    RG3@
    I want to... A
    /
    4@3?C3<B
    RG3@
    I want to... A
    /
    4@3?C3<B
    RG3@
    I want to... A
    /
    4@3?C3<B
    RG3@
    I want to... 3 5 5 2 3 Code the UI 8 ,@7B3
    B3AB
    QFBC@3 6 Code middle tier 12 Write tests 5 Automate tests 4 Product Backlog Sprint Backlog 30 50 50 20 20 15
16. © Mountain Goat Software, LLC Planning poker for estimating JAn iterative approach to estimating, loosely based on wideband Delphi JSteps 1. Each estimator is given a deck of cards, each card has a valid estimate written on it 2. Customer/Product owner reads a story and it’s discussed 0@73RG 3. Each estimator selects a card that’s his or her estimate 4. Cards are turned over so all can see them 5. Discuss differences (especially outliers) 6. Re-estimate until estimates converge 16
17. © Mountain Goat Software, LLC Planning poker - an example Estimator Round 1 Round 2 Susan Vadim Ann Chris 3 5 8 5 2 5 5 8 20 13 8 5 3 2 1 17
18. © Mountain Goat Software, LLC Estimate these Product backlog item Estimate Read a high-level, 10-page overview of agile software development in People magazine. Read a densely written 5-page research paper about agile software development in an academic journal. Write the product backlog for a simple eCommerce site that sells only clocks. Recruit, interview, and hire a new member for your team. Create a 60-minute presentation about agile estimating and planning for your coworkers. Wash and wax your boss’ Porsche. Read a 150-page book on agile software development. Write an 8-page summary of that book for your boss. 18
19. © Mountain Goat Software, LLC Why planning poker works JThose who will do the work, estimate the work1 J Estimators are required to justify estimates2, 3 J Focuses most estimates within an approximate one order of magnitude4, 5 1Jørgensen, Magne. 2004. A Review of Studies on Expert Estimation of Software Development Effort. 2Hagafors, R., and B. Brehmer. 1983. Does Having to Justify One’s Decisions Change the Nature of the 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. 19
20. © Mountain Goat Software, LLC Why planning poker works JCombining of individual estimates6 through group discussion7 leads to better estimates J Emphasizes relative rather than absolute estimating J Estimates are constrained to a set of values so we don’t waste time in meaningless arguments J Everyone’s opinion is heard J It’s quick and fun 6Hoest, Martin, and Claes Wohlin. 1998. An Experimental Study of Individual Subjective Effort Estimations and Combinations of the Estimates. 7Jørgensen, Magne, and Kjetil Moløkken. 2002. Combination of Software Development Effort Prediction Intervals: Why, When and How? 20
21. © Mountain Goat Software, LLC Reduces impact of irrelevant information J Given project spec. Group A J Given same spec but with estimation-irrelevant details added: J end users’ desktop applications J user passwords, J etc. Group B J 39 hours J 20 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. 21
22. © Mountain Goat Software, LLC (>317Q1/B7=<
    :3<5B6 J Given a one-project spec. Group A J Given a spec with exactly the same text but was 7 pages long J Increased length achieved through J double line space J wide margins J larger font size J more space between paragraphs Group B J 173 hours J 117 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. 22
23. © Mountain Goat Software, LLC Extra requirements J Given requirements R1–R4 Group A J Given requirements R1–R5 Group B J 4 hours J 4 hours J Given requirements R1–R5 J but told to estimate R1–R4 only Group C J 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. 23
24. © Mountain Goat Software, LLC Reduces likelihood of anchoring J Given a product spec Control group J 456 hours J Given the same product spec J Told the customer thinks 500 hours is a reasonable estimate but that J The customer knows very little about the implications of his spec on the estimate J -=C
    A6=C:2<PB
    :3B
    67A
    <C;03@
    7<RC3<13
    G=C High anchor group J 555 hours J Same as high but customer thinks 50 hours Low anchor group J 99 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. 24
25. © Mountain Goat Software, LLC Estimating Release planning Burndown charts Agenda 25
26. © Mountain Goat Software, LLC Release planning To answer questions such as: J How much will be done by 30 June? J When can we ship with this set of features? J How many people or teams should be on this project? Purpose J Velocity J The length of the project J Prioritized product backlog Inputs 26
27. © Mountain Goat Software, LLC Iteration 3-4 An example with velocity=14 Iteration 1 Story A 5 Story B 8 Story E 1 Story C 3 Story D 5 Story F 5 Story G 1 Story H 13 Story I 5 Story J 8 Story A 5 Story B 8 Story E 1 Iteration 2 Story C 3 Story D 5 Story F 5 Story G 1 Story H 13 Story I 5 Story J 8 27
28. © Mountain Goat Software, LLC Updating the release plan 0 10 20 30 40 1 2 3 4 5 6 7 8 9 Iterations Mean (Worst 3) = 28 Mean (Last 8) = 33 Last Observation = 36 J Use multiple views of observed velocity 28
29. © Mountain Goat Software, LLC Extrapolate from velocity B
    =C@
    :=<5B3@;
    /D3@/53
    E3P::
    Q<7A6
    63@3 B
    =C@
    A:=E3AB
    D3:=17BG
    E3P::
    Q<7A6
    63@3 B
    1C@@3<B
    D3:=17BG
    E3P::
    Q<7A6
    63@3 29
30. © Mountain Goat Software, LLC Estimating Release planning Burndown charts Agenda 30
31. © Mountain Goat Software, LLC How’s my landscaping coming? 0 20 40 60 80 0900 1000 1100 1200 1300 Wheelbarrow Loads Time This is called a burndown chart. 31
32. © Mountain Goat Software, LLC Remember the different levels? A
    /
    4@3?C3<B
    RG3@
    I want to... A
    /
    4@3?C3<B
    RG3@
    I want to... A
    /
    4@3?C3<B
    RG3@
    I want to... A
    /
    4@3?C3<B
    RG3@
    I want to... A
    /
    4@3?C3<B
    RG3@
    I want to... 3 5 5 2 2 Iteration 2 Iteration 1 “Yesterday I started on the UI; I should Q<7A6
    034=@3
    B63
    3<2
    of today.” Code the UI 8 ,@7B3
    B3AB
    QFBC@3 6 Code middle tier 12 Write tests 5 Automate tests 4 Product Backlog Iteration Backlog We can track burndown at both levels 32
33. © Mountain Goat Software, LLC An iteration burndown chart 0 200 400 600 800 1,000 4/29/02 5/6/02 5/13/02 5/20/02 5/24/02 Hours 33
34. © Mountain Goat Software, LLC A release burndown chart Story Points Iterations 600 450 300 150 0 1 2 3 4 5 Four Lessons Burndown charts: • Show net progress • Raise questions; they don’t answer them • Facilitate early discussions • Make it impossible to lie 34
35. © Mountain Goat Software, LLC Mike Cohn contact info mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890-6110 (office) (303) 810-2190 (mobile) 35