This document discusses agile planning techniques. It explains that agile planning focuses more on planning than the plan and encourages change. Velocity-driven and commitment-driven sprint planning approaches are described. When planning on fixed-date or fixed-scope contracted projects, the document recommends expressing estimates as ranges based on historical velocity data to account for uncertainty.

1. 24.11.2009
Agile Planning
Artem Marchenko
AgilDays.ru, December 9, 2009
© 2003–2009 Artem Marchenko and Mountain Goat Software®
Artem Marchenko - background
© 2003–2009 Artem Marchenko and Mountain Goat Software®
1

2. 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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
2

3. 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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
3

4. 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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
Agenda
• Sprint planning
• Estimating velocity
• Release planning
• Contracting on fixed-date
& fixed-scope projects
© 2003–2009 Artem Marchenko and Mountain Goat Software®
4

5. 24.11.2009
© 2003–2009 Artem Marchenko and Mountain Goat Software®
Two approaches
• Velocity-driven sprint planning
• Commitment-driven sprint planning
© 2003–2009 Artem Marchenko and Mountain Goat Software®
5

6. 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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
6

7. 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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
1
2
time
time
© 2003–2009 Artem Marchenko and Mountain Goat Software®
7

8. 24.11.2009
© 2003–2009 Artem Marchenko and Mountain Goat Software®
How to estimate velocity
1
Use historical values
2
Don’t, until you’ve run
a sprint or two
3
Forecast it
© 2003–2009 Artem Marchenko and Mountain Goat Software®
8

9. 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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
9

10. 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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
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

11. 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.”
© 2003–2009 Artem Marchenko and Mountain Goat Software®
© 2003–2009 Artem Marchenko and Mountain Goat Software®
11

12. 24.11.2009
Create a range from historical
data
Mean (Best 3) = 37
Mean (Last 8) = 33
Mean (Worst 3) = 28
Sprints
© 2003–2009 Artem Marchenko and Mountain Goat Software®
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)
© 2003–2009 Artem Marchenko and Mountain Goat Software®
12

13. 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”
© 2003–2009 Artem Marchenko and Mountain Goat Software®
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”
© 2003–2009 Artem Marchenko and Mountain Goat Software®
13

14. 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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
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?
© 2003–2009 Artem Marchenko and Mountain Goat Software®
14

15. 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
© 2003–2009 Artem Marchenko and Mountain Goat Software®
Fixed-scope planning: an example
Total story points desired 120
Low velocity 15
High velocity 20
120÷20=
120÷15=
© 2003–2009 Artem Marchenko and Mountain Goat Software®
15

16. 24.11.2009
Fixed-scope contracting
If you write a contract
for the short duration:
• You’ll likely win the contract
• But may not make any money
If you write a contract
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?
© 2003–2009 Artem Marchenko and Mountain Goat Software®
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.”
© 2003–2009 Artem Marchenko and Mountain Goat Software®
16

17. 24.11.2009
Artem Marchenko contact info
artem.marchenko@gmail.com
http://AgileSoftwareDevelopment.com
http://twitter.com/AgileArtem
© 2003–2009 Artem Marchenko and Mountain Goat Software®
17