Sprint Planning Meeting

The kick-off of each Sprint is the Sprint Planning Meeting. It is used to define the workload of the Scrum team for the upcoming Sprint. How the Sprint Planning Meeting has to be prepared by the Product Owner, who takes part in it, how the process is and what the team should pay attention to, you can read in this article.

Sprint Planning: Goals & Participants of the Meeting

A Sprint Planning meeting has two goals. After a successful Sprint Planning:

• the product owner and the development team agree on the sprint goal (outcome)
• and have formed the Sprint Backlog. The Sprint Backlog contains all Product Backlog Items that must be implemented in the Sprint to achieve the Sprint Goal (Output).

In some places, Outcome and Output are also summarized as MVP, the Minimum Viable Product.

Who invites to the Sprint Planning?

The Product Owner invites the development team and the Scrum Master to the Scrum Planning Session. If there are also Stakeholders who want to see what the Sprint Goal is and which Backlog Items are being worked on, the Product Owner invites them as well.

Preparation of the Scrum Planning Meeting

In order for the product owner and the development team to achieve the two goals of the planning meeting, some prerequisites must be met. The following preparatory steps are therefore essential before Sprint Planning in Scrum. If you work as a PO yourself or are currently preparing for the Product Owner role, you can use this checklist or use the items listed below.

• The Product Owner has defined a Sprint Goal (Outcome) and selected the associated Product Backlog Items (PBIs).
• The selected PBIs were formulated in sufficient detail - preferably in collaboration with the development team, e.g. as part of a Product Backlog Refinement.
• The selected PBIs have been put in an order according to which the development team will work on them. This takes into account technical dependencies.
• The team has a Definition of Done (DoD). This provides a common understanding of "when something is done".
• The capacity of the team for the next Sprint has been determined, e.g., taking into account the average velocity of the last Sprints and any planned vacations of individual team members.

The Sprint Planning process

Once the Sprint Planning is prepared as described, you can get down to the actual process with your Scrum Team. The meeting proceeds according to the following Sprint Planning Agenda:

• The Product Owner presents the sprint goal and the associated PBIs and answers comprehension questions from the team. The Sprint Goal should be documented on the Sprint Backlog in a way that is easy to read for all team members.
• If the PBIs have not been estimated yet, you should do the estimation now. If the estimation has already taken place, your team can now refine the estimation after the detailed implementation discussion.
• The team makes a prediction to the product owner and stakeholders about what PBIs it will deliver at the end of the sprint according to the collaboratively written DoD. In this way, the Sprint Backlog is formed, in which it should be documented which PBIs the development team has committed to and which it will optionally work on additionally.

Of course, in Scrum there is also a timebox for Sprint Planning: the length of a Sprint Planning should not be longer than one day (timebox: 8 hours).

Differentiation in Sprint Planning 1 and 2

Our practical tip: Scrum teams often distinguish between Sprint Planning 1 and 2:

• Sprint Planning 1 deals with the question: what do we want to tackle in the upcoming sprint?
• Sprint Planning 2 deals with the question: How do we want to tackle it?

By the way, the timebox of both plannings is not divided into 4 hours each - instead, Planning 1 is automatically quite short after a good refinement, while the larger part of the timebox is needed for Planning 2.

Although this is not mandatory, some development teams break down the Product Backlog items into smaller work packages (tasks) in Scrum Sprint Planning 2. This second part of Sprint Planning often takes place without the Product Owner.

What else should a team consider when planning a sprint?

A development team will never be able to work exclusively on the selected sprint backlog items in a sprint, because in every agile working environment there are disruptions, small emergencies and urgent support requests in between.

For this reason, it is worthwhile for your team to plan some kind of buffer into the sprints, which allows for the following activities, for example:

• Fixing operational issues, such as when a server goes down.
• Fixing critical bugs
• First- or second-level tech support

Such buffers ensure that Scrum Sprint Planning produces a backlog that the team can actually accomplish without getting frustrated by glitches. In addition, our studies show that teams with a buffer become more performant over time. This is due in part to the fact that these teams are more likely to achieve their sprint goals, and thus have more frequent feelings of success.

The results of sprint planning

If you and your team can mark the following items as done, you know your sprint planning was successful and you did everything right:

• The Scrum team has developed a shared understanding of what needs to be accomplished in the upcoming Sprint (Sprint Goal).
• Through the development team's discussion with each other, you have a common understanding of how each PBI should be implemented.
• You have created a cleanly mapped Sprint Backlog that contains the PBIs in the order of the Product Backlog, possibly even after a Task Breakdown including associated activities.

The biggest mistake at the Sprint Planning Meeting

Some development teams get bogged down in creating the perfect Sprint Backlog by trying to identify and meticulously estimate every task, no matter how small. Usually this happens when management has not yet fully penetrated the agile way of working and demands such "exact" estimates.

Since too much time is lost in the Sprint Planning meeting if the estimate is overly accurate, the Scrum Master should make sure that the actual goal of the planning is not lost: namely, to select the right PBIs for the next Sprint and to talk about them just enough so that the team feels ready to work on the items.

Summary of the Sprint Planning Meeting

A successful Sprint Planning Meeting stands or falls on good preparation such as the Product Backlog Refinement. The Sprint Planning Meeting in turn provides the prerequisite that everyone in the team knows what is to be implemented in the next Sprint and how. If the Sprint is to succeed and the development team is to work on the PBIs successfully and without frustration, the Planning Meeting is absolutely indispensable in Scrum.

Become a Certified Scrum Master

=> Take a look at our Scrum Master Training offering!

Dynamic Reteaming

=> Coaching Teams through change

Scaling Agile

=> Find out how you can scale your agile approaches.