planning and tracking agile projects

Planning and TrackingAgile Projects

1

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


Imagine...That you’re fed up with software development as a career

And you decide to go into the landscaping business

moving this pile of rock from the front of my house to the back

3


How might you estimate this?One way:

Look at the pile of rock and estimate how many wheelbarrow loads it represents

After an hour, see how many wheelbarrow loads you’ve moved then extrapolate the total duration

I think that’s 80 wheelbarrow loadsAfter an hour I’ve moved 20 loadsSo, I’ll be done in a total of 4 hours

4


My landscaping

0

20

40

60

80

0900 1000 1100 1200 1300

Whe

elba

rrow

Loa

ds

Time

5


2

23

3 3

2

An iteration is a short, constrained period of timeTypically 1-4 weeks

2

4

32

12

2

23

3 3

2

A release typically comprises more than one iteration

Velocity is the amount of work

planned or completed in an

iteration.

6


Strategy

Portfolio

ProductRelease

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


Relating the different planning levels

I want to...

I want to...

I want to...

I want to...

I want to...

3

5

5

2

2

Iter

atio

n 2

Iter

atio

n 1

“Yesterday I started on the UI; I should

of today.”

Code the UI 86

Code middle tier 12

Write tests 5

Automate tests 4

Product Backlog Iteration Backlog

8


Iteration

Conditions of Satisfaction

(scope)

An agile approach to planningRelease

Conditions of Satisfaction

(scope, schedule, resources)

Release planning

Iteration planning

Feedback

Feedback

Development Product increment

9


Estimating

Release planning

Burndown charts

Agenda

10


Story pointsProbably the most commonly used estimating unit among agile teams today

Name is derived from agile teams commonly expressing requirements as “user stories”

Based on a combination of the size and complexity of the work

Unitless but numerically relevant estimatesA 10-point user story is expected to take twice as long as a 5-point user story

11


Consider these two piles of work

What story point values might we put on these?

12


Zoo points

Assign “zoo points” to the

following breeds LionKangaroo

RhinocerusBear

GiraffeGorilla

HippopotamusTiger

13


Three key advantagesEstimating in story points:1. Forces the use of relative estimating

Studies have shown we’re better at this†

2. Focuses us on estimating the size, not the durationWe derive duration empirically by seeing how much we complete per iteration

3. Puts estimates in units that we can add togetherTime 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



of today.”

Comparing apples to apples

I want to...

I want to...

I want to...

I want to...

I want to...

3

5

5

2

3

Code the UI 86

Code middle tier 12

Write tests 5

Automate tests 4

Product Backlog Sprint Backlog

30

50

50

20

20

15


Planning poker for estimatingAn iterative approach to estimating, loosely based on wideband DelphiSteps1. Each estimator is given a deck of cards, each card has a

valid estimate written on it2. Customer/Product owner reads a story and it’s discussed

3. Each estimator selects a card that’s his or her estimate4. Cards are turned over so all can see them5. Discuss differences (especially outliers)6. Re-estimate until estimates converge

16


Planning poker - an example

Estimator Round 1 Round 2

Susan

Vadim

Ann

Chris

3 58 52 55 8

201385321

17


Estimate theseProduct 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


Why planning poker worksThose who will do the work, estimate the work1

Estimators are required to justify estimates2, 3

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


Why planning poker worksCombining of individual estimates6 through group discussion7 leads to better estimatesEmphasizes relative rather than absolute estimatingEstimates are constrained to a set of values so we don’t waste time in meaningless argumentsEveryone’s opinion is heardIt’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 DevelopmentEffort Prediction Intervals: Why, When and How?

20


Reduces impact of irrelevant information

Given project spec.

Group A

Given same spec but with estimation-irrelevant details added:

end users’ desktop applicationsuser passwords, etc.

Group B

39 hours

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


Given a one-project spec.

Group A

Given a spec with exactly the same text but was 7 pages longIncreased length achieved through

double line spacewide marginslarger font sizemore space between paragraphs

Group B

173 hours

117 hours


22


Extra requirements

Given requirements R1–R4

Group A

Given requirements R1–R5

Group B4 hours

4 hours

Given requirements R1–R5but told to estimate R1–R4 only

Group C8 hours!


23


Reduces likelihood of anchoring

Given a product spec

Control group456 hours

Given the same product specTold the customer thinks 500 hours is a reasonable estimate but that

The customer knows very little about the implications of his spec on the estimate

High anchor group

555 hours

Same as high but customer thinks 50 hoursLow anchor group

99 hours


24


Estimating

Release planning

Burndown charts

Agenda

25


Release planning

To answer questions such as:How much will be done by 30 June?When can we ship with this set of features?How many people or teams should be on this project?

Purpose

VelocityThe length of the projectPrioritized product backlog

Inputs

26


Iteration 3-4

An example with velocity=14Iteration 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


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) = 33Last Observation = 36

Use multiple views of observed velocity

28


Extrapolate from velocity

29


Estimating

Release planning

Burndown charts

Agenda

30


How’s my landscaping coming?

0

20

40

60

80

0900 1000 1100 1200 1300

Whe

elba

rrow

Loa

ds

Time

This is called a burndown chart.

31


Remember the different levels?

I want to...

I want to...

I want to...

I want to...

I want to...

3

5

5

2

2

Iter

atio

n 2

Iter

atio

n 1


of today.”

Code the UI 86

Code middle tier 12

Write tests 5

Automate tests 4

Product Backlog Iteration Backlog

We can track burndown at both levels

32


An iteration burndown chart

0

200

400

600

800

1,0004/

29/0

2

5/6/

02

5/13

/02

5/20

/02

5/24

/02

Hou

rs

33


A release burndown chartSt

ory

Poin

ts

Iterations

600

450

300

150

01 2 3 4 5

Four LessonsBurndown charts:● Show net progress● Raise questions; they don’t

answer them● Facilitate early discussions

● Make it impossible to lie

34


Mike Cohn contact [email protected]

www.mountaingoatsoftware.com

(720) 890-6110 (office)

(303) 810-2190 (mobile)

35

planning and tracking agile projects

Business

software developmentas

agile software development

software effort estimation

agile estimatingand

agile teams todayname

page book

code middle tier

llcplanning poker