What we start doing first thing in Sprint Planning?

An interesting debate into which I get pulled in most of the time when interacting with Scrum Teams:

What we first start doing in Sprint Planning? Is it crafting the Sprint Goal or come up with the Sprint Backlog?

Definitely, this cant top the list of most heated and interesting debates we humans ever had.

Everything looks small and trivial in front of 'What came first? Is that a Chicken or an egg?'

The topic for this blog post is not going to run into such endless discussions when it comes to helping clarify that question with Scrum Guide for reference.

Let us explore both the options before narrowing down on what should actually be the sequence of activities in the Sprint Planning.

Possibility One: Crafting the Sprint Goal first followed by the Sprint Backlog

The first topic explored in the Sprint Planning is 'What can be done in this Sprint?'. The answer to that question is obtained through crafting the Sprint Goal.

To convince the readers on why it is the Sprint Goal first and not the Sprint Backlog, let us refer to the Scrum Guide for what it has to say about Sprint Goal.

"The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment."

This means the Product Owner should be able to kick start the Sprint Planning with sufficient preparation done prior to negotiating an Increment of value. And this can also mean having some reasonable idea about how the Sprint Goal might be. Definitely not finalized and at the same time, not anymore an assumption or pre-requisite to what the Goal may be.

Whenever I pick up this explanation, I don't get complete buy-in from the listener unless referring to the following statements from the Scrum Guide part of the Sprint Review section,

"The Sprint Review includes the following elements [...]

• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next"

The Development Team start to pick up refined and highly ordered Product Backlog Items to forecast what they can deliver the Sprint based on the inputs to the Sprint Planning. Further, the Product Owner facilitates the discussion by bringing up the Sprint Goal set to achieve. At this juncture, this is in a draft state.

The entire Scrum Team now collaborate on the understanding further crafting the Sprint Goal and select the Product Backlog Items and a plan for delivering them. The latter is called the Sprint Backlog.

"Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a "Done" product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog." - The Scrum Guide

Possibility Two: Coming up with the Sprint Backlog followed by Crafting the Sprint Goal

We have to continue further with this possibility only on grounds where we read the Scrum Guide and have some misunderstanding.

"Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in Sprint Planning." - The Scrum Guide

Misunderstanding 1 - Product Backlog Items deemed 'Ready' for selection in Sprint Planning is the 'Sprint Backlog'. This way of building the Sprint Backlog creates an impression to freeze the Sprint Backlog from emerging further before the Sprint Planning starts. Also, this approach brings down the value behind collaboration-driven planning after the prior Sprint has completed.

Misunderstanding 2 - Completing the entire Sprint Backlog is what the Sprint Goal should be. This diffuses the purpose of crafting the Sprint Goal which helps the Development Team in delivering one coherent function.

"The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal." - The Scrum Guide

An important thing to Remember: The Sprint Backlog never gets created completely in the Sprint Planning. The Sprint Backlog serves the purpose of meeting the Sprint Goal, and its ability to do so must be improved at every opportunity during the Sprint.

Verdict Time!

The Sprint Goal remains to be an objective that will be met within the Sprint with the help of implementing the Product Backlog.

It is the Sprint Goal that gives guidance to the Development Team on why it is building the increment and hence Sprint Goal gets crafted first followed by starting to create the Sprint Backlog in the Sprint Planning.

Share your views and feedback in the comments section.