Cohn Planning Basics to Brainstumpers Agile2010

8/8/2019 Cohn Planning Basics to Brainstumpers Agile2010

1/32

2009 Mountain Goat Software Copyright Mountain Goat Software

AgilePlanning:

FromBasicstoBrainstumpers

MikeCohn

[email protected]

om

9August2010

Copyright Mountain Goat Software

Mike CohnFounding member anddirector of Agile Allianceand Scrum Alliance

Founder of MountainGoat Software

Doing Scrum since 1995Started my career as aprogrammer; worked asVP Engineering in 4companies

1

2


2/32


Release and sprint planning

Release Plan

Sprint 1 Sprint 2 Sprint 3 Sprint 47


A good plan is one that supports reliabledecision-making

Will go from

Well be done in the second quarter

Well be done in FebruaryWell be done February 18th

John Maynard Keynes

Its better to be roughly rightthan precisely wrong.

3

4


3/32


Is more focused onplanning than the plan

Encourages change

Results in plans that areeasily changed

Is spread throughout theproject


EstimatingHowdoIbestusehistoricalv

elocity

data?HowdoIestimatevelocityfor

a

newteam?HowdodoIestimatevelocity

if

teamsizechanges? HowdoIreliablycommittoafixedscopeorfixeddate?HowdoIcreateaplanwhenthereisatremendousamountofuncertaintyinwhatwerebuilding?WhenshouldIre-estimate?

5

6


4/32


How long will it take...

...to read the latest

Harry Potter book?

...to drive to Denver?


Estimate size; derive duration

Size Calculation Duration

300

kilograms

Velocity =

20

300/20 =

15 sprints

7

8


5/32


Traditional and agile measure size differently

Traditionalmeasuresof size

Lines of CodeFunction Points

Agilemeasuresof size

Story pointsIdeal days


How long a user story will take (effort)

Influenced by complexity, uncertainty, risk,volume of work, etc.

Relative values are what is important:

A login screen is a 2.A search feature is an 8.

Basic math properties should hold

5+5 = 10

9

10


6/32


HowdoIbestusehistoricalvelocitydata?


27

34

35

38

3940

40

41

45

Median 90% confidence

interval

Sorted Velocities # ofHistorical

Sprints

Sprints tothrow out

at each eachend

5 0

8 1

11 2

13 316 4

18 5

21 6

23 7

26 8Usethenextlowe

rnumber

ofsprintsifyoudonthave

anexactnum

ber.

Use the online velocity range calculator atwww.mountaingoatsoftware.com/tools

11

12


7/32


Extrapolate from the velocity range

At our median velocity well get here (539)

Well almost certainly get here (534)

The most we could realistically expect(541)


HowcanIestimate

velocityforanew

team?

13

14


8/32


Get the team together as though there weregoing to plan a real iteration (24 weeks)

Iteration planning involves

Breaking product backlog items (features) into tasks

Estimating the hours for each task

Repeating until the iteration feels full

See how many points are represented by thework they select

Consider planning a second iteration this way


Consider this team

15

16


9/32


10/32


If you dont have historical data

Take a wild guess, perhaps:

+/ 10% for a known team working in a knowndomain with known technologies

+/ 50% if all that is unknown

If you have historical data from other teams

Calculate the relative standard deviation ofthose teams


Tea

Sprint

A

Velocity

1

2

3

4

5

6

7

8

20

28

24

16

18

23

26

21

Team A

Mean

22

StandardDeviation

3.8

19

20


11/32


MeanStandardDeviation

Relative Std.Dev.

Team A

Team B

Team C

...

22 3.8 17%

28 6.2 22%

45 9.3 20%

... ... ...Average 19%

20021=9.5=10Estimatedvelocity = 18

21

15

1.19

0.81 20015=13.3=14

Total ofestimates on

product backlog

Before we start this project, our bestestimate is from 10 to 14 sprints.


HowdodoIestimate

velocityifteamsize

willchangeduringthe

project?

21

22


12/32


If future team size changes are likely to besimilar to past team size changes:

Use historical velocity without anyadjustments for team composition

If future team size changes will be different:

Predict the impact of those changes with datafrom past team size changes


Track velocity when size changes

Initial

Team Size

New

Team SizeSprint +1 Sprint +2 Sprint +3

6 7 20% 4% +12%

6 7 0% 6% +15%

7 5 12% 8% 8%

8 6 20% 20% 16%

7 8 15%

23

24


13/32


InitialTeam Size

NewTeam Size

Sprint +1 Sprint +2 Sprint +3

6 7 20% 4% +12%6 7 0% 6% +15%

7 5 12% 8% 8%

SprintAverage Velocity

Change

1 10%

2 5%

3+ +13%

The impact of going from 67 people


SprintAdjust-

ment

Low

(34)

Median

(39)

High

(41)

1 10% 30 35 36

2 5% 32 37 39

3 +13% 38 44 46

4 +13% 38 44 46

5 +13% 38 44 46

Sum 176 204 213

Round down toavoid overstating

velocity.

25

26


14/32


Predicted impact of a new team member

204 now; was 195 (539)

176 now; was 170(534)

213 now; was 205(541)


HowdoIreliably

committoafixedscope

orfixeddate?

27

28


15/32


1. Determine how many sprints you have2. 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

How much can I get by ?


Fixed-date planning: an example

615

620

Will have

Might have

Wont have

29

30


16/32


Fixed-date contracting

615

620

Will have

Might have

Wont have

If you write a contract forjust the will-haves:

You wont likely win the contract

But youll probably make money if you do

If you write a contract thatincludes the might haves:

You will likely win the contract But probably not make money on it

Its a risk issue

How much risk do you want to take?

Its a balance between short- and long-term risk


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

When will all of this be done?

31

32


17/32


Fixed-scope planning: an example

12020=

12015=


Fixed-scope contractingIf you write a contract for

the short duration:

Youll likely win the contract But may not make any money

If you write a contract forthe longduration:

You probably wont win the contract But will make money if you do

Again, its a risk issue

How much risk do you want to take? Its a balance between short- and long-term risk

33

34


18/32


Notice in both cases we had a range

For a fixed date project, use a scope range:

By that date youll have all of these featuresand some of these.

For a fixed-scope project, use a date range:

It will take us between 5 and 8 sprints todeliver all of those features.


The impending tradeshow

Your company develops tools for managing agileprojects.Youve finished version 1.0 (on time, of course).Now the boss needs a new version for the bigtrade show that is 4 sprints away.

Which features can you guarantee will be infor the trade show?

Which features are likely to be in?

Use the following user stories,estimates and velocities.

35

36


19/32


Past velocities

Histo ical Data

Sprint

number

Velocity

1 20

2 14

3 23

4 18

5 25

6 30

7 12

8 22

9 15

10 23

Your estimates


The teams estimates

37

38


20/32


HowdoIcreateaplan

whenthereisatremendousamountofuncertaintyinwhatwerebuilding?


50%

estimate

Buffer to

90%

Time=1:05

Time=1:45

39

40


21/32


Time

ProbabilityofCompletio

n


50% estimates

Remove all local safety: no padding

An estimate you should / willmiss more than half the time

90% estimates

Not really a worst case

No lightning strikes or busses running over people

Keep in mind that youll even exceed thisestimate occasionally

41

42


22/32


90% Confidence

Interval


We cant add the 50% estimates together

That assumes everything goes smoothly

Overall schedule will be too short

We cant add the 90% estimates together

That assumes that everything goes wrong

Overall schedule will be too long

43

44


23/32


We add the 50% estimates

And buffer the overall project, rather thanthe tasks

50% 90% 50% 90% 50% 90%+ +

+ 90%


50%estimate

Time=1:05

Buffer to90%

Time=1:45

1

45

5

7

7

53

45

46


24/32


Padding is extra time you dont think youllneed but add to be safe

Padding implies it was unnecessary

You will need the project buffer

Even with the project buffer youre notguaranteed to be done on time


Simple rule

Use 50% of the unbuffered (50%) schedule

More sophisticated, usually better

h = high estimate (90%)l = low estimate (50%)

The more sophisticated approach considers the

extreme variability of some work

This will take 2 days if it goes well, or 20 if not.

47

48


25/32


When the cost of being wrong is significant

Highly political environment

A great deal of extra activity (press releases, ads, training,etc.) is planned for the release date

When theres a great deal of uncertainty or risk in theproduct backlog

When youre at risk (e.g., contract development)

Dont bother in most cases

Trusting environment

When theres little impact to refining release date midwaythrough the project


Schedule =16+ 111 =16+11= 27

49

50


26/32


Whenshould Ire-estimate?


Re-estimating

33

33

33

33

33

33

33

33

We expect

velocity = 12

But we finish

half that much

51

52


27/32


666

66

6

66

But a velocity of 6

doesnt seem right; so

we double those stories

But if all stories are the

same size, we need to

double all of them

333

33

3

66


53

54


28/32


The team has just finished the first sprint

Theyd planned to do stories A, B, and C

They only finished A and B

Largely because Story A was much harder thanexpected

It should have been at least a six.

The real problem is not just with Story A butwith all stories related to graphing (A, C, and D)

Graphing is twice as hard as theyve estimated


What is the teams velocity? Will they be able to maintain that velocity?

No re-estimating

The first two situations

What happens if Story A (only) is re-estimated as 6? What was the velocity of the finished sprint? What stories are planned for the next sprint? Will the team finish those stories?

Re-estimate the finished story

55

56


29/32


Stories A, B, and C are all graphing stories; graphing is

twice as hard as thought so double all these What was the velocity of the first sprint? Can the team do that much in the second sprint?

Re-estimating when relative size changes

Whatcanyouconclude

aboutre-estimatingfrom

thesethreescenarios?


Asamanager,Iamsentan

emailwhenoneofmy

employeesrequeststime

off. ?

As an employee, I amsent an email when mymanager approves orrejects my time offrequest. ?

Theres some initial

work before we can

send the first email

Once that is done,

sending other emailswill be easy

What estimates

should we put on

these two stories?

Related, dependent stories

57

58


30/32


Assumptions Five points for initial email support and sending first email One point for each new email type to send

Which option is best?

Five points on each since we dontknow which well do first

Five points on either story and onepoint on the other

Three points on each


A Guiding Tip:

The sum of all items on

the product backlog

should always representthe full size of the entire

project.

59

60


31/32



Moreinfoatwww.mountaingoatsoftware.com

My upcoming classes

ClassesalsoinLondon&Oslo

61

62


32/32


Mike [email protected]

www.mountaingoatsoftware.comtwitter: mikewcohn

(720) 8906110

63

Documents

Cohn Planning Basics to Brainstumpers Agile2010