Agile Planning

24.11.2009

Agile Planning

Artem Marchenko
AgilDays.ru, December 9, 2009

© 2003–2009 Artem Marchenko and Mountain Goat Software®

Artem Marchenko - background


1

24.11.2009

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

2

24.11.2009

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


An example with velocity=14
Story A Story F
Sprint 1 Sprints 3-4
5 5
Story B Story G

8 1
Story C Story H
Sprint 2
3 13
Story D Story I

5 5
Story E Story J

1 8

3

24.11.2009

Release and sprint planning

Release Plan
Sprint Sprint Sprint Sprints 4–7
1 2 3

Task A 8 hours
Task B 16 hours
Task C 5 hours
Task D 8 hours


Agenda

• Sprint planning
• Estimating velocity
• Release planning
• Contracting on fixed-date
& fixed-scope projects


4

24.11.2009


Two approaches
• Velocity-driven sprint planning
• Commitment-driven sprint planning


5

24.11.2009

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


6

24.11.2009

It looks something like this
As a user, I want ... • Code the abc class (8 hours)
• Code the user interface (4)
• Write test fixtures (4) 26
• Code the xyz class (6)
2 • Update performance tests (4)

Team can commit, so they continue...

As a user, I want ...
• Prototype the UI (8 hours)
• Demo UI to 3 outside users (3)
• Code new UI (12) 26
• Update documentation (3)
3

1

2
time

time


7

24.11.2009


How to estimate velocity
1
Use historical values

2
Don’t, until you’ve run
a sprint or two
3
Forecast it


8

24.11.2009

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


9

24.11.2009

An example
At 110-160 available hours per
sprint, what is the team’s velocity?

Code the ... 12
Code the UI 8
Do the... 8
As a frequent flyer, I
Write test fixture 6
48
Document the... 8
want to... 3 31
Code middle tier 12
Test the... 8
Write tests 5
Analyze the... 4 As a user, I want to... 5
Document ... 8 As a vacation planner,
I want to... 5 50
... 50
As a frequent flyer, I
20
... 20 want to... 2


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, +5%
technology −10%
+10%
−25%
Unknown team, +25%
domain, technology −50%
†Numbers based on PMI advice on progressive
accuracy of estimates. © 2003–2009 Artem Marchenko and Mountain Goat Software®

10

24.11.2009

Expressing velocity as a range

1.10 20 200 ÷ 20 = 10
Estimated velocity
= 18
.75 14 200 ÷ 14 = 15

Adjustments Total of
from prior page estimates on
or intuition product
backlog

“Right now, before we start this project,
our best estimate is that it will take
between 10 and 15 sprints.”


11

24.11.2009

Create a range from historical
data
Mean (Best 3) = 37
Mean (Last 8) = 33
Mean (Worst 3) = 28

Sprints

Predicting where we finish

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

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


12

24.11.2009

Planning on contracted projects
Fixed-date projects
Fixed-scope projects

A caveat
• 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”

Fixed-date planning
How much can I get by <date>?
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”


13

24.11.2009

Fixed-date planning: an example
Desired
30 June
release date
Will have
Today’s Date 1 January

Number of 6×15
6 (monthly) Might
sprints
have
Low 6×20
15
velocity
High
20 Won’t have
velocity


Fixed-date contracting
If you write a contract
for just the will haves:
• You won’t likely win the contract
Will have • But you’ll probably make money if
you do

6×15 If you write a contract that
Might includes the might haves:
have • You will likely win the contract
6×20 • But probably not make money on it

Won’t have It’s a risk issue
Where do you want to be?

14

24.11.2009

Fixed-scope planning
When will all of this be done?
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


Fixed-scope planning: an example
Total story points desired 120
Low velocity 15
High velocity 20

120÷20=

120÷15=


15

24.11.2009

Fixed-scope contracting
for the short duration:

• You’ll likely win the contract
• But may not make any money

for the long duration:
• You probably won’t win the contract
• But will make money if you

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.”


16

24.11.2009

Artem Marchenko contact info

artem.marchenko@gmail.com
http://AgileSoftwareDevelopment.com
http://twitter.com/AgileArtem


17

Agile Planning

Recommended

Recommended

More Related Content

Similar to Agile Planning

Similar to Agile Planning (6)

More from Nikita Filippov

More from Nikita Filippov (20)

Recently uploaded

Recently uploaded (20)

Agile Planning