iasi codecamp 20 april 2013 agile estimations and planning - cornel fatulescu

Agile estimations and Planning

Cornel FATULESCU

agile coach

Did It Ever Happen to You?

• Who the ... made this estimation?

• Sorry it will take me than … hours!

• I hope we’ll deliver tomorrow.

• I can’t tell you how much time it will take!

• We don’t have time for testing

• …

2

Usual solution

3

Classical IT services supplier scenario

4

Sales Start-up Ongoing project

Some experts

Some members of newly created

team

The team

Basic knowledge

Some knowledge

might be lost

Grooming sessions

Release Planning

Capitalize RFP

Knowledge

DoR DoD

Estimations

Initial Release Planning

Product Vision

Initial Backlog

Goals

Problem 1 How to

estimate features?

Problem 2 How to plan?

How to estimate features ?

• What does the team need for each feature in order to increment it?

• How features become part of the increment?

• Estimate the features!

5

Definition of Ready

Definition of Done

Relative Estimations

Feature metamorphosis flow!

6

Suggestion Assumed Estimated Ready In Progress Pre-

Production Production

Done

Feature metamorphosis flow!

7

Suggestion Assumed Estimated Ready In Progress Pre-

Production Production

Done

? ? ? ?

Release Planning

End of Release

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

… …

… …

…

Sample of Definition of Ready for a feature

8

Story clarified

Tasks identified

Story estimated

Acceptance criteria

Clear dependencies

Scrum Team accepts the story

Responsible for acceptance

User story complies INVEST rules

…

Sample of Definition of Done for a feature

9

Design complete

Development complete

Code commented

Static code quality analysis

Unit testing is done

Code Refactoring

Code checkin

Continuous build

Tests

Documentation Ready

Peer reviews

Jira is updated

Story is accepted

Why relative estimations?

• Product Owner: How long it will take to deliver feature A?

• 1st team member : 3 Days

• 2nd team member: 6 Days

10

Both estimations

might be right!

Why relative estimations?

• Product Owner: How long it will take Compared to feature B we’ve done the last time?

• 1st team member : 3 times more

• 2nd team member: I agree, 3 times more

11

Measure the size, calculate the time

12

Velocity = 𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

𝛥𝑡𝑖𝑚𝑒

𝛥𝑡𝑖𝑚𝑒 = 𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦

Measure the size, calculate the time

13

Velocity = 𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

𝛥𝑡𝑖𝑚𝑒

𝛥𝑡𝑖𝑚𝑒 = 𝛥𝑑𝑖𝑠𝑡𝑎𝑛𝑐𝑒

𝑣𝑒𝑙𝑜𝑐𝑖𝑡𝑦

http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity

It’s effort, not complexity

14

“In a class a few years back, I was given a wonderful example of this. Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery–snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points–each is expected to take the same amount of time.”

-Mike Cohn

http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity

Visualize the estimations

15

To estimate

Feature 2

Feature 5

Feature 6

Feature 7

Feature 8

Feature 9

Feature 11

1 SP

Feature 1

Feature 43

Feature 32

Feature 21

Feature 23

2 SPs

Feature 3

Feature 4

Feature 18

3 SPs

Feature 10

Feature 88

5 SPs

Feature 13

Feature 15

8 SPs

Feature 22

5 SPs 6 SPs 6 SPs 10 SPs 8 SPs 35 SPs

How to plan?

16

Our concern?

Release Planning Process

Sprint DoR, DoD

Release DoR, DoD

What is release planning?

17

• It is a process not an event!

Release Planning

at project start-up

Sprint 1 Sprint 2 Sprint 3

Through Grooming Sessions

In Scrum no more than 10% of the

Sprint

Usually more effort needed

than in a sprint

Sample of Definition of Ready for a sprint

18

Sprint goal

The Sprint Backlog is prioritized

No hidden work

Calculated capacity

Team accepted the Sprint Backlog

All stories meet definition of ready

List of stories for regression testing

Sample of Definition of Done for a sprint

19

Release Build

Functional testing done

Regression testing done

Acceptance testing done by the Product Owner

Closure

Sprint Context

20

Team size

Focus factor

Sprint size

Calendar days

Velocity

6 People

70%

2 weeks

10 Days

16 SPs

Estimate 1 SP

21

• Estimate in hours several features

– Ex: Feature 1

• Estimated initially at 3 SPs

• Estimated in man days at 6 days

• =>1 SP = 2 days

• Ask the team directly how they evaluate 1SP?

• Experience and measure

Calculate Sprints Velocity

22

Sprint 1 Sprint 2 Sprint 3

Person days in sprint = calendar days * team size

60 60 60

Ideal person days in sprint = person days in sprint * focus factor

42 42 42

Sprint ideal man days 1st sprint = (1-40%) * ideal person days 2nd sprint = (1-20%) * ideal person days 3rd sprint = ideal person days

25 33 42

Velocity = Sprint ideal man days/1 SP 16 22 28

Team size Focus Factor Sprint Size Calendar Days

1 SP?

6 70% 2 weeks 10 Days 1.5 Man Days

Simulate sprints

23

Backlog 5 SPs

3 SPs

8 SPs

13 SPs

1 SP

2 SP

1 SP

Sprint 1 3 SPs

1 SP

1 SP

5 SPs

2 SPs

2 SPs

1 SPs

Sprint 2

5 SPs

3 SPs

5 SPs

2 SPs

5 SPs

2 SPs

Sprint 3 3 SPs

5 SPs

3 SPs

5 SPs

1 SP

5 SPs

2 SPs

5 SPs

…

1st Sprint Velocity 16

SPs

2nd Sprint Velocity 22

SPs

2nd Sprint Velocity 28

SPs

Measure and re-estimate 1 SP?

24

• Ex: 1st sprint estimated at 16 SPs velocity

– After execution we deliver 12 SPs

– Do reverse calculations from the previous slides

Sprint 1 Sprint 2 Sprint 3 1 SP?

Before starting 1st Sprint 16 22 28 1.5

After 1st Sprint 12 16 21 2

After 2nd Sprint 12 16 21 2

Criteria for ordering the backlog

25

• 1st The risk which the story should diminish

• 2nd The uncertainty on client needs which the story should reduce

• 3rd The contribution to the product quality

• 4th The dependencies between stories

• 5th The utility of a story

Dealing with uncertainty

26

Demo inspired from http://blog.bobcravens.com/2011/05/4-principles-to-estimation-applied-to-software-development/

Estimate how long will the walking take?

Walking from Iasi to Bucharest

28

• Distance Iasi – Bucharest = 417 km

• Average walking velocity = 5.0 (km/h)

– http://en.wikipedia.org/wiki/Walking

• We estimate walking 8 hours per day

• ~ 10.5 days of walking from Iasi to Bucharest

Walking from Iasi to Bucharest

29

• Initial uncertainty is probably in hours or days

We walk from Iasi to Roman

Walking from Iasi to Bucharest

31

• Distance Iasi – Roman = ~86 km

• Real walking velocity = 4.0 (km/h)

• We’ve walked 6 hours per day

• ~ 3.6 days of walking from Iasi to Roman

Estimate from Roman to Bucharest?

Walking from Roman to Bucharest

33

• Distance Roman – Bucharest = ~331 km

• Estimated walking velocity = 4.0 (km/h)

• Estimated walking hours per day = 6

• ~ 14.8 days of walking from Roman to Bucharest

• Initial cycle time = 10.5 days of walking

• Total cycle time = 18.4 days of walking

Burn-down chart Iasi-Bucharest

34

What about agile planning poker?

35

• The most common estimation method known in the agile community

• The interest is in the discussions

What about agile planning poker?

36

• The most common estimation method known in the agile community

• The interest is in the discussions

Estimation issues hide higher problems!

37

-10

0

10

20

30

40

50

60

D1 D2 D3 D4 D5 D6 D7 D8 D9 D10

RAF

Ideal RAF

Sprint Backlog

38

1st Story 13 2nd Story 13 3rd Story 8 4th Story 8 5th Story 13

Observed issues

39

• Just technical stories/no user stories

• Stories didn’t correspond to INVEST criteria

• Waterfall approach in iterations

• Lack of Definition of Ready

• Definition of Done was not respected

• …

Start from the need of information

40

• Clients want to know when it will be ready, the budget…

– Ex: Continuous pulling systems like Kanban

=>use average Cycle Time instead

• TODO in another knowledge sharing session!

Cornel FATULESCU

agile coach Planning is Everything. Plans are Nothing.

- Helmuth von Moltke