A summary of what you may need to think about if, and I write if, you need to add Release Planning to scrum.

1. 2013-­‐10-­‐24
Release
Planning
in
Scrum
Arne
Åhlander
Lean
and
Agile
Product
Management
Experts
What
do
you
know
about
Release
Planning?
1

2. 2013-­‐10-­‐24
Arne
Åhlander
Lean
and
Agile
Product
Management
Experts
QuesHons
to
be
answered:
•
•
•
•
When
should
you
do
Release
Planning?
How
much
work
is
it?
Who
should
be
involved?
How
to
do
Release
Planning?
2

3. 2013-­‐10-­‐24
Rough
Agenda
1. Background
2. Purpose
of
Release
Planning
3. Input
– What
do
we
need
before
we
can
start?
4. Output
– What
is
the
result
of
the
planning
acHviHes?
5. ParHcipants
6. Timebox
7. Possible
ways
to
manage
Release
Planning
Background
3

4. 2013-­‐10-­‐24
Planning
• Important
learning
experience
• CriHcal
in
developing
the
right
reflexes
in
an
organizaHon
• Necessary
for
establishing
the
high-­‐level
architectural
design
of
a
complex
system
7
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
4

5. 2013-­‐10-­‐24
The
Plan
•
•
•
•
Why
do
we
need
it?
How
shall
it
be
used?
How
detailed
shall
it
be?
The
reality
or
a
forecast?
What’s
a
good
plan?
• A
good
plan
is
one
that
supports
reliable
decision-­‐making
• Will
go
from
– We’ll
be
done
in
the
fourth
quarter
– We’ll
be
done
in
November
– We’ll
be
done
November
7th
5

6. 2013-­‐10-­‐24
TradiHonal
fixed
planning
follow
ing the
plan
wh
at h
still
app
lon
ens
g to
if re
go.
..
alit
yc
han
ges
?
Start
11
Paradox
…to
get
predictability
we
need
to
stop
predicHng…
…make
decisions
based
on
fact
not
forecasts…
…create
and
respond
to
feedback…
12
6

7. 2013-­‐10-­‐24
ConHnuous
planning
Start
13
A
comparison
• TradiHonal
planning
– Leads
to
focus
on
meeHng
the
plan
– Detailed
planning
up-­‐front
• ConHnuous
planning
– Leads
to
focus
on
value
creaHon
– Detailed
planning
as
we
learn
more
14
7

8. 2013-­‐10-­‐24
Rolling
(conHnuous)
Plan
•
•
•
•
Updated
frequently
Takes
changed
circumstances
into
account
Is
detailed
only
when
facts
allow
it
Is
detailed
as
we
learn
more
16
8

9. 2013-­‐10-­‐24
The
detail
of
planning
Accuracy
• A
licle
effort
helps
a
lot
• A
lot
of
effort
only
helps
a
licle
more
Effort
17
9

10. 2013-­‐10-­‐24
Planning
onion
Planning
levels
10

11. 2013-­‐10-­‐24
ose of g
Purp
n
Planni
e
Releas
To
get
rough
answers
• When
can
this
be
done?
• How
much
can
be
done
by
then?
11

12. 2013-­‐10-­‐24
Release
burnup
Delivered
features
time
Fixed
scope
Delivered
features
When will this
much be done?
Around middle
of March
time
12

13. 2013-­‐10-­‐24
Fixed
scope
Delivered
features
When will this
much be done?
Around middle
of March
time
Fixed
date
Delivered
features
Some of
these
All of
these
What will be done
by February 1st?
time
13

14. 2013-­‐10-­‐24
Fixed
date
&
scope
Delivered
features
No. That is
unrealistic.
Can we get
all of THIS
done...
....by
February
1st?
time
Fixed
date
&
scope
No. That is
unrealistic.
Delivered
features
We can get THIS
much done by
February 1st
...and the rest done
by mid March.
time
14

15. 2013-­‐10-­‐24
An
Agile
approach
to
planning
Release
Conditions of
Satisfaction
(user stories,
budget, schedule)
Feedback
Release planning
Iteration
Feedback
Conditions of
Satisfaction
(user stories, test)
Iteration
planning
Development
Product
increment
How
long
will
it
take
• ...to
read
the
latest
Harry
Pocer
book?
• ...to
drive
to
your
home
town?
15

16. 2013-­‐10-­‐24
EsHmate
size;
derive
duraHon
Size
Calculation
Duration
300 kg
Velocity
=
20
300/20=
15
iterations
Measures
of
size
• Traditional and agile measure size
differently
• TradiHonal
measures
of
size
– Lines
of
Code
– FuncHon
Points
• Agile
measures
of
size
– Story
Points
– Ideal
Days
16

17. 2013-­‐10-­‐24
Story
points
• The
”bigness”
of
a
task
• Influenced
by
– How
hard
it
is
– How
much
of
it
there
is
• RelaHve
values
are
what
is
important:
– A
login
screen
is
a
2
– A
search
fetaure
is
an
8
• Points
are
unit
less
As a user, I want to be
able to have some but not
all items in my cart gift
wrapped.
5
Three
levels
of
planning...
Release plan
Iteration plan
Daily
plan
Daily
plan
Daily
plan
Daily
plan
Daily
plan
Iteration plan
Daily
plan
17

18. 2013-­‐10-­‐24
...three
levels
of
precision
Iteration Backlog
Product Backlog
Iteration 1
Iteration 2
As a frequent flyer
I want to...
30
As a frequent flyer
I want to...
50
As a frequent flyer
I want to...
50
As a frequent flyer
I want to...
20
As a frequent flyer
I want to...
Code the UI
8
Write test fixture 6
Code middle tier 12
Write tests
5
Automate tests
4
20
”Yesterday I started
on the UI; I should
finish before the end
of today.”
ng
Planni
e
Releas
e
Releas
Plan
1
Sprint
Sprint
2
3
Sprint
Sprint
4-7
18

19. 2013-­‐10-­‐24
Input
• Product
Vision
• Product
Backlog
• Release
Goal
• Velocity
Results
• Release
Plan
...
• ...
and
even
more
important:
– Learning
– Understanding
– Transparency
of
risks
19

20. 2013-­‐10-­‐24
UpdaHng
the
release
plan
• Revisit
the
release
plan
at
the
end
of
every
Sprint
• Update
it
based
on:
– Current
understanding
of
velocity
– Current
prioriHzaHon
of
the
product
backlog
• This
should
be
a
very
short
and
sweet
process
e
Releas
ga
lannin
P
20

21. 2013-­‐10-­‐24
1. Determines
- when a release is needed,
- what functionality it must contain, and
- acceptable level of quality and cost
Business
2. Determines
4.
- Focuses on Business Value
derived from the release
- how long it takes to build the release
- Creates preliminary estimates
3.
- Refines estimateds as priority increases
- Selects what to work on for each Sprint
Development
Product
backlog
This Sprint : well defined work that can
be done in <30 days & produce executable product
Probable next sprint : backlog next in priority,
depends on results from prior Sprint
Planned Release
Future Releases
During a Sprint, that Sprint’s backlog is fixed
and can only be changed as a result of the
work being performed in that Sprint.
Backlog outside the current Sprint is always
changing, evolving, and being reprioritized.
21

22. 2013-­‐10-­‐24
Release
planning
Release planning meeting
Release Plan
Sprint 1
Sprint 2
Sprint 3
Sprint 4-7
43
An
example
with
velocity
=
14
Sprint 1
Sprint 3-7
Story A
Story E
Story I
1
8
5Story J
Story E
8
8
Sprint 2
Story C
3
Story D
5
Story H
Story K
5
13
Story B
Story L
Story B
5
1
1
Story M
Story F
5
Story G
1
Story P
4
12
Story N
Story Q
6
4
Story O
Story R
1
8
44
22

23. 2013-­‐10-­‐24
An
esHmaHon
unit
Story points
• A measure of the relative size of the feature
• Based on how much and how hard
• All that matter is the relative size of numbers
45
Release
Planning
Purpose
To answer questions such as:
• How much will be done by June 30?
• When can we ship with this set of features?
• How many people or team should be on this
project?
Inputs
• Velocity
• The amount of work completed in a sprint
• Prioritised product backlog
46
23

24. 2013-­‐10-­‐24
Velocity
• A
useful
long-­‐term
measure
of
the
amount
of
work
completed
per
sprint
• Not
a
predicHon
of
exactly
how
much
work
will
be
completed
in
each
sprint
40
sured
Velocity is mea
its you use
in the un
oduct
to estimate pr
ems
backlog it
30
20
10
0
1
2
3
4
5
6
7
8
9
Sprints
47
Look
at
velocity
in
a
few
ways
Velocity
40
Last Observation = 36
Mean (Last 8) = 33
30
Mean (Worst 3) = 28
20
10
0
1
2
3
4
5
6
7
8
9
Sprints
48
24

25. 2013-­‐10-­‐24
Extrapolate
from
velocity
Will have
At our slowest velocity we’ll finish here
Might have
At our long-term average we’ll finish here
At current velocity we’ll finish here
Won’t have
49
Fixed-­‐date
planning:
an
example
Desired
release
date
15
December
Todays
Date
10 June
Number of
sprints
6
(monthly)
Realistiv
velocity
15
Optimistic
velocity
20
Will have
6x15
Might have
6x20
Won’t have
50
25

26. 2013-­‐10-­‐24
Fixed-­‐scope
planning:
an
example
Total story points desired
120
Realistic velocity
15
Optimistic velocity
20
120÷20=
120÷15=
51
Ranges
NoHce
in
both
cases
we
had
a
range
Either
a
scope
range
for
a
fixed
date
project:
•
–
”By
that
date
you’ll
have
all
of
these
features
and
some
of
these.”
Or
a
date
range
for
a
fixed-­‐scope
project:
•
–
”It
will
take
us
between
6
and
8
iteraHons
to
deliver
all
of
those
features.”
26

27. 2013-­‐10-­‐24
Summary
Σ
AcHon
plan
27

28. 2013-­‐10-­‐24
InspiraHon
and
references
•
•
Henrik
Kniberg
Mike
Cohn
•
•
•
•
hcp://agileatlas.org/arHcles/item/release-­‐planning-­‐in-­‐scrum
hcp://www.mitchlacey.com/intro-­‐to-­‐agile/scrum/release-­‐planning-­‐grooming
hcp://innoluHon.com/resources/glossary/release-­‐planning
hcp://www.jamesshore.com/Agile-­‐Book/release_planning.html
•
EssenHal
Scrum:
A
PracHcal
Guide
to
the
Most
Popular
Agile
Process
(Kenneth
S.
Rubin)
hcp://amzn.com/0137043295
•
Agile
EsHmaHng
and
Planning
(Mike
Cohn)
hcp://Hnyurl.com/39memw
Thank
you!
Arne
Åhlander
arne.ahlander@aqqurite.se
www.aqqurite.se
www.twicer.com/ArneAhl
hcp://www.linkedin.com/in/arneahlander
28