AWB - 06 - Agile Planning, Release and Sprint

187 Agile White Book – AXA Emerging Markets EMEA-LATAM
Chapter 6
AGILE PLANNING
RELEASE & SPRINT
V1.0

Contents
HOW PLANNING WORKS..................................................................................................................................................................................... 190
THE AGILE BASIC ACTIVITIES ..................................................................................................................................................191
HOW EFFORT IS DISTRIBUTED ................................................................................................................................................194
HOW AN INITIATIVE IS CONCEPTUALISED..................................................................................................................................196
HOW TO START WITH A PROJECT ....................................................................................................................................................................... 197
FIRST PLANNING (PHASE ZERO) .............................................................................................................................................198
PREPARE THE COMING RELEASES............................................................................................................................................200
TAKE AWAY.................................................................................................................................................................................................. 202
AGILE RELEASE PLANNING .................................................................................................................................203
HOW TO PREPARE A RELEASE........................................................................................................................................................................... 206
REFINE THE PRODUCT BACKLOG .............................................................................................................................................208
COMPREHENSIVE PRODUCT BACKLOG REFINEMENT ..................................................................................................................210
THE EXPECTED OUTCOME ................................................................................................................................................................................ 212
TAKE AWAY.................................................................................................................................................................................................. 213
CHECKLIST 6.1.................................................................................................................................................................................................. 214
CHECKLIST 6.2.................................................................................................................................................................................................. 220
CHECKLIST 6.3.................................................................................................................................................................................................. 225
SPRINT PLANNING .............................................................................................................................................229
HOW SPRINT PLANNING WORKS......................................................................................................................................................................... 232
OVERVIEW .........................................................................................................................................................................233
SPRINT PLANNING: HOW TO .................................................................................................................................................234
UNDERSTANDING TEAM’S CAPACITY .......................................................................................................................................237
COMMON ANTI-PATTERNS .................................................................................................................................................238
TAKE AWAY.................................................................................................................................................................................................. 240
CHECKLIST 6.4.................................................................................................................................................................................................. 241

Agile Planning
Planning in Agile is an iterative activity that targets
to have an up-to-date plan rather than keeping
initial plans without changes. Quoting Dwight D.
Eisenhower: “Plans are nothing; planning is
everything”.

In Agile, planning is always a learning
exercise for the whole team that produces
different and real results and help align the
people involved with goals, milestones, and
roadblocks and get a constant feedback
from the process and clients.
HOW planning works
Planning in Agile is an iterative activity that targets to have up-to-date plan rather than keeping
initial plans without changes. Planning happens not only at the start of a project but continually
through the whole time while the team works on the project with a different focus at each stage.
Here, near-time planning is a team exercise to gather input (feedback) and gain support. The
value is not so much in the plan itself as in the planning exercise.
The value of planning with milestones and goals is that they do not intend to change
considerable parts of the product even if the underlying activities do. Keeping these milestones
fairly constant gives confidence to the team including the sponsors/stakeholders and saves
constant re-planning.

HOW planning works
THE AGILE BASIC ACTIVITIES
Agile needs some discipline from the very beginning of the project; activities and meetings always
have the same structure and follow a predetermined order:
 One or many high level planning meetings.
 Release Planning.
 Sprint Planning.
 Sprint and many Backlogs Refinements activities.
All these activities are regulated by the idea of a fixed-length event or timebox. Agile uses this very
special concept (Timebox) for all the meetings, and planning is not an exception. This is a
previously agreed period of time during which an individual/team works steadily towards
achieving the goal. The particularity is that rather than allow work to continue until the
goal is reached, and evaluating the time taken, the timebox tactic includes stopping work
when the time limit is reached and evaluating what was accomplished.

HOW planning works
In Agile, teams are always loaded with work during the Sprint Planning, followed by an iteration
(Sprint) which is typically a two to four week time-box.
Considering the aim is to have quicker feedback from the client, the plan reduces in
significance and planning gains in importance. As many projects in AXA are considerably
complex, they need different levels of planning to be in place. Otherwise, the generic view
may be obstructed. Many of these levels run generally in parallel to minimise blockings and to
facilitate constant learning and synergy of the teams towards a shared goal.

HOW planning works
In Agile there are 5 different levels of planning:
Product Vision and Product Roadmap
contain the broadest picture of the product that comprises of goals/objectives,
milestones and a high-level product Backlog (sized and prioritised). It also
defines the scope as a very rough idea of the architectural needs.
Plan of releases
creates a lower view, which includes the necessary information (risks, possible
spikes, mitigations, etc.) to take a Release to market successfully.
Sprint Plan & Sprint
organise the elements to be developed in the coming cycle.
Daily Scrum
organises the work for the current day in a Sprint.
In AXA, many of the items required by the 1st
and 2nd
stages come already packed into a
Business Portfolio that just needs to be
checked in order to align them with practises.
The major ideas found during those stages are
related to budgeting, scope, people
impacted, people needed and expectations.
The lower you go on the planning, the more
detailed it gets and thus the more people and
money will be required. This approach decreases
the risks of developing features that will not be
used. Frequent feedback on early stages helps
directing product in the right way.

HOW planning works
HOW EFFORT IS DISTRIBUTED
Effort distributed in each planning phase is different, similarly to the people involved in the
activities and techniques used. Nevertheless, there is a constant variable: all of them share the
concepts behind the Rolling Wave and Product Backlog Iceberg.
Those are applied as a metaphor to express the idea of the Rolling Wave Planning and give a
guideline of how much effort is required at each stage. The idea is not to dedicate more effort
than is necessary to things that may change or even objectives that could be cancelled. The
first thing to do is to identify where you are in order to know how to proceed.
The easiest way to understand the pyramid it is to read it from bottom (base) to top. The lower
part contains the business goals that are part of the Roadmap and that contain Epics; for
example, “we want our VIP clients to get more benefits than our Standard clients”.
On the second phase, the team takes the Epics, has a conversation and comes up with a
collection of related elements that alone confer a benefit to the user, i.e. “VIP client can access
to discounts”, “VIP Clients have rewards”, etc.

HOW planning works
Finally, the top part of the pyramid contains the requirements that are ready for the coming Sprints
(Scrum cycle). Once they are taken on-board in a cycle, they will be fully detailed (Last
Responsible Moment). The top elements are always the ones with higher priorities.
As you see, requirements are set at different levels of granularity to avoid expending effort
to detail aspects and approaches that can change and even disappear.

HOW planning works
HOW AN INITIATIVE IS CONCEPTUALISED
The conceptualisation of the project (1&2) or baseline creates a broader picture of the product
that contains the goals/objectives, milestones to conform a High Level Product Backlog
that defines the scope of the project as well as a very rough idea of the architecture.
This initial planning is carried out in a number of workshops where the Product Owner, Key
Users, Stakeholders, Scrum Master and Development Team are present. This is the first
scenario where you start using the Rolling Wave.
Apply the next steps in order to support the Rolling Wave technique:
 Identify objectives/requirements at a high level to define the vision and scope.
 Prioritize objectives (learn the art of prioritization by reading the Agile Requirements
How-to).
 Divide and plan in detail only the targets whose development is closer (or have a
real sense of urgency).
 Do not lose the Forest for the Trees; always keep a good vision.
You can use a User Story Mapping to identify dependencies and sequences of your
product features implementation; you will see the details later on in this chapter.
There are other outcomes or activities that should be expected to be completed at this level:
 Know the initial solution approach, estimated cost and any other data required by the
Business Portfolio.
 Identify high-level risks (i.e. market risks) and set initial expectations.
 Know the people who will be impacted by the product (users, manager, IT, etc.).
 Score Business requirements (i.e. using Kano Model, Moscow or any other technique)
Identify if there are similar products.

HOW TO START with a project

FIRST PLANNING (PHASE ZERO)
The Phase Zero is the initial planning session of the project. The High Level Product Backlog
is re-analysed to organise the coming releases using the ideas behind the Rolling Wave
Planning; here the closest elements are transformed into Features, User Stories, grouped into
Themes and prioritised using Business Value (Value, Cost, Risk, etc.).
Release planning meetings place emphasis exclusively on coming release(s) and make any
other required adjustments to the future in order to represent reality.
Sprint 0 has the following specific: preparing all the foundations for the project. The table
below indicates some of the outcomes:
Graphical Interface
GUI high level designs guidelines – establish some
recommendations for the User Interface.
Navigation maps – indicates some high-level relationships
between major screens and targets to address some fundamental
usability questions.
User Experience – indicates the best ways a user completes a
task.
Solution Models
Product Maps – identifies all the functional Scope, Value of each
Requirement and relationship with features.
Architectural Maps – gives an idea of the architectural/technical
solution.
Domain Models – include the needed information entities and
their relationships in order to establish a common vocabulary.
User Workflow - indicates the possible ways the target audience
of the product will use the System.

The Size of the Sprint is also defined in this stage, based on how
frequently feedback is expected from users, the process to upload
code and other factors.
Impact Maps
Final Users Impacted – all the people that will use the system in a
direct or indirect way.
Users Impacted – all Business, Manager and IT affected by the
system.
Context Diagrams – informs about the boundary between the
systems, or part of a system and environment, showing entities that
interact with it.
Risks
Dependencies (internal and external) – list of In-house
dependencies or 3rd
parties.
Immature requirements – list of all requirements which do not
pass the Definition of Ready.
Technological – technological unknowns; you can create Spikes to
make this risk go down.
Other Documents
Definition of Done and Definition of Ready (Check the Chapter
2 for more details), Team Working Agreements, etc.
The Roadmap is generally adjusted during the planning and feedback is given to all the
participants. A Product map is created where everything is organised in different areas, such as
technical aspects, architecture, user interface, etc. This mapping is very important, as it will define
the boundaries of the project.
The format for this Workshop and First Sprint are similar to the standard Release Planning
Meeting and Sprints Meeting but the goal instead is to have a solid foundation for the whole
project so some practices can be different.

PREPARE THE COMING RELEASES
The objective of Release Planning is to define the contents of a release or a potential
shippable product increment. As we have seen before, it involves identifying the goals for the
release, prioritising and sizing User Stories, and establishing due dates.
Make sure you avoid:
 Going into too many details, as this is usually done during the Sprint Planning Meeting.
 Attending the meeting with an unprepared Product Backlog or without fully
 understanding the purpose of a Release Planning Meeting.
 Getting too many interruptions or doing other activities not related to the
initiative.
 Going into long technical discussions.
You do not need to understand the details of each User Story, just concentrate on their key
assumptions (read more about what a User Story is on Chapter 4, Agile Requirements).
Focus on understanding a sufficient level of information to forecast the achievable goals by
the release date.

My humble advice to make good decisions during planning is:
 Invest more time in the most important things only and go down to details just when
are closer to the development phase.
 Make decisions at the right time, when you have the best possible knowledge about the
project, client, product team and technology.
 Do not believe in a perfect plan, an initial and detailed written plan makes people
believe that "everything" will be in that way. Progressively refine the plan and adapt over
time.

TAKE AWAY
REMEMBER
 Keep the focus of the meeting at all times.
 Knowledge of how to estimate is needed.
 Product Owner should prepare the Backlog before attending the meeting
DEEPEN YOUR KNOWLEDGE
Product Backlog Refinement
Agile Release Planning
 Sprint Planning
Agile Iteration Planning
Value Vs. Complexity (prioritisation framework)
Difficulty vs. importance
BENEFITS
Sets the importance of identifying a Minimum Valuable Product.
Ensures that Stakeholders´ input is thoughtfully considered.
Make sure everyone is aligned and understands what the needs are.
Supports a learning environment.
Help everyone understand what the future product releases will provide and the overall product strategy.

Chapter 6.1
AGILE RELEASE PLANNING
V1.0

Contents
HOW TO PREPARE A RELEASE........................................................................................................................................................................... 206
REFINE THE PRODUCT BACKLOG .............................................................................................................................................208
COMPREHENSIVE PRODUCT BACKLOG REFINEMENT ..................................................................................................................210
TAKE AWAY.................................................................................................................................................................................................. 213
CHECKLIST 6.1.................................................................................................................................................................................................. 214
CHECKLIST 6.2.................................................................................................................................................................................................. 220
CHECKLIST 6.3.................................................................................................................................................................................................. 225

initial plans without changes. A release planning is
a special activity, which focuses on preparing all
the necessary elements for a coming Release.

HOW TO PREPARE a release

HOW TO PREPARE a release
I generally expect this from a Release Planning Meeting:
 Team Working Agreements and Definition of Ready are available and visible.
 I (Product Owner) clearly explain the Release Goal to the team and answer all their
questions.
 Scrum Master provides the team’s Velocity.
 I (Product Owner) introduce the most important User Stories to the developers.
 Developers ask enough questions about the stories to be able to confirm the existing
coarse estimates or provide new ones (this may require the Product Owner to split
some User Stories)
 Developers assess the technical risk for each story, classify it with any numeric scale
and run Spikes if information is not of sufficient detail (i.e. Spike).
 I (Product Owner) establish a Minimum Viable Product (sufficient features to
satisfy early adopters) and define user stories to be completed in the coming release.
 If the Velocity is available, everyone has an idea of how many Sprints are needed to
achieve the release.
 Brief retrospective of the session.
It is important to stay focused and not to start unnecessary conversations (a timebox can help to
avoid this). Remember that verbal consensus needs to be reached during the Release Planning
with everyone to check if there is common understanding of all variables and responsibilities to
deal with them.
Open the checklist “Organise a Release Planning” to see how to do this meeting.

PBR Product Backlog Refinement
The Goal of the meeting is achieved when all the User Stories for the first release have been
identified, sized and prioritised.
Techniques such as Story Mapping can be of a huge help at the time of organising Releases
and the desired features.
Open the Checklist “Using Story Mapping” to know this technique or “Organise a
Sprint Planning Meeting” to see how to do this meeting.
REFINE THE PRODUCT BACKLOG
Product Backlog Refinement is an on-going activity throughout a Scrum project and the team
should allocate around 10% of the Sprint time for this. These are the activities to do in order to
maintain a proper Backlog and run a refinement session:
 Remove or lower the priority for items that no longer seem important.
 Add or promote items that arise or become more important.
 Split items into smaller items.
 Merge items into larger items
 Estimate items.
 Check maturity of items and ask why.

The idea of a Product Backlog Refinement activity is to prepare for the upcoming Sprints.
The refinement activity gives special attention to preparing items that are coming closer to
implementation.
For simplicity, this activity can be split in 2 parts, the first one focuses on adding new items,
analysing or splitting Epics and adding new Acceptance Criteria to them. The second part of
the meeting focuses on taking the “closer to development” items and going down into a little
bit more detail. The objective of this phase is to make sure that the User Stories closer to be
implemented meet the Definition of Ready.
Read more in the Requirements and estimation chapters.

I run a more comprehensive refinement session using many techniques when:
 Running a very complex project.
 A high number of stakeholders are involved.
 More than one project or SLA (Service Level Agreement) needs to be refined.
COMPREHENSIVE PRODUCT BACKLOG REFINEMENT
Product Backlog Refinement can be executed in a more comprehensive way if deeper
understanding of dependencies between features is necessary and if the complexity is high and a
deeper look into feature details is required.
This format of Product Backlog Refinement consists of the following phases:
1. Data collection.
Key information is for the discussion including:
- All projects Product Backlogs (in the case of more than one).
- Current Sprint progress charts and Sprint Product Backlog.
- Macro calendar with milestones.
- A list with requirements that might not be finished in the current Sprint.
- Changes to be incorporated/dropped.
- Any other important information.

2. Key requirements identification and categorisation.
Key requirements are identified, categorised and explained in order to get a good
understanding before they are split up and detailed.
3. Estimation.
An overall quick relative estimation based on T-shirt sizes is done in this stage. If a
request cannot be estimated, the Team usually do it in the coming Sprint Planning meeting
or create a specific analysis task for the next cycle. Dependencies and risks are also
analysed at this stage.
Please refer the Estimation chapter of Agile White Book for further information.
4. Prioritisation and planning.
Elements are prioritised by analysing different aspects (ROI, IT recommendations, Capacity,
etc.) and a concrete number of updated documents are generated.
Please refer the Requirements chapter of Agile White Book for further information.
A Pluses and Delta retrospective (or another option if you wish) is finally done in order to
improve the process (check Retrospective Chapter for more information about it).
Open the checklist “Comprehensive Product Backlog Refinement” to understand the
way to do a full refinement.

THE EXPECTED outcome
An Agile planning meeting has many outcomes; the following is the minimum number of items to
be expected:
 Forecast & updated Product Backlog.
 Needed documents/concerns/dependencies/risks.
 Metrics to be monitored (and assumptions to consider).

TAKE AWAY
REMEMBER
 Knowledge of how to estimate is needed.
 Product Owner should prepare the Backlog before attending the meeting
 Sprint Planning
Value Vs. Complexity (prioritization framework)
Difficulty vs. importance
BENEFITS
Helps identify a Minimum Valuable Product.
Ensures that Stakeholders´ input is thoughtfully considered.
Make sure everyone is aligned and understands what the needs are.
Supports a learning environment.
Help everyone understand what the future product releases will provide and the overall product strategy.

User Story Mapping
Checklist 6.1
Version 1.0
DATE: __________
Attendants
Context
User-story mapping technique helps to run the high-level product planning and release
planning. It helps dependencies and identifies the right order. User-story mapping can be
used for both purposes: defining releases of the product or splitting release scope in
several sprints in the best way.

For more details – please refer chapter 6 of Agile White Book – Agile Release Planning.
User Story Mapping is a technique, which provides a more structured approach to Release
Planning. User Story mapping consists of ordering user stories along two independent
dimensions. The "map" arranges user activities along the horizontal axis in rough order of
priority (and time). Down the vertical axis, it represents increasing sophistication of the
implementation.
The main idea is to have an overall vision and easily know the required features for a product
by keeping an eye on maximising the Business Value.
The technique can be applied for the high-level planning of releases for projects with extended
scope. In this case, elements are epics rather than user-stories.
-
+

Task Comments
1. Before the meeting

The room has been booked and a time-
box has been allocated.

Product Owner and relevant people have
been invited and a detail of the activities
has been sent.
 Pens and sticky notes are available.

A wall or table are available.
2. Gather information

I welcomed the team, reviewed purpose
and agenda, organizing tools, etc.
 I gave post-its to each participant

People in the room were placed in groups
of 3 to 5 people.

All teams checked that the post-its
were not duplicated.

(Optional) All the requisites were
converted into User Stories

All sticky notes were placed on a timeline
Extracted from Jeff Patton – Story Mapping

Task Comments
3. Break down tasks and
reorder

Teams took all the Requirement/User
Stories and broke them down into smaller
tasks.

Small requirements were placed under
the related User Story (Tasks that the
user can perform in the upper story).

All the tasks to be performed at the same
time were arranged vertically.

All the alternative tasks and
exceptions were detected and
added/changed the order.

All dependencies were detected and
cards arranged consecutively.
The team checks, that each column
contained all required User Stories.

Task Comments
 4. Find out the necessity
and prioritise

The concept of “necessity” was added on
the vertical axis to represent the value it
brings to the user. More necessity at the
top, less necessity to the bottom.
 All cards were moved up and down
according to necessity.

Everyone checked that the first line or
Roadmap contained the application´s
backbone (essential items). The walking
skeleton is the software that we build
with the least number of tasks we
needed for the user to have a first
experience.

First release and subsequent ones
were highlighted and incorporated into
the Roadmap.
They final result should look like this:

Checklist 6.2
Version 1.0
DATE: __________
Attendants
Context
Product Backlog Refinement is an on-going activity throughout a Scrum project. Which the
team should allocate around 10% of the Sprint time for. These are the activities to do in order
to maintain a proper Backlog and run a refinement session: remove or lower the priority for
items that no longer seem important, add or promote items that arise or become more
important, split items into smaller items, merge items into larger items, estimate items, check
maturity of items and ask why. The idea of a Product Backlog Refinement activity is to
prepare for the upcoming Sprints. The refinement activity gives special attention to preparing
items that are coming closer to implementation.

Task Comments

The room has been booked and a time-box of
up to 2 hours has been allocated.

Product Owner, Team and relevant
people have been invited and a detail of the
activities has been sent
 Pens and sticky notes are available.
2. Input collected

The following information was collected and
placed in a visible space:
- All projects Product Backlogs (in the
case of more than one).
- Current Sprint progress charts and
Sprint Product Backlog.
- Macro calendar with milestones.
- A list with requirements that might not
be finished in the current Sprint.
- Changes to be incorporated/dropped
and any other relevant information.
3.Requirements Identified
and Categorised

We reviewed purpose and agenda, organizing
tools, etc.
 I reminded the team of the larger picture.
 A High level overview of new requests was
carried out.


More important, larger requirements (Epics)
were split up.

A detailed requirements gathering for
next Sprints was carried out, taking into
account the Definition of Ready (DoR). If
some details were not answered, I noted
them down to be brought in the next Sprint
Planning.

The Acceptance Criteria for those
requirements were created and people fully
agreed with it.
4. Elements estimated

Overall quick relative estimation based
on T-shirt sizes was carried out (the team
initially decided an M size type of work
where new requirements should be
compared).

If some element was not estimated for
some reason, they were noted down and
the task included to be done in the coming
Sprint.

5. Elements prioritised and
planned.

Elements were prioritised by analysing
different aspects, such as:
- ROI (Return of Investment) using a
quadrant with the following axis:
Business Value – Based in
defined prioritization criteria and
supporting techniques like Kano
Model. It is scored in relative Business
Value points.
Cost – Derived from previous
estimation step.
- IT recommendations.
- Dependences and risks.
- Team capacity for the next Sprint,
taking into account trainings,
vacations, etc.

I used Kano Model or any other prioritisation
technique to help people see priorities clear.
 We agreed upon Backlog priorities.

Task Comments
Outputs

The following documents were updated:
Idea of the upcoming Sprint Backlog with
clear requirements and Acceptance Criteria.
Product(s) backlogs, Macro Calendar with
Milestones.
Retrospectives
 A retrospective is carried out in order to
improve the process.

Release Planning Meeting
Checklist 6.3
Version 1.0
DATE: __________
Attendants
Context
The objective of Release Planning is to define the contents of a release or a potential
shippable product increment. It involves identifying the goals for the release,
prioritising and sizing User Stories, and establishing due dates.
For more details – please refer chapter 6 of Agile White Book – Agile Release Planning.

Task Comments

The room has been booked and a time-box
has been allocated.

been invited and a detail of the activities has
been sent
 Make pens and sticky notes available.
2. During the meeting

I welcomed the team, reviewed purpose and
agenda, organizing tools, etc.
 I reminded the team of the larger picture.
 I discussed any new information that may
impact the plan.

Task Comments
Inspected current status as it relates to the
roadmap themes and collaboratively we
decided on adjustments to name and theme
to achieve a specific, current business goal
for the release

Velocity in previous releases and iterations,
or your estimated velocity is presented.

We review key milestones and special
events followed by collaborative decision on
time-boxes for the release and iterations
within the release.

Checked in on any known issues and
concerns and recorded them as appropriate.

We reviewed the Definition of Done and
Definition of Ready and we made any
appropriate updates based on technology,
skills, or other changes.

The Product Owner presented proposed
backlog items to be considered for scheduling
into this release.

We agreed upon sizing values to be used in
the release planning if velocity is unknown or
the value from Sprint 0 is used.

The Product Owner and experts answer
clarifying questions and elaborate
Acceptance Criteria for User Stories.

The Team determined the size of items under
consideration for the release and splits items
too large for Sprints in the release.
Task Comments

Delivery team and Product Owner moved
items to iterations based on size and
velocity; Scrum Master facilitated.


We checked in again on any new issues and
concerns based on the previous work and
recorded as appropriate.

We checked in on any dependencies or
assumptions determined during planning and
recorded.

Scrum Master asked for the team´s
forecast. Team and Product Owner signalled
if this is the best plan they can make.
3. After the meeting

All items should have either been resolved
or turned into action items. A Release Plan
should have been created

Chapter 6.2
SPRINT PLANNING
V1.0

Contents
HOW SPRINT PLANNING WORKS......................................................................................................................................................................... 232
OVERVIEW .........................................................................................................................................................................233
SPRINT PLANNING: HOW TO .................................................................................................................................................234
UNDERSTANDING TEAM’S CAPACITY .......................................................................................................................................237
COMMON ANTI-PATTERNS .................................................................................................................................................238
TAKE AWAY.................................................................................................................................................................................................. 240
CHECKLIST 6.4.................................................................................................................................................................................................. 241

Sprint Planning
initial plans without changes. A sprint planning is a
special activity, which focuses on loading work for
the Team for the coming iteration.

HOW SPRINT planning works

OVERVIEW
The first activity that happens when a new Sprint begins is the Sprint Planning. It’s the time when
the Development Team and the Product Owner sit together to agree on a sprint goal and they
determine which items of the product backlog should be delivered in order to reach the shared and
common goal.
To increase the confidence of what can be delivered, the team creates a plan for how to develop
and deliver the selected product backlog items. The selected product backlog items that are
planned for the sprint form the Sprint Backlog. The Sprint Backlog and the Sprint Goal are
considered the main two outcomes of the Sprint Planning meeting!
Participants in Sprint planning meeting is the whole scrum team which means the Product Owner,
the Development Team and the Scrum Master. If for some reason you think that you need people
with specific knowledge and skill that could help you make better decisions feel free to invite them
as well.
The meeting is generally time-boxed from 4 hours for a
two-week sprint, to a maximum of 8 hours for one
month sprint. You might wonder how to organise such a
big activity, right? A common practice used is to split
the sprint planning meeting into two parts with different
objectives! You can find more details below!
The end users know better than anyone else
how they behave and what their problems are.
Have you ever thought to bring representative
end users in your Sprint Planning? If not, think
about it!

SPRINT PLANNING: HOW TO
As mentioned a common practice is to split the sprint planning meeting into two parts with different
objectives.
The first part is focused on WHAT product backlog items would be good to complete in the sprint
and will return the most value for your product and your customers.
The second part is focused on HOW to complete the selected product backlog items into valuable
product increment
So, let’s take a look at the activities that need to be followed for an effective and efficient sprint
planning meeting.
 Preparations: make sure that the following set of inputs is available in the sprint planning.
It will help and guide the team to make better decisions related to what could be completed
by the end of the sprint.
o A prioritised, appropriately detailed, estimated product backlog where the top items
are marked as “ready” (based on Definition of Ready) to be undertaken by the
development team. Take a look at the chapter of Product Backlog refinement
meetings, where most of these activities should happen there!
o The average velocity or previous performance measurements of the team based on
historical and gathered data. This data could help the development team to make
quick decisions of how much work may be completed within the sprint.
o Team capabilities considering public holidays, leaves, availability etc. that might affect
the skills required to complete the work for the sprint (refer to understanding team’s
capacity subchapter). You need that information in order to make a realistic plan and
find ways to mitigate any raised risk.
o Any known constraint or dependencies related to product backlog items or coming
from business needs to be considered.
o An indication from the Product Owner for the sprint goal that needs to be achieved
and will serve as input for further discussions and collaboration with the Development
Team aiming to reach a common and shared sprint goal!

 Sprint Planning Part 1 activities (figure out What to do)
o Product Owner presents the sprint goal for the coming sprint and describes the
desired product backlog items that if completed, the goal will be reached.
o Product Owner and the Development Team collaborate and discuss the suggested
product backlog items that could be taken in coming sprint. Even though the items
should be marked as “ready” (outcome of Product Backlog refinement) it’s an
opportunity to highlight possible risks, review details related to dependencies
acceptance criteria, documentation, models, UX artifacts etc. It’s even possible to
change the prioritisation as/if needed.
o The Development Team based on past performance data, for example their average
velocity, collaborate with Product Owner on the sprint goal. Make sure as
development team to consider your capabilities and highlight any foreseen risks or
known issues!
o First part outcome should be a shared Sprint goal.
 Sprint Planning Part 2 activities (decide HOW to do it)
o The Development Team, the Product Owner (if needed) and any other person that
could share knowledge and experience discuss around possible solutions on the
selected Product Backlog items. Visual thinking and sharing knowledge is vital. Make
technical designs use flip charts and discuss what the functionality will look like is
highly recommended.

o The Development Team creates a more detailed plan on how to develop the selected
Product backlog items to gain more confidence of what could be completed within the
coming sprint. To do that, it is common practice to split the backlog items into smaller
tasks that won’t take more than a day to complete them (try to keep that rule!).
Advice : the Definition of Done will serve you as a guide to identify possible tasks!
Keep in mind that task splitting is an ongoing activity that happens throughout the
sprint duration, however having a good view from the sprint planning is quite helpful.
Keeping some spare time to handle unforeseen events that may happen during the
sprint is good practice! For further reading, refer to Understanding capacity
subchapter below.
o Develop technical models that may be useful to share approaches. It’s a collaborative
activity and make sure to use flip charts and whiteboards to increase understanding
and reach consensus easier. Make photos of them; keep them in your knowledge
repositories for future reference.
o Considering the team’s capacity and the identified tasks, the Development Team is
much more confident to forecast if they can finish (or not) selected backlog items as
outcome of the 1st part of the meeting. If there is more capacity available, renegotiate
with the Product Owner what else could be selected. The final forecast is shared with
the Product Owner.
o The second part outcome should be a Sprint Backlog that contains the forecasted
backlog items and their related tasks. Make sure that your sprint backlog is prioritised
so that that the risk of not reaching the sprint goal is minimized. In addition try upfront
to resolve or find workarounds for any known dependencies, issues and risks that will
affect you reaching the sprint goal.

UNDERSTANDING TEAM’S CAPACITY
Defining your team’s capacity is a really important step since it will strongly affect the sprint
forecast on what as a team you can deliver
When it comes to calculating your team’s capacity make sure to
1. Reserve capacity for the sprint ceremonies (for a two week sprint, almost one full day collectively
for sprint planning, reviews and retrospective is needed).
2. Reserve about 10% of sprint capacity to support the Product Owner in Product Backlog
refinement activities.
3. Reserve some time (based on your previous experience and data) on activities for supporting
issues of current product, maintaining other products or other activities not related with the
current sprint.
4. Reserve scheduled time that team members will be off work or engaged with other activities.
5. Reserve some time (buffer) to handle unforeseen events that may happen during the sprint.
Some items might be larger than estimated or more complex. Again, make use of previous
experience and data.
Now that you know how much time you should reserve, you hopefully have a better view of what
available time you can dedicate to the current sprint!

COMMON ANTI-PATTERNS
Anti-pattern #1
Scrum Master or Product Owner allocating work to team members during the planning
Team members should decide themselves on which items they should work on based on priorities
set and starting from the highest items! The Development Team should self-organise around their
sprint backlog. This could be quite easy if team members’ skills are fairly balanced. If this is not
possible, and you see that you have bottlenecks that prevent the flow of work during the sprint,
reflect and rethink! What should you change to enable work to flow? What improvements do you
need to consider to make your team a truly cross-functional and self-organised team? What
practices would you consider?
Anti-pattern #2
Product Backlog items discussed for a first time during sprint planning
Sprint Planning meeting requires that the suggested product backlog items are already discussed
during Product Backlog refinement and are aligned with the Definition of Ready. During Sprint
Planning the suggested items will be reviewed in order to resolve any possible misunderstandings.
Seeing for the first time the backlog items during Sprint Planning will result in a low value meeting
and unrealistic plans and commitments. Bring this observation to your next retrospective and find
ways to improve! Reflecting on your meetings’ effectiveness, roles and responsibilities could be a
good start!
Anti-pattern #3
Task splitting performed without having the whole team present
Task splitting is an activity done by the whole team, which means that all team members should be
present and share openly their opinions or suggestions. How could you differently maximise
synergies from prior knowledge and experience? How could you reach consensus on how to work
on that Sprint?
Open the checklist do a “Sprint Planning” to see how to do this meeting

THE EXPECTED outcome
These are the expected outcomes from a Sprint Planning meeting:
 Prioritised Sprint Backlog with common understanding and forecast of Product Backlog
Items to be delivered in the Sprint.

TAKE AWAY
REMEMBER
 Sprint Planning is split in two parts. 1st part is about WHAT to do and 2nd part about HOW to do it
 The outcome of sprint planning should be a sprint backlog aligned with a shared goal
 Sprint Planning
BENEFITS
 Supports a learning environment.
 Helps everyone understand what will be obtained after the Sprint.

Sprint Planning Meeting
Checklist 6.4
Version 1.0
DATE: __________
Attendants
Context
Sprint planning - main objective is to transform product backlog items into tasks and
actions, which can be completed by development team during the sprint. The meeting
usually contains of two parts with different goals: (1) Product Owner explains priorities to
the team and clarify outstanding questions, (2) Development Team split backlog-items
into tasks and action items.
For more details – please refer chapter 6 of Agile White Book – Sprint Planning.

Task Comments
□
The room has been booked and a time-box
has been allocated.
□
been invited and a detail of the activities has
been sent
□
Pens and sticky notes are available.

Task Comments
2. First part (WHAT)
□
I welcomed the team, reviewed purpose and
agenda, organizing tools, etc.
□
I set up the context of the meeting
□
I discussed any new information that may
impact the plan.
Inspected current status and the Product
Owner informed the Sprint Goal to the
Team.
□
Velocity in previous releases and iterations,
or your estimated velocity was presented.
□
We reviewed the Sprint Goal and made
sure everyone understood it.
□
Checked in on any known issues and
concerns and recorded as appropriate.

Task Comments
□
We reviewed the Definition of Done and Definition
of Ready and we made any appropriate updates based
on technology, skills, or changes
□
The Product Owner presented proposed backlog items
to be considered for scheduling into this Sprint. A high
% of the items should agree with the goal.
□
We agreed upon sizing values to be used in the
release planning if velocity is unknown or the value from
Sprint 0 is used.
□
The Product Owner answered clarifying questions
about User Stories.
3. Second part (HOW)
□
Team determined the size of items under
consideration for the Sprint and split items into tasks.
They also had technical discussions.
□
They had checked in on any dependencies or
assumptions determined during Sprint and found an
answer.
□
Scrum Master asked for the team´s forecast based
on previous velocity. Team and Product Owner
signaled if this is the best plan they can make and go
ahead if positive.
□
We reviewed and updated communication and
logistics plan for this Sprint.

Task Comments
4. After the meeting
□
All items should have either been resolved
or turned into action items. A Sprint
Backlog should have been created.

AWB - 06 - Agile Planning, Release and Sprint

More Related Content

What's hot

Viewers also liked

Similar to AWB - 06 - Agile Planning, Release and Sprint

Recently uploaded

AWB - 06 - Agile Planning, Release and Sprint