release planning in scrum
DESCRIPTION
A summary of what you may need to think about if, and I write if, you need to add Release Planning to scrum.TRANSCRIPT
2013-‐10-‐24
1
Release Planning in Scrum Arne Åhlander
Lean and Agile Product Management Experts
What do you know about Release Planning?
2013-‐10-‐24
2
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?
2013-‐10-‐24
3
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
2013-‐10-‐24
4
7
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
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
2013-‐10-‐24
5
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
2013-‐10-‐24
6
11
TradiHonal fixed planning
Start
follo
win
g th
e pl
an
what happens if reality changes?
still long to go...
12
Paradox
…to get predictability we need to stop predicHng…
…make decisions based on fact not forecasts… …create and respond to feedback…
2013-‐10-‐24
7
13
ConHnuous planning
StartStart
14
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
2013-‐10-‐24
8
16
Rolling (conHnuous) Plan
• Updated frequently • Takes changed circumstances into account • Is detailed only when facts allow it • Is detailed as we learn more
2013-‐10-‐24
9
17
The detail of planning
• A licle effort helps a lot • A lot of effort only helps a licle more
Acc
urac
y
Effort
2013-‐10-‐24
10
Planning onion
Planning levels
2013-‐10-‐24
11
Purpose of
Release Planning
To get rough answers
• When can this be done? • How much can be done by then?
2013-‐10-‐24
12
Release burnup Delivered features
time
Fixed scope Delivered features
time
When will this much be done?
Around middle of March
2013-‐10-‐24
13
Fixed scope Delivered features
time
When will this much be done?
Around middle of March
Fixed date Delivered features
time
What will be done by February 1st?
Some of these
All of these
2013-‐10-‐24
14
Fixed date & scope Delivered features
time
Can we get all of THIS
done...
....by February
1st?
No. That is unrealistic.
Fixed date & scope Delivered features
time
We can get THIS much done by February 1st ...and the rest done
by mid March.
No. That is unrealistic.
2013-‐10-‐24
15
An Agile approach to planning
Conditions of Satisfaction (user stories,
budget, schedule)
Release planning
Iteration planning
Conditions of Satisfaction
(user stories, test)
Development Product increment
Release
Feedback
Feedback
Iteration
How long will it take
• ...to read the latest Harry Pocer book? • ...to drive to your home town?
2013-‐10-‐24
16
EsHmate size; derive duraHon
Size Calculation Duration
300 kg Velocity
= 20
300/20= 15
iterations
Measures of size
• TradiHonal measures of size – Lines of Code – FuncHon Points
• Agile measures of size – Story Points – Ideal Days
• Traditional and agile measure size differently
2013-‐10-‐24
17
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
Release plan Iteration plan
Three levels of planning...
Daily plan
Daily plan
Daily plan
Iteration plan
Daily plan
Daily plan
Daily plan
2013-‐10-‐24
18
...three levels of precision Product Backlog
Iteration 1
As a frequent flyer I want to... 30
As a frequent flyer I want to... 50
Iteration 2
As a frequent flyer I want to... 50
As a frequent flyer I want to... 20
As a frequent flyer I want to... 20
Iteration Backlog Code the UI 8
Write test fixture 6 Code middle tier 12
Write tests 5 Automate tests 4
”Yesterday I started on the UI; I should
finish before the end of today.”
Release Planning
Release Plan
Sprint 1 Sprint 2 Sprint 3 Sprint 4-7
2013-‐10-‐24
19
Input
• Product Vision
• Product Backlog
• Release Goal
• Velocity
Results
• Release Plan ... • ... and even more important:
– Learning – Understanding – Transparency of risks
2013-‐10-‐24
20
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
Planning a Release
2013-‐10-‐24
21
Business
Development
- when a release is needed, - what functionality it must contain, and - acceptable level of quality and cost
1. Determines
- how long it takes to build the release
2. Determines
- Creates preliminary estimates - Refines estimateds as priority increases - Selects what to work on for each Sprint
3.
- Focuses on Business Value derived from the release 4.
Product backlog This Sprint : well defined work that can be done in <30 days & produce executable product
Planned Release
Future Releases
Probable next sprint : backlog next in priority, depends on results from prior Sprint
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.
2013-‐10-‐24
22
Release planning
43
Release Plan Sprint 1 Sprint 2 Sprint 3 Sprint 4-7
Release planning meeting
An example with velocity = 14
44
Sprint 1
Story A 5
Sprint 2
Sprint 3-7
Story B 8
Story E 1
Story I 5
Story B 8
Story E 1
Story K 13
Story C 3 Story D
5
Story F 5 Story G
1
Story L 1
Story H 5
Story M 4
Story J 8
Story P 12
Story N 6
Story Q 4
Story O 1
Story R 8
2013-‐10-‐24
23
An esHmaHon unit
45
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
Release Planning
46
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
2013-‐10-‐24
24
47
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
0
10
20
30
40
1 2 3 4 5 6 7 8 9
Velocity is measured
in the units you use
to estimate product
backlog items
Sprints
Look at velocity in a few ways
48
0
10
20
30
40
1 2 3 4 5 6 7 8 9Sprints
Last Observation = 36
Velocity
Mean (Last 8) = 33 Mean (Worst 3) = 28
2013-‐10-‐24
25
Extrapolate from velocity
49
At our slowest velocity we’ll finish here
At our long-term average we’ll finish here
At current velocity we’ll finish here
Will have
Might have
Won’t have
50
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
Might have
Won’t have
6x15
6x20
2013-‐10-‐24
26
51
Fixed-‐scope planning: an example
Total story points desired 120
Realistic velocity 15
Optimistic velocity 20
120÷20=
120÷15=
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.”
2013-‐10-‐24
27
Summary
Σ AcHon plan
2013-‐10-‐24
28
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 [email protected] www.aqqurite.se www.twicer.com/ArneAhl hcp://www.linkedin.com/in/arneahlander