What Is The Sprint Planning And How To Have An Effective Sprint Planning Scrum Meeting

HOW TO HAVE AN EFFECTIVE SPRINT PLANNING SCRUM MEETING

Over the last weeks I have collected a lot of feedback from my readers on what they´d like to read in next couple of weeks.  One of the topics was: how to run an effective sprint planning. 

For some of you this might be a basic topic, if this is the case, feel free to skip it 😉

Effective Sprint Planning Scrum Meeting

Any work that is to be performed in the Sprint is planned at the Sprint Planning. The plan brings together the entire Scrum Team and is created by collaborative work. Sprint planning is time-boxed to a maximum of eight hours for a month long Sprint

In Scrum, teams plan by picking up Stories from the product backlog. Afterward, they commit to a set of them for an execution in the upcoming sprint.

Like mentioned, each team plans the upcoming sprint in a time-boxed meeting (like in the most of Scrum Artifacts). It is a ScrumMaster´s responsibility to make sure that the event takes place and the attendants understand the reason for the event. The ScrumMaster will teach the team to stay within the time box.

By the end of the meeting (outcome) the team will have:

• The sprint backlog, consisting of the stories the team committed for the next sprint. In an optimal scenario, these stories will have acceptance criteria.
• The Sprint Goals
• An agreement by the team to do what is possible to achieve the goals. The word commitment was removed in the last Scrum Guide. In my personal view, this was a great move.

The objective of the Sprint Planning Meeting is to organize the work and define a realistic scope for the next sprint.

Teams agree on a number of stories they can pull from the backlog. Of course, they must take the availability of team members into consideration. After agreeing on what they will take from the backlog, they define the Sprint Goal(s) together with the Product Owner.

Sometimes it is necessary to do some adjustments to achieve a larger purpose.

The team capacity is based on story´s complexity, size, and dependencies on other stories and other teams. We all try to get teams to have an end to end responsibility. Unfortunately, the reality is a bit different, and it is quite common to have several dependencies towards other teams.

Pre-Requirements for an effective Sprint Planning Scrum Meeting

Before the meeting, the Product owner should prepare some draft of the upcoming Sprint Goals. Usually, part of this task is done in the Grooming session.

Another important part is to be aligned with other Product Owners in case the team has dependencies on others. It is very frustrating for team members when Product Owners come to a meeting asking for work that cannot be done because of external dependencies.

It is not only the Product Owner that must do his homework. Team members must be prepared too. It’s common to have some research tasks (spikes) that must be done before the Sprint Planning. These tasks usually answer questions related to architecture or future implementations.

Guidelines for an effective Sprint Planning Scrum Meeting

Attendees

Attendees of the Daily Scrum Meeting include:

• The Product Owner
• The Scrum Master,  this person acts as facilitator
• All other team members

Agenda

An example of a Daily Scrum Meeting agenda:

• The team determines the velocity available for the Sprint
• If you use #NoEstimates, the team determines the number of stories they achieved in past (per sprint) and how many stories they could achieve based on their capacity
• The Product Owner presents the Sprint goals; the team discusses and agrees on the goals
• Personally, I find the previous topic a bit top-down approach 🙂 I prefer asking the team for the Goal, of course with the right guidance from the Product Owner
• The team discusses each story. For each story, the team:
• Sizes each story in story points and splits them if necessary
• If you use #NoEstimates break the story until the team is comfortable to deliver the story up to two days
• Elaborates acceptance criteria through conversation
• Based on size and value/time/risk, the PO may re-rank stories
• Some teams break the stories into tasks, estimated in hours
• Planning stops once the team runs out of points

• The team and PO negotiate and finalize the selected stories
• Everyone commits to the Sprint goals

Meeting

Usually, the Product Owner starts the meeting by reviewing the proposed Sprint goals. During the meeting, the team discusses the implementation and different options. In this meeting, the Product Owner is the responsible to define the what; the team defines how and how much.

During the meeting, the team elaborates on the acceptance criteria (together with the Product Owner) and estimates the effort to complete each story. 

Based on their velocity, the team then selects the candidate stories. Many teams break each story down into tasks and estimate them in hours to confirm that they have the capacity and skills to complete them.

As soon the team capacity has been established, the team turns their attention to understanding and agreeing on one or more sprint goals.

The product owner and team agree on the final list of stories that will be achieved. The sprint goals are then revisited and restated. The entire team commits to the sprint goals, and the scope of the work remains fixed for the duration of the sprint.

It is very important to mention that most of the times teams are over confident. They tend to pick more stories than what they were able to achieve in previous sprints. As a Scrum Master challenge them. Usually, they are not going to make it. This can lead to frustration and disappointment.

Hope you liked the post today. Some of you know that I have been studying for the SAFe consultant certification during last weeks. I found a very nice page about the Sprint Planning. I decided to re-write it to make it more look like Scrum 🙂 The original page can be found here.

Working with Me Or Evolution4all

I have developed the “Organisational Mastery” product. The aim of this product is to create a coalition that drives change and internal innovation alongside shared knowledge throughout the organisation. It’s extremely suitable for companies that want drastically improve the alignment between executive leadership and delivery teams.

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.