Agile Planning

24.11.2009

1

© 2003–2009 Artem Marchenko and Mountain Goat Software®

Agile Planning

Artem Marchenko

AgilDays.ru, December 9, 2009

Artem Marchenko - background


24.11.2009

2


What’s a good plan?

• A good plan is one that supports reliable decision-making

• Will go from

• We’ll be done in the third quarter

• We’ll be done in August

• We’ll be done August 18th


What makes planning agile?

Is more focused on

planning than the plan

Encourages change

Results in plans that

are easily changed

Is spread throughout

the project

24.11.2009

3


Starting assumptions

• We have a product backlog (prioritized feature

list)

• Items on the product backlog (user stories is my

preference) have been estimated in story points

or ideal days

• We have a team with a known velocity

• We’ll relax this assumption shortly


Sprint 2

Sprints 3-4

An example with velocity=14

Sprint 1Story A

5

Story E

1

Story D

5

Story G

1

Story I

5

Story J

8

Story H

13

Story C

3

Story B

8

Story F

5

24.11.2009

4


Release and sprint planning

Release Plan

Sprint

1

Sprint

2

Sprint

3

Sprints 4–7

8 hoursTask A

16 hoursTask B

5 hoursTask C

8 hoursTask D


•Sprint planning

•Estimating velocity

•Release planning

•Contracting on fixed-date

& fixed-scope projects

Agenda

24.11.2009

5



Two approaches

• Velocity-driven sprint planning

• Commitment-driven sprint planning

24.11.2009

6


Velocity-driven sprint planning

• “We finished 15 story points last time, let’s plan

on 15 story points this time.”

• Very unreliable in what will be accomplished

during an iteration

• Velocity is mostly useful over the long term


Commitment-driven sprint planning

• Discuss the highest priority item on the product backlog

• Decompose it into tasks

• Estimate each task

• Ask ourselves, “Can we commit to this?”

• If yes, see if we can add another backlog item

• If not, remove this item but see if we can add another smaller one. Possibly by splitting the original story

24.11.2009

7


It looks something like this

• Code the abc class (8 hours)

• Code the user interface (4)

• Write test fixtures (4)

• Code the xyz class (6)

• Update performance tests (4)

As a user, I want ...

2

• Prototype the UI (8 hours)

• Demo UI to 3 outside users (3)

• Code new UI (12)

• Update documentation (3)

As a user, I want ...

3

Team can commit, so they continue...

26

26


time

1

2

time

24.11.2009

8



How to estimate velocity

Use historical values

Don’t, until you’ve run

a sprint or two

Forecast it

1

2

3

24.11.2009

9


Forecasting velocity

• Just like commitment-driven sprint planning

• Estimate available hours for the sprint

• Repeat until full:

• Pick a story, break into tasks, estimate each task


An example

• Estimating available hours

Person Hours per Day Hours per Sprint

Sergey 4-6 40-60

Kimmo 5-7 50-70

Jarmo 2-3 20-30

Total 110-160

24.11.2009

10


... 20

... 50

8

6

12

Code the UI

Write test fixture

Code middle tier

Write tests 5

An example

As a frequent flyer, I

want to...3

As a user, I want to... 5

As a vacation planner,

I want to...5

As a frequent flyer, I

want to...2

Code the ... 12

Do the... 8

Document the... 8

Test the... 8

Analyze the... 4

Document ... 8

48 31

50

20

At 110-160 available hours per

sprint, what is the team’s velocity?


Put a range around it

• You’re unlikely to have precisely forecasted the

exact velocity the team will average

• So, put a range around your velocity estimate:

Known team, domain,

technology

+5%

−10%

Unknown team,

domain, technology

+25%

−50%

+10%

−25%

†Numbers based on PMI advice on progressive

accuracy of estimates.

24.11.2009

11


Expressing velocity as a range

200 ÷ 20 = 10

Estimated velocity

= 18

20

14

1.10

.75 200 ÷ 14 = 15

“Right now, before we start this project,

our best estimate is that it will take

between 10 and 15 sprints.”

Adjustments

from prior page

or intuition

Total of

estimates on

product

backlog


24.11.2009

12


Create a range from historical

data

Sprints

Mean (Worst 3) = 28

Mean (Last 8) = 33

Mean (Best 3) = 37


Predicting where we finish

At our long-term average we’ll finish here (5×33)

At our slowest velocity we’ll finish here (5×28)

At our best velocity we’ll finish here (5×37)

24.11.2009

13


Planning on contracted projects

Fixed-date projectsFixed-scope projects

• There are times you need to do this

• So let’s look at some good techniques

• Better though is try for a collaborative

relationship with your customer

• “You’ll have this team for each sprint, can

direct them at the start of each, and stop

when you have enough”

A caveat


Fixed-date planning

1. Determine how many sprints you have

2. 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 <date>?

24.11.2009

14


Fixed-date planning: an example

Desired

release date30 June

Today’s Date 1 January

Number of

sprints6 (monthly)

Low

velocity15

High

velocity20

6×15

6×20

Will have

Might

have

Won’t have


Fixed-date contracting

6×15

6×20

Will have

Might

have

Won’t have

•You won’t likely win the contract

•But you’ll probably make money if

you do

If you write a contract

for just the will haves:

•You will likely win the contract

•But probably not make money on it

If you write a contract that

includes the might haves:

It’s a risk issue

Where do you want to be?

24.11.2009

15


Fixed-scope planning

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?


Fixed-scope planning: an example

Total story points desired 120

Low velocity 15

High velocity 20

120÷20=

120÷15=

24.11.2009

16


Fixed-scope contracting

•You’ll likely win the contract

•But may not make any money


for the short duration:

•You probably won’t win the contract

•But will make money if you


for the long duration:

It’s a risk issue

Where do you want to be?


Ranges

• Notice in both cases we had a range

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

• “By that date you’ll have all of these features and

some of these.”

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

• “It will take us between 5 and 8 sprints to deliver all

of those features.”

24.11.2009

17


Artem Marchenko contact info

[email protected]

http://AgileSoftwareDevelopment.com

http://twitter.com/AgileArtem

mailto:[email protected]

mailto:[email protected]

http://agilesoftwaredevelopment.com/

http://twitter.com/AgileArtem

http://www.mountaingoatsoftware.com/

Agile Planning

Technology

mountain goat software4

mountain goat software6

mountain goat software7

mountain goat software8

mountain goat software10

mountain goat software11

mountain goat software12

velocity estimate