Facilitating Release Planning Event

1

Facilitating

Release Planning Event

beyond “SAFe” Scale!

Ravi Tadwalkar

Agile Coach, WD;

Co-founder, "Cisco Internal Coaches Network";

Event Organizer, AgileCamp.org & SVALN

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 expect2

Scrum OverviewFor 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.

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

HighestPriority

LowestPriority

Sprint 1

Sprint 2

Sprint 3

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:00Team 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

Day 2 | 11/19


Time Agenda


8:30 – 8:45 Day 2 Plan: Team Planning Breakout Session Guidelines (Updated)

8:45 – 12:00

Team Planning Breakout Sessions



12:00 – 1:00 Working Lunch

1:00 – 5:00




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

Day 3 | 11/20


Time Agenda


8:30 – 8:45 Day 3 Plan: Team Planning Breakout Session Guidelines (Updated)

8:45 – 12:00

Team Planning Breakout Sessions



12:00 – 1:00 Working Lunch

1:00 – 4:30




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

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

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 StoryPTO /

TrainingDefects

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) RobH.

User Story

Summary

(Owner)

PO Owner

This is a fake user

story Rob H.

depends on

(Chandra)RobH.

This is a fake user

story that depends

on Rob H.

(Chandra)RobH.

User Story

Summary

(Owner)

13

3

5

5F789 – This is a

fake feature Rob H.

depends on

(Chandra)

(Target Month:

Feb’15)

10

• Rule of thumb: get the most value with the minimum effortChoose 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

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 boundariesI'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 complexI'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 possibleI'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

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

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


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


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”.

• 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!

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

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

1 – PO talks about a Feature

- Timebox this to 15 minutes!

Breakout Flow

Feature 899:

Enable the LAN frobot capability

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 enablea frobot so that..

[SPIKE]As an mobile user,I need an appinstalled so that..

The frobot mustbe able to handle500k calls / sec

Add the frobotbilling API forthe Acme co.

Investigate theAPI standardfor a frobot

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 enablea frobot so that..8

As an mobile user,I need an appinstalled so that..3 The frobot must

be able to handle500k calls / sec5

Add the frobotbilling API forthe Acme co.13

Investigate theAPI standardfor a frobot5

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 minutesCapture this on each sprint

sheet in the top right corner

Breakout Flow

Sprint 1 Velocity: 34

Sprint 2 Velocity: 34Sprint 1 Velocity: 345- 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 mobile user,I need an appinstalled so that..3

The frobot mustbe able to handle500k calls / sec5


SomethingOr somethingElse

8


GET

GIVE

Sprint 1 Velocity: 346 – 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

Abdlkjsdjdl

AbdlkjsdjdlAbdlkjs

djdl

Abdlkjsdjdl

Sprint 2

Abdlkjsdjdl

AbdlkjsdjdlAbdlkjs

djdl

Abdlkjsdjdl

Sprint 3

xxxx

Abdlkjsdjdl

AbdlkjsdjdlAbdlkjs

djdl

Abdlkjsdjdl

Sprint 4

Abdlkjsdjdl

AbdlkjsdjdlAbdlkjs

djdl

Abdlkjsdjdl

Sprint 5

xxxxAbdlkjsdjdl

AbdlkjsdjdlAbdlkjs

djdl

Abdlkjsdjdl

Sprint 6

Abdlkjsdjdl

AbdlkjsdjdlAbdlkjs

djdl

Abdlkjsdjdl

Abdlkjsdjdl

Abdlkjsdjdl

Abdlkjsdjdl

Abdlkjsdjdl

Sprint 7

Velocity: 34 Velocity: 34

Velocity: 34 Velocity: 34 Velocity: 34 Velocity: 34

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

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

Abdlkjsdjdl

Abdlkjsdjdl

Abdlkjsdjdl

Sprint 2

Abdlkjsdjdl

AbdlkjsdjdlAbdlkjs

djdl

Abdlkjsdjdl

Sprint 3

xxxx

Abdlkjsdjdl

Abdlkjsdjdl

Velocity: 34 Velocity: 34

Tips for Breakout Planning1. 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

Tips for Facilitators/coaches1. 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.

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

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

• “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


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



• 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


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



• 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

Deep Dive

(Detailed slides)

35

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

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

• 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.

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

EpicIf this is the only thing we do the whole 16-week Mile Run,

we might just finish it, but might as well not40

Unknown Not really sure how much, but definitely a lot 100

Pros: Relatively simple to use

Cons: Fuzzy, generic, subjective


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


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


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.

• 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

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

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

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

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

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 mobile user,I need an appinstalled so that..3

The frobot mustbe able to handle500k calls / sec5



IN OUT

NOT NEEDED

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 Objectives1. Deliver a POC prototype to Acme

NOT NEEDED

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

Release Planning Output

PSI Objectives

Objectives /

Business Value

1. ...

2. ....

3. ...

Stretch Objectives

1. ...

Sprint 1 Sprint 2 Sprint 3

YellowPink

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 organizationNOT NEEDED

Leadership & Management

Facilitating Release Planning Event