guide on running a successful release planning session - agile …€¦ · the agile release train...

January, 2015 Confidential 1

Guide on running a successful Release Planning Session

IT Delivery

January 2016

Philips IT Delivery Orchestration Office


Foreword

This guide has been created with the help of all Agile coaches that have worked hard on doing, failing, reflecting and improving our Release Planning Sessions as we know it today. All credits for this work go to them Special thanks to Henk Mooijweer, Bas Willemsen and Tom Rooderkerken, who took the time to collect all learnings and made this into a useful guide.


Contents

Introduction “RPS Runbook”

Preparing the RPS successfully

Q&A

4 Leffingwell et al. © 2015 Scaled Agile, Inc. All Rights Reserved

The Agile Release Train

A virtual organization of 5–12 teams (50–125 individuals) that plans,

commits, and executes together

Program Increment (PI) is a fixed timebox (default is 10 weeks)

Synchronized iterations and PIs

Aligned to a common mission via a single program backlog

Operates under architectural and UX guidance

Frequently produces valuable and evaluate-able system-level solutions

Define new functionality

Implement Acceptance

Test Deploy

Repeat until further notice. Project chartering not required.


Key Agile Release Train Roles

Release Train Engineer is the Chief Scrum Master

for the train

Business Owners are the key stakeholders on the

Agile release train

Product Management owns, defines, and prioritizes the

program backlog

The System Architect provides architectural guidance and

technical enablement to the teams on the train

The System Team provides process and tools to integrate

and evaluate assets early and often


Release Planning

Two days every 8–12 weeks

Everyone attends in person if at all possible

Product Management owns feature priorities

Development team owns story-planning and high-level estimates

Architects and UX folks work as intermediaries for governance, interfaces,

and dependencies

Result: A committed set of program objectives for the next PI

Cadence-based Release Planning Sessions

are the pacemaker of the agile enterprise


Our purpose Within several programs we successfully executed a 2 days Release planning session (RPS). We want to share the actions we took and the knowledge we gained during preparation and execution, so we can help other programs to be successful with their release planning sessions. Together with Organization Transition Orchestration we will keep updating this document as we gain new insights every time.


Contents

Introduction “RPS Runbook”

The Release Planning Session runbook

Q&A


Overview of steps Preparing for the Release Planning Session Every step is a number of sprints before the IP sprint. RPS will take please inside the IP Sprint

Ready Stage

3SP before IP

Pre

par

atio

n A

Ready Stage

2SP before IP

Pre

par

atio

n B

Go Stage

IP SP

RP

S After care

1SP after IP 1SP before IP

Pre

par

atio

n C

Set Stage


Preparation A – “Ready stage” At least 3 Sprints prior to the IP Sprint: • Start filling up the SAFe ART Readiness Workbook • Choose a location (country, city) • Request quotes for possible venues via assistants • Check possible meeting days with participants (invite everybody who participates

in the program) • Send out invitation to the meeting (sooner is better) • Make sure all teams and stakeholders (System team, DBT team(s), Deployment

team(s), DevOps, Release Management, Security and Authorizations, Compliance and business representatives accept the invite)

• Get travel approvals from senior management (ensure coverage of costs) • Make sure our partners can travel • Start organizing travels (who travels, who needs visa, etc.) • If travel is disapproved reserve connect rooms • Collect training demand (Agile, Scrum, Scaled Agile) and do the required trainings

before the event • Facilitate the Program Team to start creating top 10 Features

Strong advice to do the first RPS F2F, subsequent can be distributed, although F2F always bring the best result and highest quality

Ready Stage

3SP before IP

Pre

par

atio

n A


Preparation B – “Ready stage” 2 Sprints prior to the IP Sprint: • Arrange extra Agile coaching support for the event. (A coach can effectively

support max. two teams during the team breakouts) • Decide about the venue and get approval from Program management.

Reserve the Venue for the RPS days + 1 day before for preparations • Make a floor plan in the event venue (take pictures about the venue if you

can and make your floor plan digitally). • Plan a social event together as part of the RPS (e.g. dinner to celebrate the

great work you will do) • Order necessary office supply – do not forget about the Release Board –

Starter KIT can be provided by the Agile Coach • Prepare RPS Agenda (Use SAFe setup) • Facilitate the Program Team updating their top 10 Features • Update SAFe ART Readiness Workbook

Ready Stage

2SP before IP

Pre

par

atio

n B


Preparation C – “Set Stage” 1 Sprint prior to the IP Sprint: • Align with presenters (business owner, product manager, architect) on what is

expected from them (potentially schedule simulation event) • Organize a session for all participants (~ 1,5 hours) and explain high level what

will happen during Release planning. • Release Train Engineer (RTE), Agile coach and Facilitator start having daily

alignment meeting (15 minutes stand up) • Prepare Flipcharts for the venue; Release Board, RPS Purpose, RPS Agenda,

Working Agreements, Parking lot, Program Risks, Risk ROAMing, RPS SoS. • Ask the DBT teams to ensure they can estimate the User Stories either via a

Planning poker website, app, poker cards or any form they choose, as long as they apply Fibonacci.

• Alignment with Product Team on finalization of the Top 10 Features, prioritization and possible related User stories.

• Create the TOP 10 features in Rally (and preferably also the user stories) • Update the SAFe ART Readiness Workbook

1SP before IP

Pre

par

atio

n C

Set Stage


Preparation E – “Go Stage” 1 day prior to the RPS: • Prepare the venue (RTE, coaches, Scrum Masters). Make sure every team has

flipcharts, pens, sticky notes, yarn etc. (from the starter KIT). • Create sprint schedule per team per sprint (5 sprints + IP Sprint max.) • Hang all created flipcharts to the walls: Scrum of Scrums, Release board,

Program Risks, ROAMing Risks, PURPOSE, AGENDA, WORKING AGREEMENTS and team composition. The reason is that we found that we often go back to “why we are together for the 2days” (PURPOSE), “what are we going to do next” (AGENDA) and “how are we supposed to work together” (WORKING AGREEMENTS) and where do we find the person we have to talk to. (examples on next slides)

Go Stage

IP SP 1 d

ay b

efo

re R

PS


Examples Scrum of Scrum questions Dependencies overview

PI OBJECTIVES RISKS Sprint 1.1 Sprint 1.2 Velocity: 34

Load: 30

Velocity: 34

Load: 30

- …. - …. - …. - …. --Stretch Objectives-- - …. - ….


Examples PURPOSE: To co-create a plan and our business objectives for the next n sprints (n months) of work for the ….. release AGENDA: One flipchart per day. Only the topics, time is not needed. (Flipchart is only to follow progress) WORKING AGREEMENTS: • Time box our Work • Be Present • Self-Manage • Have Fun


Release Planning Session Execution

• Facilitator: before break-out sessions do check with the participants if they really understand what is expected from them.

• Facilitator, coaches: continuously observe dynamics in the room. Are there teams working in silos? Make sure there is the right level of interaction among teams and also business. Everybody has to actively participate

• Agree about next release planning days, block everybody’s agenda (1 year up front)

• Strictly time box otherwise you really run out of time

Go Stage

IP SP

RP

S


Outcome after finishing Release planning

1. All User stories in Rally available, cleaned-up and assigned to sprints nn - nn

2. Capacity (LPC Velocity) in each sprint is clear, load (Team Planned Velocity) is clear

3. Rough Assignment estimate: ****

– N % building new functionality

– N % refine / refactor flexibility

– N % leaving room for deployment topics

4. Team committed release board

5. Release x.x objectives and business value

6. Risks ROAMed (Resolved, Owned, Accepted, Mitigated) and updated risk log

7. Updated dependency log

8. Confidence vote by everyone participating the RPS

9. Partners enabled to deliver their BID response

Objectives

**** it is really up to you, how you divide the work.

Go Stage

IP SP

RP

S


After care • Collect Release board • Place it where the scrum teams are • Update Rally (assign ownership to realize, RTE to verify) • Create report out (share learning) • Send invite to the next release planning session(s) • Fill up ART assessment with Product Team, RTE, Coach(es) and Scrum Masters

After care

1SP after IP


When your maturity increases you can consider the following:

- If you have distributed planning sessions where the majority of the team is in one off-site location, let them work off-line for a few hours on detailing (part of) the backlog. Give them time to reconnect with the onsite team before the presentation moments. The onsite team members can update the (digital) release board, and the off-site members (who did majority of the work) can present.

- Involve the scrum masters in the preparation activities. They will learn a lot by doing things and that will help the facilitator to manage the agenda.

- After every planning session have a retrospective and define the top 1-3 actions that you want to improve on before the next planning session. Take note of it, and start working on it on time.

- Use the ART assessment outcome to define and execute improvement points.


If you run a Release planning session, please share with us your

learning, there are thousand ways of doing it right and we would like to

hear about the other 998.

Thank you!

[email protected] , [email protected] or [email protected]

20

mailto:[email protected]



guide on running a successful release planning session - agile …€¦ · the agile release train...

Documents