The sprint planning – minor tweaks and best practices that make it easy

The sprint planning meeting in Scrum is the ceremony that kicks off every sprint. If prepared correctly, it is the smoothest of all the Scrum meetings and sometimes takes no more than a few minutes. The planning can, however, also descend into chaos and be a huge source of discontent and frustration for the team.

As it is so often, the overlooked details are what influence the effectiveness of the sprint planning. I will address exactly those today.

I will first explain why the planning exists, what it is, and how it works in practice. Finally, I will share three of my best practices for ensuring a smooth sprint planning meeting that often takes no more than 15 minutes.

Email address:

Leave this field empty if you're human:

Why this Scrum ceremony exists

Within a sprint, we spend time, money, and energy enhancing a product. Thus, the sprint is essentially an investment of resources into a product. 

The sprint planning ceremony is there to explain what purpose the next investment will serve and why it is worth doing that. In its essence, it is there to define the outcome we want to achieve within the next iteration.

Additionally, the planning has a motivational effect on the team as the members define and commit to a goal and plan that is their own.

What is the sprint planning?

The sprint planning meeting is the scrum ceremony that kicks off the sprint. It is where the team defines a goal and, well…. plans the coming iteration. As such, together with the Product Owner (PO) the team sets the outcome for what it wants to achieve and outlines how it will achieve this. 

The result of the sprint planning meeting is a sprint goal and a sprint backlog. The sprint backlog contains all user stories and tasks that the team will attempt to implement in the sprint. All items are already broken down and the team has a rough idea on how it will implement them.

Sprint planning in practice

Upfront, the planning will be very different depending on if your team conducts a refinement meeting or not. The refinement is not part of the official Scrum Guide. I do think it’s something worth considering, though. More on that in a minute. Let’s look at the sprint planning by the book first.

The participants of the planning meeting are the team, the PO, the Scrum Master, and – if necessary – other stakeholders join to answer specific questions. 

The sprint planning generally consists of three parts. First, the PO gives some guidance on what outcomes we want to achieve. Jointly the entire team then sets the sprint goal. Second, the team answers the question of how much we can achieve. In practice this means they go from the top of the backlog of prioritized, fully refined, as well as estimated user stories and determine how many they can implement in the next iteration. 

Third and finally, the team breaks down the stories and plans how it will implement them. This is the part that is impacted by (not) having a refinement session. In case you chose to have one, this last part will be obsolete or done quickly, since most or all of the stories will already be broken down and planned upfront in the refinement. 

My best practices for the sprint planning

Conducting the planning meeting is pretty straightforward. However, as it is so often, the details are what make or break this Scrum ceremony. For this reason, I want to elaborate on three best practices that improve effectiveness of the planning:

• The benefits of a separate refinement session
• Dealing with team capacity
• Dependencies to other teams

The benefits of a separate refinement session

For the vast majority of teams, I recommend having a separate refinement meeting during the sprint where the team already plans the implementation of stories. This makes, in my view, much more sense than doing this during the planning.  

The reason for this is simple: removing uncertainty as early as possible. It’s hard to estimate a given story and uncover hidden dependencies before understanding how we plan on implementing it. Oftentimes, it is exactly during the process of discussing how to build a feature that we find that we forgot something. Maybe some other team still needs to do something or maybe we cannot do it before finishing something else. 

If we uncover this during the planning it is likely too late. Depending on what we uncover, we often aren’t able to resolve the issue during the planning and thus are left with two choices. Either we postpone the implementation to the next sprint, or we add a story to our current sprint that is missing some sort of input. Neither is a good option and I particularly advise against the latter. Adding an incomplete story will have a host of negative downstream effects.

On the other hand, if we uncover the missing input or some other issue during a separate refinement session, we have at least a few days to try and resolve this before the next sprint starts.

In my experience, having a refinement meeting also significantly shortens the planning to be no longer than 10-15 minutes. This gives us some buffer to discuss new stories or tasks that may have come up short notice. We sometimes conduct an ad-hoc refinement during the planning where we prepare the short notice stories to be added to the sprint, provided we are able to fully refine them.

Dealing with team capacity

For any PO it is a challenge to balance the things we want to achieve and the available capacity. Naturally, the PO always thinks that there is enough capacity for just one more story. The urge to apply pressure and add it is always there. However, applying too much pressure risks unhappiness and demotivation in the long run.

I tend to use the velocity of the team, i.e. the amount of story points completed in the last sprints, as a starting point for the discussion. The emphasis here is on starting point. Story points can help but are an imperfect and subjective measure. 

In the end the engineers should and need to decide if the number of stories are realistic within the next sprint. In practice, this often means that we start out with a number of stories whose story points added up more or less equal the velocity of the last sprints. (Don’t forget to consider holidays and vacations.) We shortly discuss them and add or remove stories based on our joint evaluation. This is honestly mostly based on gut feeling with the story points as a guideline.

We then have a look at the types of stories and tasks we are proposing – i.e. what buckets they belong to (user value vs. business value vs. maintenance vs. tech value) – to determine if the distribution seems balanced. 

In this context, the engineers will often point out some maintenance or tech debt tasks that we should be doing at this point in time. My advice to any PO is to trust their evaluation and, if at all possible, add it in favor of something else. This will pay dividends in all kinds of ways down the road.

Once we are done discussing and moving stories in and out of the next sprint, we end up with a proposed sprint backlog. We then take one last look and the team confirms if it is realistic to complete all of the tasks and user stories. Finally, we start the sprint.

Dependencies to other teams

This one is going to be short: If a story or task has an unfulfilled dependency to another team or function, don’t add it to the sprint! I feel so strongly about this that we generally add it to our definition of ready for stories and tasks.

Sometimes, it is impossible to do this, particularly when close to deadlines or launches. On the whole however, it should be avoided at all costs. Different teams have different priorities and thus, more often than not, the dependency will not be resolved during the sprint. This leads to unfinished sprints, frustration, and bad feelings towards others.

Let the team decide

In short, having an effective planning means making sure the stories are fully broken down upfront, not adding stories with unfulfilled dependencies, and most importantly letting the team decide how much they can do in the next sprint. 

This last part is extremely hard to do for any Product Owner. But trust me, humans want to perform and be proud of what they do (also, the engineers know best anyway). Leaving this up to them will in the short term lead to the same outputs. In the long term, you will find a more motivated and more productive team. 

Take the leap and try it for a few sprints. You might be amazed at what happens.

Coverphoto by N. on Unsplash