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 THE EXPECTED OUTCOME ................................................................................................................................................................................ 239 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.

https://less.works/less/framework/product-backlog-refinement.html

https://www.versionone.com/agile-101/agile-management-practices/agile-development-release-planning/

https://less.works/less/framework/sprint-planning-one.html

http://www.versionone.com/Agile101/Agile-Development-Iteration-Planning/

http://www.product-arts.com/articlelink/1049-value-vs-complexity-a-prioritization-framework

http://www.allaboutagile.com/how-to-prioritise-quickly-and-intuitively/


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 THE EXPECTED OUTCOME ................................................................................................................................................................................ 212 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.


Help everyone understand what the future product releases will provide and the overall product strategy.

https://less.works/less/framework/product-backlog-refinement.html

https://www.versionone.com/agile-101/agile-management-practices/agile-development-release-planning/



http://www.product-arts.com/articlelink/1049-value-vs-complexity-a-prioritization-framework

http://www.allaboutagile.com/how-to-prioritise-quickly-and-intuitively/


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). Extracted from Jeff Patton – Story Mapping

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. Extracted from Jeff Patton – Story Mapping

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


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.

Product Owner and relevant people have 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 THE EXPECTED OUTCOME ................................................................................................................................................................................ 239 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


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.

□

Product Owner and relevant people have

been invited and a detail of the activities has

been sent

□



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

Leadership & Management