6 sprint planning mistakes you should avoid doing

When you’re preparing for a sprint, there are a lot of things to think about.

How will you organize the work? How do you prioritize the different stories to work on? How will you make sure the team stays focused on the sprint goal?

That’s a lot to consider, so, as you can imagine, it can be easy to lose your way during the sprint planning sessions.

When this happens, mistakes are likely to follow, and before you know it, your team is no longer moving forward as quickly as you would like it to.

That’s why in this article, we’re going to address six common mistakes that occur during sprint planning sessions and offer a few suggestions on how to avoid them.

Setting goals is a crucial part of being successful in all aspects of the business. 

The sprint planning session is no different: setting a goal can be the difference between a successful sprint and one that doesn’t meet expectations. 

Still, when the new sprint begins, it can be tempting to jump straight into tackling its tasks without determining a goal first.

This is, however, always a mistake—and Maarten Dalmijn, a product management leader at Signalbound, has provided us with a good reason why.

Without a clear sprint goal, your sprint plan will rarely yield good results. 

In his article The perfect ingredients to fail your Sprint Planning, David Pereira further elaborates on the topic by identifying some of the possible consequences of failing to define sprint goals.

As an experienced product manager, he has conducted a fair share of sprint planning sessions and seen what works and what doesn’t firsthand.

He believes that three of the six biggest mistakes you can make during sprint planning are closely related to not identifying a goal for each sprint, as illustrated in the picture below. 

And undoubtedly, without a set goal, it’s easy to get bogged down in trivial details.

If we don’t define what is important, he states, then everything will become equally important.

When this happens, we may end up wasting time on tasks that we don’t need to complete during this sprint and overlook important ones.

He even goes so far as to compare the sprint goal to a lighthouse and a north star, both of which are reference points for navigation. 

Without the sprint goal, he argues, there isn’t any common direction, and collaboration becomes challenging.

Therefore, the goal should be evident from the very beginning of each sprint planning session so that the team members can align their efforts around it.

Only after the sprint goal is established should they begin planning how to achieve it.

When you and your team members are focused on completing the day-to-day tasks, the backlog can easily fall by the wayside.

After all, you’re busy trying to deliver on your commitments—you don’t have time for backlog refinements for the upcoming sprints.

But, this is precisely what you should do—step back from the current sprint for a moment and schedule a time to review and update the project’s overall backlog.

Before we go further, let’s take a look at what the backlog is and why exactly it’s important to refine it before the sprint planning meeting.

As the picture shows, the concept of the product backlog is straightforward: it’s a list of prioritized tasks that need to be done.

At the top are tasks with high priority, and at the bottom are those of lesser importance.

Every backlog is supposed to undergo refinement at some point in order to make it more compact and clear.

Backlog refinement is also called backlog grooming, and Sari Harrison, chief product officer at Retreat Guru, prefers this term because it perfectly describes its ongoing nature: it’s not a one-time activity but rather something that requires continuous attention.

She has also seen many teams try to ignore backlog grooming, and the consequences can be dire. She states:

David Pereira, who has seen how poorly managed backlogs can hurt teams firsthand, is even harsher in his assessment.

But you can escape this quandary. By conducting product backlog refinement prior to the sprint planning meeting, you’ll be better prepared.

But when it’s the best time to run it, you may wonder?

Dave West, CEO of Scrum.org, suggests that if your sprint is two weeks long, you should hold a backlog refinement meeting midway through it.

That way, you and your team will have plenty of time to do it and still handle your normal workload.

Christian Strunk, a product and leadership coach, expands on this idea by stating that you should share the refined backlog with your team at least 24 hours before the initial meeting, as he has seen great results from that approach.

All in all, backlog refinement can greatly improve the outcome of your sprint planning meeting. 

It’s even safe to say that, without it, you may have trouble running both the meeting and the sprint.

Without a proper agenda, your sprint planning meeting might go on for hours without accomplishing anything meaningful.

An agenda is important not only to keep the meeting on track but also to ensure that everyone remains engaged.

Let’s look at what Cameron Herold, the founder of COO Alliance and author of Double Double and Meetings Suck, has to say about meetings without agendas to get a better picture. 

Although he was talking about meetings in general, the same remarks apply to sprint planning sessions too.

Without a meeting agenda in place, the discussion can get sidetracked, and the team won’t be able to reach a consensus on what they need to do during that sprint.

The agenda also helps keep meetings focused, making sure that all participants are aware of what topics need to be discussed and preventing them from wandering off-topic or engaging in side conversations.

Christian Strunk, whom we’ve already mentioned earlier, presents a similar view:

The importance of having an agenda becomes even more evident if we consider that for the sprint that lasts, say, three weeks—a meeting time frame of six hours is proposed.

And that is a lot of time to spend in the meeting, during which it could be almost impossible to follow the stream of thoughts and ideas of everyone in the room if there isn’t some kind of structure established.

Therefore, a simple agenda like the one pictured below can make all of the difference when it comes to getting your team members to participate in the meetings and stay on point.

As you can see in the picture, the agenda should contain a list of topics for discussion, with an estimate of how much time each item will require.

You can use this framework as a starting point and then modify it to suit your needs or create an agenda specifically for your team. 

The bottom line is to make sure that the agenda is thorough and clearly outlines what needs to be discussed and when.

Many teams fall into the trap of focusing too much on velocity during sprint planning and not enough on quality.

But to better understand this issue, let’s see first how the velocity is calculated in sprints and why giving it too much attention can damage the team’s quality of work. 

Velocity is the number of story points a team completes per sprint (as shown in the graph below).

The whole concept is based on the premise that at the beginning of each sprint, you have an idea of what you can accomplish, and at the end of each sprint, you know how much has been accomplished.

If a team achieves more than it originally estimated, its velocity increases. However, if it doesn’t finish all the work it planned, its velocity goes down.

Therefore, if you keep track of your velocity for several consecutive sprints, you’ll get an estimate that indicates how many story points your team is completing over time.

And based on this estimate, you can predict how many story points the team will perform in future sprints. 

By doing this, you and your team can decide how many product backlog items to plan for completing in each future sprint.

But the danger is that when velocity becomes the be-all and end-all—where people are more focused on achieving a certain number of story points than on creating excellent work.

As this can lead to more bugs, slower delivery times, and unhappy customers, teams should not focus on velocity at the expense of quality.

They should first determine what it is they need to accomplish and how difficult the tasks are likely to be and then decide on how many of those tasks they can complete in a sprint.

Maarten Dalmijn suggests that planning for less could be an even better solution. Here’s what he says on the topic. 

This way, if you have some extra time, you can always add more work to the backlog.

Also, when the team commits to smaller, more achievable tasks for each sprint, they are less likely to carry over into future sprints.

You might think that making changes during a sprint is unrelated to the planning of that same sprint, but in fact, they are tightly linked.

When your team believes it has to strictly follow the sprint plan and has little or no room for maneuvering, they will spend too much time and effort trying to perfect every tiny detail of the sprint plan, as there is no room for error.

And it’s clear why that would be detrimental to the planning process.

It’s impossible to anticipate all the challenges, urgent requirements, or unresolved bugs that will inevitably pop up during a sprint.

In light of these considerations, teams should not be led towards a no-change policy.

For this reason, Maarten Dalmijn suggests that you do the following:

If the plan sets unrealistic deadlines and expectations, stress levels will increase, and the pace of production may decline.

Barry Overeem, a co-founder of The Liberators, agrees that teams should be given the flexibility to change plans if they feel it’s necessary, but adds a caveat: only as long as the sprint goal isn’t compromised.

Let’s see what he has to say.

To sum up, when the team members know that they’ll be able to make changes in the sprint, they are allowed to shift their focus accordingly.

The plan should give the team a general idea of what a successful sprint will look like, but it’s not meant to be written in stone.

What matters is that the team completes the sprint with an outcome that meets the goal set in sprint planning.

When scheduling a sprint, you should be sure that everyone who is supposed to participate is able to do so.

If you fail to check the sprint capacity, delays are likely to result—which will make it impossible for your team to meet its deadlines and sprint goal.

But what exactly is sprint capacity?

To answer this question, let’s see how Allie Beazell, director of developer marketing at Census, defines capacity.

Scrum teams use the sprint capacity to define how many days each developer will be available during each sprint.

Knowing who will be on vacation or blocked by meetings or other activities will have an impact on the work being finished.

As Christian Strunk notes, failing to consider capacity can negatively impact a sprint.

So how do you calculate your team’s capacity? 

It’s easy: just plug the numbers into this equation below.

Then multiply the number of team members by the number of productive hours they can work in a day.

After subtracting time spent on meetings and other activities when they’ll be unavailable, you can get an accurate picture of what your developers have left for regular duties.

These calculations will give you only an estimate of your resources, but it should be enough to make a reasonable guess about their availability.

And if you want to make capacity planning even easier, Christian Strunk has also created an excellent spreadsheet that will do the work for you.

Remember, you can’t manage what you don’t measure.

You may not be able to predict how many resources you have with 100% accuracy, but if you’re aware of the factors that influence capacity, you can make better decisions about how many tasks your team should work on in a sprint.

Sprint planning is an essential part of any agile project, as it’s the time when the team gets together and figures out what they’ll be working on.

But with all the excitement of a new sprint, there are some things that can easily get overlooked in the planning stage, but which can lead to big problems later down the line.

The six common mistakes that we’ve listed in this article should give you a good heads up on what to look out for so that you can avoid them when planning your next sprint.