Starting with Scrum: 4 - Sprint Planning

Erik de Bos
Erik de Bos
Scrum Master & Agile Coach
Posted on
Jul 8, 2022
Updated on
Jul 18, 2022
Table of Content

This is the fourth article in the 'Starting with Scrum' series. In the first article, we discussed how to get started with Scrum by determining what the Product Goal is. In the second article, we talked about how to translate the Product Goal into a backlog. In the third, we looked at Product Backlog Refinement.

Want to read the full Series? See here for the link to: Article 1, Article 2, Article 3

In this article, we pick up where we left off and get started with the first Sprint!

What is Sprint Planning?

If you look closely at the 5 Scrum events you will notice that Sprint Planning is actually the very first event that takes place. This is the moment of truth, when all the preparations come together as the team gets ready to start their first Sprint.

The Sprint Planning as the starting event of the Sprint. Sprint Planning sets everything else up. All the other events evaluate or adapt the result of the Sprint Planning.

Agile Scrum Events
The Sprint Planning as the starting event of the Sprint. Sprint Planning sets everything else up. All the other events evaluate or adapt the result of the Sprint Planning.

According to the Scrum Guide, Sprint Planning covers three topics:

  • Why is this Sprint valuable?
  • What can be Done this Sprint?
  • How will the chosen work get done?

Why is this Sprint valuable?

Having developed the backlog together in the previous articles, the team is yearning to get started. Perfectly aware of the Product Goal and having worked out the first priorities into a Product Backlog, the team – and especially the Product Owner – come to the Sprint Planning with a clear idea of the first step that needs to be taken. Now is the time to express that first step as a Sprint Goal. This is important because just like with the Product Goal, it gives the team a clear vision to focus on, this time at the level of the Sprint.

We also explain why the Sprint is valuable. We talk about value because that is the currency of our work. The Scrum Guide tells us:

“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” Scrum Guide

The complexity that Scrum is designed to address requires a measure that is tied closely to the outcome we seek, and that is value. It’s a bit too complicated to discuss here in further detail, but check out this article if you want to know more.

If there is disagreement about what the Sprint Goal should be, I like to organize a quick 1–2–4-all to collect the various ideas for the Sprint Goal. A clear overview of the thoughts of the whole team will often lead to a creative synergy that makes it easy to find a single powerful Sprint Goal. At the same time, giving everyone in the team the opportunity to contribute leads to ownership of the goal and greater motivation.

Whatever the case, I’ve found defining the Sprint Goal away from the backlog works best. It helps keep the focus strictly on the Product Goal, and helps to make the Sprint Goal a faithful stepping stone towards it.

I have found that the mere presence of the backlog can have a strong impact on the team. This is very much human nature, a result of cognitive load. All the individual work items – each with its own urgency and purpose, beckoning the team to click on them and get lost in the details – create confusion and make it really hard to keep sight of what is important. The trees obscuring the forest, so to speak.

Information Processing Model
Source. Our ability to deal with information is limited. What we can’t deal with is simply lost. Understanding this cognitive load is essential to manage information effectively. Liberating Structures are an example of techniques designed to deal with this.

What can be Done this Sprint?

Once clear on the Sprint Goal and with a firm commitment from the team, it is time to collect the work to achieve it. Having the Sprint Goal makes it ‘safe’ to look at the backlog, as it makes for a very strong criterion to sift through the available work items. We are not looking at the backlog to create our focus anymore; we are looking at the backlog to fulfil that focus.

One thing to keep an eye on during this process is the capacity of the team. Developers generally have two very positive characteristics: They are ambitious and they are optimistic.

It is therefore important to at least make them aware of the fact that they need to think about what will fit in the Sprint. This is an important skill to learn as a team, to improve their Sprints: too much work and the team will work under stress, struggling to achieve the Sprint Goal, too little work and the team will run out of work during the Sprint, which often also leads to stress.

Note that the focus here is on learning. Whether the team gets it right or not is irrelevant. Work is getting done, one way or the other, so the learning doesn’t cost anything. In fact, the more often the team gets it wrong, the faster they will learn. This means that we can focus on creating safety for the team; simply having a laugh at how far off we were can be enough.

How will the chosen work get done?

Having collected the necessary work items to achieve the Sprint Goal, it is time to get started on the final step of the Sprint Planning: determining how the work will get done. In general, I’ve noticed that teams often skip this step. This happens because the work items have been worked out so extensively during the refinement, that the ‘how’ is completely obvious.

As I discussed in the previous article, this has a lot to do with confidence. It takes courage for a team to accept that they don’t need to figure out everything about how to deliver a user story until the Sprint Planning. This reflects on the length of the Sprint Planning: Some teams will spend no time at all on this step, having prepared everything in the refinement. However, the ideal is leaving the ‘how’ to the last responsible moment, and that is this step.

Incidentally, an interesting thing to notice at this stage is whether the team writes new work items. I find this a significant indicator of whether the backlog is leading, or the Sprint Goal.

Just in Time Approach
Source. An effective way of avoiding waste in the form of inventory is a Just in Time approach.

One of my favourite approaches here, working with a team that really leaves figuring out the how till this moment, is organizing a Shift & Share. We will split into 2 or 3 teams, and in separate breakout rooms prepare our approach. Once everyone is ready, we will take turns presenting the plan to each other. It is so satisfying to see how results are often complementary, with different groups focusing on different perspectives! Combining these gives the team not only a very reliable plan, but also serves to reinforce the value of all the individuals in the team.

After that, and depending on the complexity of the work, especially the existence of dependencies with other teams or events, I sometimes like to set up a timeline where we can visually plan the work over time. This also helps to discuss other things in addition to the regular work. For example, meetings with other teams. Knowledge transfer moments. All the things that teams will often hesitate to include in the backlog.

True to the Agile principle of finding our way while we work, I will leave it up to the team to leave the planning of lower-priority work items for further on in the Sprint. I find that it is often more efficient to plan some work after having made an initial delivery. The knowledge that is gained makes it possible to plan the rest of the work appropriately.


For me, the Sprint Planning is the most important event to get right in Scrum. It is the one event that shows best how mature a team is. For a long time, it was the milestone I worked towards, convinced that so many things had to be in place before it would be a success. The refinement must work efficiently, the backlog must be in order, the team must understand what the Daily Scrum is for, etc.

It was Maarten Dalmijn who quite casually told me that with a new team, he always starts with the Sprint Goal. That was a watershed moment for me. It made me realize that Scrum can be as simple as that: start by focusing on the Sprint Goal and all the rest will automatically fall into place, in service of that higher purpose.

I find that this maybe is the key element that distinguishes Scrum:

  • Scrum is not about delivery. It’s not an output-driven approach driven by incoming requests, where the content of the Sprint is determined by the available work items in the backlog

Scrum is about a creative process driven by vision, an outcome-driven approach where the Sprint Goal determines which work items will be picked up during the Sprint.

About the author

Erik de Bos
Scrum Master & Agile Coach

I started life as an ecologist, but found better employment opportunities as a programmer… and soon started wondering why project management never seems to work. Convinced we should be able to enjoy our work much more, I embarked on a quest to find solutions. For me, Agile is the silver bullet, a win-win proposition, and the new competitive baseline against which all organizations are measured. I am a Scrum Master, Agile Coach, writer, speaker and editor. I work at Scrum Facilitators with a group of idealists, where we are committed to helping everyone to understand and adopt Agile.

Related Posts

Run team retrospectives easily, quickly, and absolutely FREE

get started
retro meeting art
Contact Us
Thank you! Your message has been sent!
Oops! Something went wrong while submitting the form.