The document provides an agenda and guidance for facilitating a multi-day release planning event involving breakout sessions at both the track and team levels. Key points include: - The event will use breakout rooms for teams to decompose features into user stories, size stories, identify dependencies, and populate a release plan across 8 sprints. - Guidance and "cheat sheets" are provided on techniques for feature decomposition, story sizing, and identifying risks. Sample user stories are to be pre-loaded. - Each day involves breakout sessions, with time for leadership reviews and adjustments. On day 3 teams will present plans to track leads and participate in a confidence vote. - In breakouts,

1. 1
Facilitating
Release Planning Event
beyond “SAFe” Scale!
Ravi Tadwalkar
Agile Coach, WD;
Co-founder, "Cisco Internal Coaches Network";
Event Organizer, AgileCamp.org & SVALN

2. Agenda
• Scrum Overview
• Release Planning Overview
• Agenda For Breakout Sessions
• Day 1
• Day 2
• Day 3
• Breakout Flow (Track/Team level)
• Breakout Room: Artifacts Overview
• Breakout Flow: What will happen in Breakout Rooms
• Track/Team level Board
• Tips for release planning
• Tips for facilitators/coaches
• What to expect 2

3. Scrum Overview
For the purposes of release planning, here’s a few key agile/scrum concepts:
• Release – a planning timebox (e.g. 3 months) - overlaps with external releases
• Sprint – a time-box (e.g. 2 or 3 weeks) in which we (tend to) complete work
• Feature – a high level product requirement from product management
• A feature may cross teams but should be completed in one release
• Each team determines any work they have for a feature – and breaks that
work down into User Stories in a product backlog
• Product Backlog – list of User Stories that represent “slices” of feature
• User Story – a team-specific “end-to-end slice” to be completed in one sprint.
• Functional/Technical Spike – a short, time-boxed piece of research, functional
or technical, for a feature or user story. It is intended to provide just enough
information that the team can estimate the size of the feature or story.

4. Release Planning Overview
4
• What is our release plan for next 8 sprints?
• Release Plan is a forecast, not a commitment
• Strategic planning for 3 sprints or more
• More certainty and confidence near term
• High level, focused on feature decomposition
• Identify dependencies across teams earlier
• Allocate high priority user stories into sprints,
one feature at a time:
Product
Backlog
Highest
Priority
Lowest
Priority
Sprint 1
Sprint 2
Sprint 3

5. 5
Day 1 | 11/18
Agenda for Breakout Sessions- Day 1
Time Agenda
8:00 – 8:30 Breakfast
8:30 – 8:45 Welcome, Intro & Team Introductions
8:45 – 9:15 Business Strategy Product Vision & Roadmap
9:15 - 10:00 Technology Strategy Architecture Vision & Roadmap
10:00 – 10:15 Break
10:15– 10:45 Development & Deployment Practices
10:45 - 11:00 QA Automation
11:00 - 11:15 Team Breakout Instructions
11:15 – 12:00 Lunch
12:00 – 1:00
Team Planning Breakout Sessions:
Defects Overview (PO) followed with Features Overview (PO)
1:00 – 5:00
Team Planning Breakout Sessions:
Decompose Features into stories for release plan update
Scrum-of-Scrums (hourly) for GIVEs and GETs
5:00 – 5:30 Leadership Review & Planning Adjustments (if necessary)
6:00 – 8:00 Happy Hour (Team building event)

6. 6
Day 2 | 11/19
Agenda for Breakout Sessions- Day 2
Time Agenda
8:00 – 8:30 Breakfast
8:30 – 8:45 Day 2 Plan: Team Planning Breakout Session Guidelines (Updated)
8:45 – 12:00
Team Planning Breakout Sessions
Decompose Features into stories for release plan update
Scrum-of-Scrums (hourly) for GIVEs and GETs
12:00 – 1:00 Working Lunch
1:00 – 5:00
Team Planning Breakout Sessions:
Decompose Features into stories for release plan update
Scrum-of-Scrums (hourly) for GIVEs and GETs
2:00 – 5:00 Team Readouts to Leadership (PO briefs current Plan, Obstacles, Risks)
5:00 – 5:30 Leadership Review & Planning Adjustments (if necessary)

7. 7
Day 3 | 11/20
Agenda for Breakout Sessions- Day 3
Time Agenda
8:00 – 8:30 Breakfast
8:30 – 8:45 Day 3 Plan: Team Planning Breakout Session Guidelines (Updated)
8:45 – 12:00
Team Planning Breakout Sessions
Decompose Features into stories for release plan update
Scrum-of-Scrums (hourly) for GIVEs and GETs
12:00 – 1:00 Working Lunch
1:00 – 4:30
Team Planning Breakout Sessions:
Decompose Features into stories for release plan update
Scrum-of-Scrums (hourly) for GIVEs and GETs
2:00 – 4:30
Team Readouts to Track Leads
(PO briefs current Plan, Obstacles, Risks)
(Leadership team facilitates consensus-driven Confidence Vote)
4:30 – 5:00 Team Retrospectives

8. Breakout Room: Artifacts Overview
8
Feature
s
Input artifacts Process artifacts Output artifacts
• 1 List of
Features
(Use large
stickies for In
scope and de-
scoped
features)
• 1 List of Defects
(In scope and
de-scoped
defects)
• 1 Story sizing board
• 1 Story sizing cheat-sheet pre-loaded with sample user stories
• 1 Feature Decomposition Cheat-sheet with sample user stories
• 2 Cheat sheets for scenario-based story writing
• 1 Cheat Sheet of powerful questions for coaching & facilitation
• 1 Obstacle Board
(Use large stickies for escalating risks & impediments)
24 Track/Team level
Release Planning
boards
(for all 8 sprints)
Legends page
(to indicate 5 colored
stickies for 5 types of
things on this board)
ROTI style informal
asynchronous
retrospective

9. 9
Output Artifact: Release Planning Board (for team rooms)
Give = Someone else
depends on your
feature or story
Get = Your feature or
user story depends
on someone else
Feature RisksUser Story
PTO /
Training
Defects
Track Name: xyz Release #
Team Name: xyz Sprint 1 Sprint 2
Feature 1
(Target Month)
Feature 2
(Decomposition)
Sprint Backlog
(Child Stories)
Upcoming Events
(e.g., PTO, Training,
Holidays)
PTO
Jing Brewer
(10/27 – 10/31)
Training
Andrew Lim
(11/3: 4 hrs)
Feature ID -
Feature Name
(Owner)
(Target Month:
Jan’15) PO
Owner
Type of Event
Name
(Date and Duration)
F456 – This is a
fake feature Rob H.
depends on
(Chandra)
(Target Month:
Feb’15) Rob
H.
User Story
Summary
(Owner)
PO
Owner
This is a fake user
story Rob H.
depends on
(Chandra)Rob
H.
This is a fake user
story that depends
on Rob H.
(Chandra)Rob
H.
User Story
Summary
(Owner)
13
3
5
5F789 – This is a
fake feature Rob H.
depends on
(Chandra)
(Target Month:
Feb’15)

10. 10
• Rule of thumb: get the most value with the minimum effort
Choose the split that leads to the biggest difference in value.
Choose the split that leads to the smallest difference in size
• Patterns for Decomposing
Features into user stories
1. On operation boundaries
2. On business rules
3. On effort boundary
4. On complexity
5. On data types
6. On input methods
7. On requirement type
8. On workflow boundaries
9. On engineering activity
10. On architectural boundaries
- this is your last resort,
when nothing else works!
Here are 10 examples of patterns for feature decomposition into vertically sliced user stories:
Please pre-load this cheat-sheet with sample user stories from your existing product backlog.
Put those sample stickies next to each decomposition pattern here!

11. 11
Please pre-load this cheat-sheet with sample user stories from your existing product backlog.
Put those sample stickies next to each decomposition pattern here!
Pattern Original story Split stories
Identify operational boundaries
I'd like to manipulate posts
on wiki
 I'd like to edit a post
 I'd like to share a post
 I'd like to delete a post
Identify independent business rules I'd like to search for a post
 I'd like to find posts from a specific person
 I'd like to find posts sent or received in a specific date range
 I'd like to find posts pertaining to a certain topic
 I'd like to find posts linking to a certain post
Perform what-if analysis to account for technical or
scheduling dependencies and identify an effort boundary
I'd like to see an up-to-date
contact list in chat window
 I'd like to see an up-to-date contact list in my chat window:
o need to poll server periodically
o When notifications are implemented, we can leverage API
Isolate the simple from the complex
I'd like to share knowledge
and information with others
 I'd like to quickly share mostly text and maybe a link, a-la Twitter
 I'd like to add embedded images and multimedia content to my posts
 I'd like to add references to external data to my post, updated on-the-fly
Handle various data types separately whenever possible
I'd like to ignore updates I
am not interested in
 I'd like to ignore updates from a specific person
 I'd like to ignore updates in a specific community

12. 12
Please pre-load this cheat-sheet with sample user stories from your existing product backlog.
Put those sample stickies next to each decomposition pattern here!
Pattern Original story Split stories
Provide the user with different ways to input
data into the application
I'd like the application
to help me with the list
of users I'm sharing a
post with
 I'd like to be able to pick people from a list of contacts I'm most
often in touch with
 I'd like to be able to search for people in the corporate directory
 I'd like the application to auto-complete a person's name as I
am typing it.
Separate functional and non-functional
requirements
I'd like to be able to
attach files to a post
 I'd like to be able to attach multiple files to a post. It's OK if I
have to add each one separately.
 I'd like an easy way to attach multiple files to a post. Multiple
select, drag-and-drop or any other form is acceptable so long as
I don't have to add each file separately.
Identify workflow boundaries
I'd like the system to
assist me in creating a
post
 When I add a post title, I'd like the system to look for similar
posts and give me an option to comment or edit them instead so
as to avoid effort duplication
 I'd like to link data from other posts into the post I am creating
and have the system update it automatically
Split out the research from the implementation
I'd like to configure the
application to my own
taste
 As an engineer, I need a framework to handle user preferences
so that I can make certain aspects of the application
configurable
 As a user, I'd like to be able to set user preferences in order to
configure the application the way I like it

13. Work Complexity Risk Points
Small Small Small 1
Small Small Medium 2
Small Small Large 5
Small Medium Small 2
Small Medium Medium 3
Small Medium Large 5
Small Large Small 3
Small Large Medium 5
Small Large Large 8
Work Complexity Risk Points
Medium Small Small 3
Medium Small Medium 5
Medium Small Large 13
Medium Medium Small 5
Medium Medium Medium 8
Medium Medium Large 20
Medium Large Small 8
Medium Large Medium 13
Medium Large Large 20
Work Complexity Risk Points
Large Small Small 8
Large Small Medium 13
Large Small Large 20
Large Medium Small 13
Large Medium Medium 20
Large Medium Large 20
Large Large Small 20
Large Large Medium 20
Large Large Large 20
Facilitators recommend that teams should use “user story sizing board” together with
this cheat-sheet. Please pre-load the cheat-sheet with sample user stories from your
previous release, specific ones for your team. New teams can use their domain to
define what small work is for their specific context. There is “no one size fits all”.

15. • We need to take feedback from attendees for our next release planning event!
• After Team Readouts, as team members start leaving, they put a colored dot on the
ROTI line which ranges from “being sleepy” to “being excited”. Sticky for comments if
need be.
• This is so asynchronous that we don’t have to facilitate it as a formal retrospective event!

16. Tips- What will happen in
Breakout Rooms
• Sprint #1 is 15 days this time, due to holiday overlap.
• Plan Sprints 1 to 3, You May Be Tentative for Sprints 4 to 7
• Identify all your key features to inform the leadership what you can do (IN)
and not do (OUT). There is a lot of back & forth between the teams – mostly
understanding and minimizing dependencies (GIVEs & GETs)
• Writing should be legible, pithy, and understandable
• Velocity established based on velocity trend
• Please do not equate story points with person days, use cheat sheet
• In breakouts, each team breaks down their features into user stories which
are sized and placed into Sprints
• All stories estimated using sizing board & cheat-sheet
• For slack, load sprints such that capacity is less than planned velocity
• Identify impediments & risks; use obstacle boards to escalate/mitigate16

17. Tips- What will happen in
Breakout Rooms (Contd.)
• “Until you get it!” approach means no prescription for
how many sprints teams will use SAFe normalization formula
• Plan for full regression at feature level (existing functionality). E.g.
test cases for OpenStack components.
17

18. 1 – PO talks about a Feature
- Timebox this to 15 minutes!
Breakout Flow
Feature 899:
Enable the LAN frobot capability

19. 2- Decomposition: (60 minutes!)
Break feature down into User Stories
Note: 1 per sticky –
NO STICKING ON TOP OF EACH OTHER
Not using Rally yet!
Prefix spike story with [SPIKE].
And these stories will be high level,
i.e. don’t task out during breakout as yet
Breakout Flow
As an admin,
I need to enable
a frobot so that..
[SPIKE]
As an mobile user,
I need an app
installed so that..
The frobot must
be able to handle
500k calls / sec
Add the frobot
billing API for
the Acme co.
Investigate the
API standard
for a frobot

20. 3a- Size each story in story points
Use planning poker to size user stories.
When in doubt, refer to sizing cheat-sheet, based on work, complexity & risk.
Use sizing board for sizing relative to other stories, and adjust the size!
Breakout Flow
As an admin,
I need to enable
a frobot so that..
8
As an mobile user,
I need an app
installed so that..
3 The frobot must
be able to handle
500k calls / sec
5
Add the frobot
billing API for
the Acme co.
13
Investigate the
API standard
for a frobot
5

21. For planned velocity, we will use velocity trending data.
New teams can use Roman Pitchler’s story sizing scale.
Be sure to adjust for holidays and vacation.
4 – SM sets team Velocity
for 1st sprint in 5 minutes
Capture this on each sprint
sheet in the top right corner
Breakout Flow
Sprint 1 Velocity: 34

22. Sprint 2 Velocity: 34Sprint 1 Velocity: 34
5- Place stories in
sprints
You may move stories
multiple times based
on GIVEs & GETs
(dependencies) and
other features, and
priorities !
Stick with stickies!
You can use little BLUE &
RED dots to identify
dependencies
Use Obstacle Board for
escalating issues with
stories & sprint execution
cycle.
Breakout Flow
As an admin,
I need to enable
a frobot so that..
8
As an mobile user,
I need an app
installed so that..
3
The frobot must
be able to handle
500k calls / sec
5
Add the frobot
billing API for
the Acme co.
2
Something
Or something
Else
8
Investigate the
API standard
for a frobot
8
GET
GIVE

23. Sprint 1 Velocity: 34
6 – Repeat
Keep breaking down features,
creating stories and placing them in
sprints until you fill
sprints 1-3 with confidence
& sprints 4-7 tentatively.
You’re done with breaking down features
Breakout Flow
xxxx
Abdlkjs
djdl
Abdlkjs
djdlAbdlkjs
djdl
Abdlkjs
djdl
Sprint 2
Abdlkjs
djdl
Abdlkjs
djdlAbdlkjs
djdl
Abdlkjs
djdl
Sprint 3
xxxx
Abdlkjs
djdl
Abdlkjs
djdlAbdlkjs
djdl
Abdlkjs
djdl
Sprint 4
Abdlkjs
djdl
Abdlkjs
djdlAbdlkjs
djdl
Abdlkjs
djdl
Sprint 5
xxxx
Abdlkjs
djdl
Abdlkjs
djdlAbdlkjs
djdl
Abdlkjs
djdl
Sprint 6
Abdlkjs
djdl
Abdlkjs
djdlAbdlkjs
djdl
Abdlkjs
djdl
Abdlkjs
djdl
Abdlkjs
djdl
Abdlkjs
djdl
Abdlkjs
djdl
Sprint 7
Velocity: 34 Velocity: 34
Velocity: 34 Velocity: 34 Velocity: 34 Velocity: 34

24. 8 – Identify Impediments &
Risks
As you go along, anytime a
significant obstacle or risk is
identified that is high enough level
to raise to the attention of the
leadership, capture it on the larger
sticky and put it on the Obstacle
Board to escalate/mitigate!
During execution after the release
planning event, you can apply your
obstacle removal process.
Breakout Flow
Obstacle Board
Something pretty
bad that might
happen here
Something pretty
bad that might
happen here
Something really
really bad that
might happen here
The entire team
may well quite
because of how
awful this is

25. Obstacle Board
Breakout Flow
9 – Read Out
These sheets together represent the readout to the leadership.
Your PO will lead readout but your team should help with questions that may
arise.
Focus on the sprints that you have planned so far, for example first 3 sprints.
Also discuss the obstacles raised during the planning so far.
Sprint 1 Velocity: 34
Abdlkjs
djdl
Abdlkjs
djdl
Abdlkjs
djdl
Sprint 2
Abdlkjs
djdl
Abdlkjs
djdlAbdlkjs
djdl
Abdlkjs
djdl
Sprint 3
xxxx
Abdlkjs
djdl
Abdlkjs
djdl
Velocity: 34 Velocity: 34

26. Tips for Breakout Planning
1. The coaches will be wandering by and available to answer questions or
provide assistance if you get stuck
2. Use legends page to check what colored stickies to use for your features,
stories, defects, events and risks. Some recommendations:
1. Only 1 item per sticky; Use larger stickies for easy identification of risks
2. Have “Stop Starting, Start Finishing” attitude. So don’t stack up stickies.
3. Write estimates in story points on 1 corner of each sticky
4. Use sizing board & sizing cheat-sheet to do estimating first.
5. Don’t get stuck if you don’t fully understand the work
• Plan some spikes, when the feature or technology is not clear yet
• Hold conversations to confirm GETs & GIVEs for features & stories
3. Choosing your team velocity based on trending from your sprints
• Consider vacations, holidays, other things that may affect velocity
• If your team is new, hold back some of your capacity for unknowns – how
much depends on team and the level of surprises you might expect
4. Try to minimize your use of Rally and other online tools – use paper for
most of this work and deal with loading Rally after the planning

27. Tips for Facilitators/coaches
1. You will be wandering by and available to answer questions or provide
assistance if teams get stuck
2. Please ensure that PO is engaged with the teams, and that s/he uses Rally
once the story sizing board looks decent and that the level of
decomposition is upto his/her satisfaction
3. If you are familiar with “Tribes” as an agile coaches tool, then it is possible
to use it instead of fist-of-5. Watch out for type A personalities, who don’t
necessarily like out-of-comfort-zone situations like that.
4. Likewise, use Constellations (-with caution in case surrounded with type A
folks- ), so that you can assess whether the team understands what PO
described as a feature.

28. What Else to Expect
1. You’ll be able to go back and revisit the stories in the 2nd day breakouts to
take them down to another level of detail.
2. The leadership may adjust the priorities at the beginning of the 2nd day
based on what they hear from you and the other teams on the 1st day. This
will include the breakout format based on ongoing feedback.
3. The “GETs & GIVEs rep” will leave on the hour to synch up in a “scrum of
scrums” back in the main room
• Your team needs to be self-organizing and keep making progress even if
the coach/facilitator and/or SM have stepped out!
4. Dependencies:
• Other teams may send delegates to visit you at any time
• This will usually be to talk about a GET dependency on your team
• Please stop to deal with these interrupts in a timely way
• This will often add a story or two to your sprints
• you may have to adjust the priority of work to maximize the overall output

29. What else can happen in
Breakout Rooms
• Some sprint may be longer due to holiday/shutdown overlap.
• Plan Sprints 1 to 3, You May Be Tentative for Sprints 4 to 7
• Top 10 Features should be prioritized for release planning, ideally those should
come from Rally, so the those Feature IDs will be used on the list artifacts.
• This will avoid the “Walk of shame” syndrome (i.e. blank feature list)!
• Identify all your key features to inform the leadership what you can do (IN) and not
do (OUT).
• We don’t prescribe how you do your “fist of 5” after feature review.
It can even be a “can we decompose now?” question.
• Coaches/Facilitators should watch out for GIVEs
• You have to facilitate an utterly confused atmosphere due to a lot of back &
forth between the teams mostly during (mis-)understanding and minimizing of
dependencies (GETs & GIVEs)
• “GET” dependency may end up creating a story on GIVE(r) team’s sizing board!
• Dependency tracking will not “STOP THE LINE”. This way we don’t interrupt
teams doing their planning timebox. We have a separate pomodoro for tracking
GETs & GIVEs.
• Note that we are applying pomodoro technique for time management during
planning timebox method!
29

30. • “Until you get it!” approach means no prescription for how many
sprints teams will use SAFe normalization formula of “1 SP per day
per person”!
• Consider this as a baby step towards “pure” scrum style empirical
estimation process!
• Plan for full regression at feature level (existing functionality).
30
What else can happen in
Breakout Rooms (Contd.)

31. What else can happen in
Breakout Rooms (Contd.)
• When do teams take short break during planning timebox?
• We suggest taking breaks each time feature is sized, just before
dependency frenzy kicks in!
• Ensure that stickies are readable: writing should be legible, pithy, and
understandable
• For slack, load sprints such that capacity is less than planned velocity
• Identify impediments & risks; use obstacle boards to escalate/mitigate
• All Coaches/facilitators (internal/external) will need tool access, just in case.
• QA & DevOps are now part of release planning
• Shared team members are still going to be concern for release leadership
and SM team
• Facilitators may have to monitor how and when stories are entered in Rally;
perhaps do that by themselves.
31

32. What else can happen in
Breakout Rooms (Contd.)
• Please have a Sticky/sign on your door stating that you need a coach!
• Someone will be with you shortly!
• Facilitators may have to monitor how and when stories are entered in Rally;
perhaps do that tby themselves.
• From now until release planning day, you will have to watch evolving
roadmaps very closely
• This will answer: how many features teams will bring into next release!
• There will be code deployment schedule artifact
• We trust SM/facilitator’s judgement when dealing with edge-case scenario
of not having SME/expertize within the team for a feature or story!
32

33. What else can happen in
Breakout Rooms (Contd.)
• Use 1st hour or 2 for S1 & S2 defects prioritization!
• When addressing risks & obstacles, give priority to “GIVE” type dependencies
• What if GET dependency cannot be discussed right now?
I would keep it near the sizing board, clubbed under “unscheduled dependencies”.
• Assign a primary owner to each user story, for tracking it using “dependency
exchange market”.
• Use your best judgement to decide when to take feedback on the planning timebox
method & the overall planning process.
• Leadership team will schedule time-slots for “dependency exchange market”, and
adjust those based on feedback from facilitators & coaches.
• You need to socialize changes to the release planning process to the larger
audience, to set the baseline. E.g. user story sizing process, how to use various
reference cheat sheets, etc.
33

34. What else can happen in
Breakout Rooms (Contd.)
• Product owners should write user stories in Rally as soon as they can!
• Avoid last minute rush to enter a large batch of stories in Rally.
• Facilitators should ensure existence of Acceptance Criteria (AC’s) for
user stories entered in Rally.
• Facilitators should watch out for “rat holing” situations, and ask those
team members to move those conversations to parking lots during
breaks.
• Leadership, coaches, PO community as well as SM community will all be
overloaded during those 3 days. Use your facilitation skills to resolve as
many conflicts as you can.
34

35. Deep Dive
(Detailed slides)
35

36. What is a User Story?
A user story is a lightweight requirement written from an
end user’s perspective.
A user story follows the format:
As a <user>
I want to <do something>
so that <I get value>.
• This format is recommended but it’s NOT required to
write every requirement as a user story.
• User stories help us think in terms of business value
• We try to keep these at a business level and defer
talking about the technical implementation until sprint
planning
36

37. Estimating Story Size: Points
& the “Faux-binacci” Scale
{0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100}
small medium large
This is a form of relative estimation.
“easy”
“simple”
“known”
“difficult”
“complex”
“unknown”
37

38. • The concept is difficult to explain to the business and even the
team if they’ve had formal cost engineering training or
experience or are simply new to Agile
• Estimates in story points must be subject to numerical
operations for estimating large backlogs to be viable. 1+1 must
equal 2.
• Large projects with many teams working off the same backlog,
or a backlog-of-backlogs, need to have a common baseline for
story sizes or else estimates can’t be reliably rolled up for
planning.
• During planning, various team members need to exercise
discipline and provide objective rather than subjective estimates
(i.e. how big a story is vs. how much work it is for me). This is
very difficult as engineers traditionally view estimates as
commitments.

39. Story Size Ideal Team Days Points
Trivial Done before you can say “Gobbledygook” 0 or 1/2
Tiny One 1
Very Small A couple of days, max 2
Small A few days 3
Average A week or so 5
Large About two weeks 8
Very Large Three weeks, maybe 13
Huge A month 20
Epic
If this is the only thing we do the whole 16-week Mile Run,
we might just finish it, but might as well not
40
Unknown Not really sure how much, but definitely a lot 100
Pros: Relatively simple to use
Cons: Fuzzy, generic, subjective

40. Work Complexity Risk Points
Small Small Small 1
Small Small Medium 2
Small Small Large 5
Small Medium Small 2
Small Medium Medium 3
Small Medium Large 5
Small Large Small 3
Small Large Medium 5
Small Large Large 8
Work Complexity Risk Points
Medium Small Small 3
Medium Small Medium 5
Medium Small Large 13
Medium Medium Small 5
Medium Medium Medium 8
Medium Medium Large 20
Medium Large Small 8
Medium Large Medium 13
Medium Large Large 20
Work Complexity Risk Points
Large Small Small 8
Large Small Medium 13
Large Small Large 20
Large Medium Small 13
Large Medium Medium 20
Large Medium Large 20
Large Large Small 20
Large Large Medium 20
Large Large Large 20
Pros: More aligned to Engineers’ way of thinking, scale easier to pick from
Cons: Teams can’t always separate the three factors.

41. • Came up with actual calculations to generate the Cheat Sheet
• Basic assumptions
• Work is an additive factor. This is due to various activities
(coding, testing etc.) being independent of each other and
adding up.
• Complexity is a multiplicative factor. It scales with the
number of areas and team members affected.
• Risk is an exponential factor. The probability of getting it
right follows an inverse power law based on the number of
unknowns you’re dealing with.
Small Medium Large
Work 1 3 8
Complexity 1 1.5 2.25
Risk 1 2 4
Buffer factor 1.2

42. Product Backlog 101
High Value &
More Detail
Low Value &
Less Detail
} Each iteration implements the
highest priority stories.
Any new request gets
prioritized within the existing
stack
Stories may be removed at
any time
Stories may be reprioritized
at any time
42

43. Agile
PRODUCT OWNER (VoC)
Sets the Vision and
Product Roadmap
Manages and Owns
Product Backlog
Orders by Business Value
Determines Acceptance
Criteria
Works with team daily
ScrumMaster
Team Process Conscience
Organizer/Facilitator
Remove Impediments
Prepares & challenges Team
Liaison to Stakeholders (+ PO)
Updates Information Radiators
Works behind the scenes
DEVELOPMENT TEAM
Cross-functional
Self-organizing
Estimates the Work
Creates a Plan for the
Iteration
Commits to the Work
Demonstrates Working
Product for Feedback
Business Knowledge Process Knowledge Technology Experts
3 Scrum Roles

44. 44
What comes out of the Breakout Session?
Each team had the same deliverables:
 An objectives sheet
 One sheet per sprint for stories
 One risk sheet for risks and impediments
Your deliverable is primarily in Features / Objectives
NOT NEEDED

45. 45
Team Breakout #1: Objectives
Team’s Release Objectives...
 They often will map directly to the features in
the backlog... and they sometimes may not. For
example
– aggregation of a set of features stated in more
concise terms
– a milestone like “trade show demo.”
– an architectural feature?
– a major refactoring
 At the end of day 3, teams will be committing to
these objectives, not individual stories
Objectives are brief summaries, in business terms, of what
each team intends to deliver in the upcoming release
NOT NEEDED

46. 3b- Prioritize each story
after sizing
Prioritize the stories as well.
We develop stories in priority too!
In some cases we may defer some
stories out of the release in order
to get to other features. Work
with your PO to make those
decisions.
Breakout Flow
As an admin,
I need to enable
a frobot so that..
8
As an mobile user,
I need an app
installed so that..
3
The frobot must
be able to handle
500k calls / sec
5
Add the frobot
billing API for
the Acme co.
2
Investigate the
API standard
for a frobot
5
IN OUT
NOT NEEDED

47. 7 – Capture the Objectives
that you are delivering
Objectives will often be
features or parts of features.
In some cases, they may be
something else that your team
feels is a critical delivery to the
business.
Breakout Flow
Objectives
1. Enable the LAN frobot capability
2. Delivering the admin portions of the
buzhop feature
3. Deliver a working prototype for the
Buzz 2014 conference
4. Refactor the Zimbug module to
improve the mantainability of our
code
Stretch Objectives
1. Deliver a POC prototype to Acme
NOT NEEDED

48. 48
The Release Planning Process (SAFe)
Top Biz
features
ranked
Vision
Team A PSI
Objectives
Team B PSI
Objectives
Team C PSI
Objectives Team J PSI
Objectives
Program PSI
Objectives
...
Program Board
Input: Vision and Requested features
Output: Objectives and Program Board
Objectives are often features
or partial features that your team
is delivering
NOT NEEDED

49. 49
Release Planning Output
PSI Objectives
Objectives /
Business Value
1. ...
2. ....
3. ...
Stretch Objectives
1. ...
Sprint 1 Sprint 2 Sprint 3
Yellow
Pink
Blue
= Dependencies
or issues
(Small Sticky to
put on top of a
user story)
= User Stories = Spikes
Sprint 5-7Sprint 1.4Sprint 4
HIP Sprint
X
0
Risks
Color coding gives visibility into the work
…..
Your team will fill out all these sheets
and use this as your output to the
larger organization
NOT NEEDED