Planning and Tracking Agile Projects

Slide 1

Slide 1 text

Planning and Tracking Agile Projects 1

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

© 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@AB8=07A moving this pile of rock from the front of my house to the back 3

Slide 4

Slide 4 text

© 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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 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

Slide 7

Slide 7 text

© 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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 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

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© 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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 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

Slide 19

Slide 19 text

© 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

Slide 20

Slide 20 text

© 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

Slide 21

Slide 21 text

© 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

Slide 22

Slide 22 text

© 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

Slide 23

Slide 23 text

© 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

Slide 24

Slide 24 text

© 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 -=CA6=C:2

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 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

Slide 27

Slide 27 text

© 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

Slide 28

Slide 28 text

© 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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© 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