Agile camp releaseplanning

AGENDA
Why is this important?
When should the team release plan?
What does release planning look like?
Closing your release plan and what comes
next?

 An event, not a meeting
 Will seem chaotic at times
 May seem slow at other times
 There is a “method to the madness”

 Helps the Product Owner and whole team to determine how
much MUST be developed, and how long that will take before
they have a releasable product.
 Serves as a guide to which the team can progress
 Shows how iterations fit into the “whole”
 Extends visibility past a single sprint to help make informed
decisions
 Gives the scrum team(s) a chance to understand the complete
set of functionality in the product

Create a Release Plan that provides the following:
 Initial agreement, update current commitments
 Allows external teams/sources to understand goals and
objectives
 Risks and Dependencies to be identified
 To allow the organization to make informed decisions and
support the plan
Where
you
are
Where
you
want to
be
Lots and
lots of
work

 Backlog readiness
 Team has a better understanding of the whole picture
 Understanding of what it takes to release
 Baseline that has the stakeholder confidence because they
were invited into the process
 Collective ownership of a plan
 Outlines the impact of incoming work

 Whenever you need greater than 1 sprint’s worth of visibility
into the plan
 Multiple teams are potentially involved
 After you have established the team(s) velocity

 Will take 1-2 days of planning and
at least a few weeks of
preperation
 Story mapping can happen
before or during, but it will
stretch the planning session
if done together
 3-4 times a year based on
average
 PO, Team, SH(s)
 Product backlog
 Prioritized backlog by PO
 Estimated backlog
 What is the purpose you hope to
accomplish
 Release theme
 Current state of team
 Velocity?
 DoD
 Will everyone be in attendance
(contingency plans)
 Key members

 All necessary members to complete the project in attendance
 Opening the session
 PO will go over the Product Vision
 Essential for teams to be able to see the whole picture
 PO will represent the Product Roadmap
 Organizes themes of features
 Updated 3-4 times per year
 Event Purpose
 Acceptance criteria for session
 Agenda and Schedule
 Working agreements

 The team(s) breakout to:
 Organize the backlog(s)
 Line up stories in priority order
 Clarify AC
 Identify potential sprint boundaries (velocity, current estimations,
key dates)
 What starts to happen…
 Reality vs. Plan starts to emerge
 Stories will emerge that do not fit into the plan – fail fast
 Tradeoffs start to happen

Photos from Story Mapping session in Lincoln for the IDR team (7/9/15)

 After the team(s) breakout a “Walk the Walls” activity happens
 An opportunity for the teams to walk the room and talk to other
teams.
 Identifies potential dependencies
 Identifies duplicated efforts
 Helps to align work between teams
 After a “Walk the Walls” happens or if only 1 team, now it is an
opportunity for the PO to “Walk the Wall” with the SH(s).
 Once complete, feedback and information comes back to the
teams for another breakout session to work on changes and/or
“solidify” current plan

 Team(s) come back together to share plans
 Go over any decisions made
 Go over any action items and set boundaries around them
 Team Commitment
 Step through session criteria to verify all AC’s have been met
 Quick closing retro
 Thank everyone for the participation
 Head into Sprint Planning which should be much easier 
“Plans are worthless but planning is everything.”
Dwight D. Eisenhower

Agile camp releaseplanning

More Related Content

Agile camp releaseplanning

Editor's Notes