Sprint planning: what, who, when, and how

When it comes to scrum, the most important part of the process is the sprint, a time-boxed iteration where a team focuses on completing a set of work.

Much like a musical piece, each sprint is divided into parts, with each part building on top of what came before.

And just as in music, all parts must be in harmony and orchestrated perfectly in order to have a successful performance.

Sprints are no exception. Without a proper plan in place, each sprint would be prone to difficulties and inefficiencies.

In this article, we’ll reveal the nitty and gritty of conducting successful sprint planning sessions. 

Keep reading for more information.

Before we go into details about the sprint planning process, let’s clarify what sprint planning is and why it matters.

In a nutshell, it’s a meeting in which the entire team comes together to create a plan for the work that will be done during the next sprint. 

As you can see in the image above, the team will consider what’s been accomplished so far and pending tasks from the backlog—and plan accordingly.

As such, sprint planning not only helps keep track of what the team is doing but also gives them a clear direction to work towards. 

However, it’s worth mentioning that the delivered sprint plan isn’t supposed to be set in stone but rather be a living document that changes as new information comes in.

Or how Dave West, CEO of Scrum.org, perfectly points out:

During sprint planning, it’s easy to forget that you are building a plan for only two to three weeks—and get caught up in the details.

The plan that results from a sprint session like that doesn’t have to be perfect, but simply good enough to get the team through the next sprint and that leaves a little wiggle room for unexpected issues that may come up.

There are no hard-and-fast rules for when you should hold a sprint planning meeting, but the most common approach is to conduct it at the beginning of each sprint.

In fact, many teams hold it on the very first day of the sprint before they start working on any new features.

For example, Manuel Küblböck, an agile and lean practitioner, worked in teams where sprint planning typically started with a Wednesday morning meeting at the beginning of a new sprint.

The team would come together in a room, and the product backlog would be on display for everyone to see. Then they’d discuss what could be accomplished in the upcoming period.

While the team usually plans its sprint in a sprint planning meeting, it sometimes acts earlier by engaging in backlog refinement, i.e., going through every item on its working list and deciding whether to keep or remove it.

Let’s see what one Scrum.org user has to say on the matter.

To sum up, cleaning up issues in the product backlog precedes the actual planning, but a proper sprint planning session occurs at the beginning of each new cycle.

It only makes sense that a sprint planning meeting—where you discuss how the team will build and ship a product during the next development cycle—won’t be quick.

Because this isn’t something you can finish in just a few minutes, you should make sure to allocate ample time to that initial meeting.

A good rule of thumb is that for each week of a sprint, the duration of the planning meeting is about two hours.

Thus, a one-month sprint planning meeting should last about eight hours in total—although, of course, you don’t have to do it all in one sitting. You can break it up over several days.

However, this rule of thumb won’t always apply.

Ken Rubin, a managing principal at Innolution, thinks that how you schedule your sprint planning meeting can depend heavily on the team’s experience—and that the link between planning and duration shouldn’t be strict.

Let’s see what he has to say about this topic.

That means that the proposed rule of thumb is not an inviolable one. 

Rather, it’s a good guideline that can help you schedule sprint planning meetings in your team’s calendar.

In practice, though, the length of your sprint planning meeting will most likely depend on a number of factors specific to your team.

The key principle of agile is to bring people together in order to work in a collaborative fashion.

Sprint planning is not a top-down affair where the management dictates a list of tasks to be completed by the team.

Instead, it’s a cooperative process in which all team members and stakeholders are included.

Therefore, as you can see in the picture below, the scrum master, product owner, and development team are all invited to attend sprint planning sessions.

Let’s examine each role separately.

The following diagram provides a simplified view of the roles and interplay between them that can help you better understand how they collaborate.

Although there is no limit to the number of people who can be involved in sprint planning, including too many participants rarely yields good results.

To avoid unnecessary confusion, the planning team should include only those who are directly involved in making decisions about the sprint.

In one of the previous sections, we mentioned backlog refinement as a key activity that needs to happen before the sprint planning session.

Now let’s expand on this idea and look at the ways that it can help teams plan their sprints better.

The team members should hold a pre-planning session to review where they’re on their roadmap, what needs refining in terms of backlog items—and identify which user stories or epics should go into the next sprint.

Preliminary planning is conducted for the sprint planning meeting to go more smoothly, preventing it from turning into a long, drawn-out process.

The best time to start planning for the next sprint is during the current one, but according to Dave West, the CEO of Scrum.org, there are some important tips on pre-planning worth considering.

Keep in mind that backlog refinement is not mandatory, simply because not all backlogs need it.

However, it’s usually a good idea for teams to schedule some time in advance of the sprint planning meeting to review and refine their backlog. 

It can help them identify any gaps or issues that need more attention during the formal planning process.

After the team has decided on which tasks will make it into the next sprint, it’s time to plan the sprint.

This is where the team takes all of their tasks and breaks them down into user stories, which are then prioritized.

Once this has been done, the team will create an overall plan for the sprint.

But without further ado, let’s now look at how planning usually takes shape.

Drafting a sprint goal can feel redundant when the team is getting started on a new sprint.

After all, they’ve already spent a lot of time refining the sprint backlog, and the goal may now seem like a formality.

But highlighting the sprint goal is important—it helps keep the team focused on what they’re working towards, and it gives everyone something concrete to rally around.

That’s why the goal-setting should come first, and here’s a step-by-step breakdown of what that usually looks like in practice.

As you can see in the picture, the product owner is responsible for drafting the sprint goal, and it would be wise to create it and share it with everyone even before the sprint planning session begins.

The team is encouraged to tweak the sprint goal if necessary and display it in a visible place, like a whiteboard, so it’s always top-of-mind for everyone on the team.

Once the sprint goal is in place, it’s time to start planning the process itself, and that usually begins with a review of the product backlog.

The team will take a closer look at all the user stories that haven’t yet been implemented and sort them by priority.

In theory, this should be an easy decision. After all, you just have to pick up the top priority items from the backlog that are ready to be worked on and put them in the sprint backlog.

But sometimes, things don’t go as planned, and you may need to make tough decisions about what stays on the product backlog until later and what needs immediate attention.

If that is the case, it’s best to prioritize user stories by choosing the lowest hanging fruit—those that will provide immediate value for users—by filling in the formula below:

By filling in the answers, teams can easily see what stories provide the most value for the users and should come first in the backlog.

It’ll help them think about the task from a customer’s point of view and enable them to give higher importance to the tasks that are more valuable to the customers.

Once the backlog is settled and sorted, it’s a good idea to let team members determine for themselves what they want to work on based on their skills and roles in the company.

Scrum promotes the idea of self-organization and self-management, so letting the team choose their own assignments enables them to take full responsibility for their work.

The product owner should provide the team with a prioritized list of tasks and allow them to decide which ones they want to work on.

In this age of modern technology, it makes sense to use collaboration tools for this purpose.

For example, the picture above shows how you can use Jira, a management tool popular among developers, to create a shared backlog in which team members can see what tasks are available, their priorities, and estimated effort.

That way, they can easily choose what they want to work on, flag tasks as done when they resolve them, and basically keep track of everything that’s going on in the sprint.

The benefit of this kind of self-organization is two-fold. First, it allows the team members to make decisions in a timely manner without having to wait on others.

Second, it fosters collaboration between them because they’re trusted with deciding what work they’ll be doing each day.

No sprint is managed in isolation. Whenever one thing must happen before another, there’s a dependency at play.

Within a single sprint, many dependencies exist—for example, between team members and their tasks or steps in the process that depend on each other.

If a task must be reviewed before it can be delivered, or a feature has to go through testing before it can be released, then those tasks are linked by dependencies, as shown in the picture below.

This makes it easy to see why the team needs to identify and create dependencies during sprint planning.

By doing so, team members can better align their work with that of others and ensure that the right features are being built in the right order.

Some tools, such as Jira and Big Picture, for example, enable teams to visualize dependencies to see how tasks are interrelated.

The type of dependency mapping illustrated above is sometimes referred to as a red string visualization because on the physical Kanban boards, a red string is often used to represent dependencies.

All in all, by creating a visual representation of dependencies, teams can better understand the work that needs to be done and plan accordingly.

This helps them to communicate more clearly, increase the efficiency of their processes, and deliver software faster.

There are several ways to measure a team’s velocity, but the most common one is by counting how many story points they can complete in a sprint.

But before we dive into that, let’s first explain what story points are so no one gets confused.

Story points are a unit of measure that describes the size of a particular user story. They’re used to estimate how much effort it will take to implement a feature or complete a task.

For instance, more complex tasks will be assigned higher story points than simpler ones, as the picture below demonstrates. 

Let’s use a hypothetical team to illustrate how the velocity metric works. This team plans on completing 41 story points during their first sprint.

However, they’ve managed to complete only 38 story points in this sprint and rolled 13 over to the next. 

So their overall velocity is 38 for this sprint—the image below shows exactly how that number was calculated.

However, the velocity of one sprint doesn’t tell us much about how quickly the team can complete their assigned tasks.

To calculate this more accurately, we should take into account the velocities from multiple sprints.

Let’s then examine the team’s performance in a few more sprints and see what happens.

The image below shows that the team finished 38 story points in their first sprint, 29 in their second, 38 in their third, and 39 in their fourth.

So, their average sprint velocity is 144÷ 4 = 36.

Based on these calculations, the team can plan to complete 36 story points worth of work in the following sprints.

If the team has, for example, 180 story points remaining in a project, it’s safe to assume that it’ll need five more sprints to finish the job.

This is how you can get an idea of your team’s velocity. The figure will be only an estimate, so take it with a grain of salt—but this technique will help you plan future sprints.

Sprint planning is one of the most important meetings in the scrum.

It’s the meeting where all of the product backlog items are put together into a single sprint plan.

It’s also where team members can make sure the plan is achievable.

That’s why it’s important to build a strong foundation for your team’s sprint at the outset.

Only this way can you ensure that your team understands what needs to be built and how much work there is to do.