This is a presentation I gave at the Central Indiana MPUG September 2012 meeting. Abstract: There are many commonly held myths about agile. Two of these myths are that agile projects don’t do any planning and that you can’t do agile on a fixed date project. In this presentation we will disprove these two myths by exploring just how agile planning is accomplished and how you can not only use agile on fixed date projects but also improve your accuracy and consistency in hitting those dates with agile.

1. Agile Planning
September Central Indiana MPUG
Matt Block

2. Quick Introduction
 Developer by trade
– CS Major from Purdue (Go Boilers!)
– Developer at large manufacturing company
 Development Manager
– Small software company
– Introduced Agile
 Product Manager/Product Owner
– Sounded good at the time 
 Development Manager
– Large Software company
– Leading Agile Transformation
 AgileIndy – Founding Member/Organizer
Copyright © 2012
2
Development Block, LLC

3. Agenda
 Agile Planning – Common Myths
– Agile means no plans
– You can’t do fixed date projects in agile
 Agile Release Planning – An Overview
Copyright © 2012
3
Development Block, LLC

4. AGILE MEANS NO PLANS
Copyright © 2012
4
Development Block, LLC

5. The Agile Manifesto
Individuals and
over Processes and Tools
Interactions
over Comprehensive
Working Software
Documentation
Customer over Contract
Collaboration Negotiation
Responding to
over Following a Plan
Change
Copyright © 2012
5
Development Block, LLC

6. Agile Teams Plan Constantly
 “Plans are nothing; planning is everything.”
– Dwight D. Eisenhower
 “I plan to re-plan”
– Popular agile t-shirt
Copyright © 2012
6
Development Block, LLC

7. Levels of Planning in Agile
Strategy
Portfolio
Product • 1-2 times per year
• Product evolution over time
Release • 3-4 times per year
• Feature/Date tradeoffs
Iteration • Every 2-4 weeks
• What will fit in this iteration?
• Every day
Daily • How to complete comittement
Copyright © 2012
7
Development Block, LLC

8. Planning in Scrum
Copyright © 2012
8
Development Block, LLC

9. We Can’t Know Everything Up Front
Copyright © 2012
9
Development Block, LLC

10. Agile is Iterative
Copyright © 2012
10
Development Block, LLC

11. Accuracy vs. Precision
 Plans must be accurate, gain precision over
time
– We’ll be done in Q3.
– We’ll be done in September.
– We’ll be done on September 10.
 Precision is expensive, and more likely to be
wrong.
 While both accuracy and precision are
desirable, accuracy is much more valuable.
Copyright © 2012
11
Development Block, LLC

12. YOU CAN’T DO FIXED DATE
PROJECTS IN AGILE
Copyright © 2012
12
Development Block, LLC

13. The Agile Manifesto
Individuals and
over Processes and Tools
Interactions
over Comprehensive
Working Software
Documentation
Customer over Contract
Collaboration Negotiation
Responding to
over Following a Plan
Change
Copyright © 2012
13
Development Block, LLC

14. Planning in Scrum
Fixed Date!
Copyright © 2012
14
Development Block, LLC

15. Fixed Dates in Scrum
Fixed Date
Copyright © 2012
15
Development Block, LLC

16. What About Utilization?
“Attempts to force non-deterministic
systems to operate at greater than 80%
efficiency will cause short bursts of
stabilization followed by extreme
periods of destructive and unpredictable
variations from that goal.”
- W. Edwards Deming
Copyright © 2012
16
Development Block, LLC

17. The Iron Triangle
 Quality is part of scope
Scope
– It is built in from the
beginning, not “tested
in” at the end.
 Value is part of scope
– Higher value items are
delivered sooner
 “Depth” is part of scope
Cost Schedule
– Do you need a Porsche
or will a Kia do?
Copyright © 2012
17
Development Block, LLC

18. The Release Burndown
Release Burndown Release Date
600
500
400
300
200
100
0
Copyright © 2012
18
Development Block, LLC

19. RELEASE PLANNING IN AGILE
Copyright © 2012
19
Development Block, LLC

20. Levels of Planning in Agile
Strategy
Portfolio
Product • 1-2 times per year
• Product evolution over time
Release • 3-4 times per year
• Feature/Date tradeoffs
Iteration • Every 2-4 weeks
• What will fit in this iteration?
• Every day
Daily • How to complete comittement
Copyright © 2012
20
Development Block, LLC

21. What is It?
 Usually trying to answer questions like…
– How much can be done by a given date?
– When can this set of features be shipped?
– How many teams do we need working on this
project?
Copyright © 2012
21
Development Block, LLC

22. What is Needed?
 Prioritized, estimated backlog
– High level estimates from the team that will likely
do the work.
– Prioritized by business value.
 Velocity
– Average amount of work a given team can
complete in a given sprint.
– Usually use the previous 8 – 12 sprints.
Copyright © 2012
22
Development Block, LLC

23. Velocity?
 Agile teams usually use relative estimates, not
precise estimates
– This feature is about the same as that one.
– Often expressed as Story Points using a modified
Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, … )
A team’s Velocity is the sum of the story
points for all of the user stories/features that
are completed in a sprint
Copyright © 2012
23
Development Block, LLC

24. Getting Confidence Intervals
 We can obtain the 90% confidence intervals
using a team’s historical velocity values from
recent sprints.
24  Sort the velocities from the
26 previous 9 sprints.
28  Throw out the highest and lowest.
28
 The remaining highest and lowest
30
is your 90% confidence range.
30
31
 www.mountaingoatsoftware.com
32
has good tools to help with this
35
Copyright © 2012
24
Development Block, LLC

25. Using Confidence Intervals
 Apply the confidence intervals to your backlog
to get a better idea of how much work will be
done by a given date.
We will almost certainly get here (8x26)
At our median velocity, we’ll get here (8x30)
The most we could realistically expect is here (8x32)
Copyright © 2012
25
Development Block, LLC

26. Using Confidence Intervals
 Apply the confidence intervals to your backlog
to determine when a given set of features will
be done.
– We will almost definitely be done in 20 sprints
(500 / 26)
– At our median velocity, we will be done in 17
sprints (500 / 30)
– The best we could realistically expect is to be done
in 16 sprints (200 / 32)
Copyright © 2012
26
Development Block, LLC

27. Burndown with Confidence!
Release Burndown Release Date
600
500
400
300
200
100
0
Copyright © 2012
27
Development Block, LLC

28. Credits and References
 Mike Cohn
– http://www.mountaingoatsoftware.com
– Blog, Books, Articles, Presentations
– Agile Estimating and Planning, Succeeding with
Agile
– Portions of this presentation were taken from his
redistributable Introduction to Scrum presentation
Copyright © 2012
28
Development Block, LLC

29. Contact Information
 Matt Block
– Email: matt@developmentblock.com
– Blog: http://www.developmentblock.com
 AgileIndy
– Meetup: http://www.meetup.com/agileindy/
– Meet 2nd Wednesday @ 5:30
Copyright © 2012
29
Development Block, LLC