When does the team plan what it hopes to accomplish and complete during the upcoming sprint?

If your organization is operating on sprints or transitioning to a Scrum framework, then getting the sprint planning meeting right is a top priority.

Put simply, the sprint planning meeting can make or break the entire sprint — and your project team's morale and cohesiveness.

In this brief article, we’ll define sprint planning meetings and show you why they matter so much. Then we’ll walk through seven key items to include in every sprint planning meeting.

Why is sprint planning important?

Sprint planning is essential within the Scrum framework because it sets the course for the upcoming sprint. Effectively, without sprint planning, there is no sprint. You may have a bunch of individual contributors working hard, but they won’t work as a cohesive unit toward a shared goal.

Here’s an analogy: Think of the sprint like a real-world race. You can’t just shout “Go!” into the air and expect something coherent to happen.

First, you need to set up the race: Where is it taking place? How long is the course? Where do the runners go, and where’s the finish line? Are there any unusual elements, like hurdles or batons? Who’s running, and do they know?

All that work of defining and preparing for the race is sprint planning. And it matters because the sprint cannot succeed without it.

Chris Bee, CTO of Lessen, on sprint planning:

“It’s an opportunity for us to really dive in, challenge assumptions, understand requirements, give input, and eventually settle on something we can ship together. It’s a nice touchpoint to center us back in collaboration mode,” shares Chris about how his team works.

How long is the typical sprint?

There is no formal requirement for sprint length, but most fall between one and four weeks. Arguably the most common length is two weeks, or 10 working days. Many agile teams devote a portion of every other Monday (or every Monday, in the case of weekly sprints) to debriefing from the previous sprint and planning the next one.

Some organizations operate on a fixed sprint length, where sprints are always two weeks long. Others adapt to the moment's needs and must determine a sprint’s length during its sprint planning meeting.

One of the key principles to running effective meetings is covering the right material — and nothing extraneous or unimportant. For maximum effectiveness, work to cover each of them in the sprint planning meeting that kicks off every sprint.

Sprint Meeting Agenda Key Items

1. Establish the sprint goal

Before jumping into objectives or the work itself, ensure your team establishes a sprint goal. According to the Scrum Guide, every sprint should have a singular objective, called the sprint goal. All the work within the sprint should support that goal. It’s not necessarily a problem to have multiple objectives supporting the goal, and every sprint will certainly have numerous tasks to complete. But the Sprint Goal is the key.

Stefan Wolpers, a professional Scrum trainer at Scrum.org, notes that failing to set a sprint goal is unfortunately quite common, and he warns that failing to set a sprint goal demotivates teams and destroys focus.

Left unchecked, this lack of focus will eventually degrade the team into an assembly line mentality.

2. Review previous sprints and product backlog

The sprint planning meeting should include a review or debrief of the last sprint: Was it a success? Was there anything from the backlog the team expected to complete but didn’t? Were any lessons learned in last sprint’s work that suggest adjustments are needed?

Next, the team should examine the product backlog and select those tasks that contribute toward the sprint goal. This step should not be automatic or perfunctory: You should discuss why and whether each task contributes toward the goal. This step aims to narrow down which items to include in the sprint backlog.

3. Discuss team capacity

Next up is a conversation about how much the Scrum team can realistically accomplish during the sprint. If you’re the Scrum master or product owner, you’ll do some estimating here: Some task durations may be well known, but others are a bit more open-ended. When you have previous project or sprint data to pull from, do so.

Sometimes your team will end up with more tasks than they can accomplish during a sprint. This might mean the sprint goal is too broad, or it could mean that your progress toward it will only be incremental.

Also, somewhere within the previous and this step, make sure the team agrees on a definition of "done" for the sprint. This shared understanding of what success looks like will benefit everyone at the next sprint planning meeting.

4. Identify bottlenecks

Even in Agile project management, it’s possible to have task dependencies — product backlog items that can’t be finished until something else is done. When one member of the development team or an external contributor falls behind or is overallocated, you’re facing a bottleneck. It isn’t possible to proceed to an item in the sprint backlog until the bottleneck clears.

Bottlenecks aren’t ideal, but invisible or unidentified bottlenecks are much, much worse. Now is the time to discuss any bottlenecks and brainstorm solutions with team members. You may need to allocate resources differently to ease the bottleneck, or the entire Scrum team may even need to adjust what they pull from the backlog during this sprint planning session.

5. Define action items & next steps

Next is assigning specific tasks from the sprint backlog to specific resources on the team. Each team member should receive actionable next steps: which tasks or items the team member will need to complete during the sprint.

Usually, the product manager or product owner will be closely involved here as the individual who knows the scope of the product best. The Scrum Master or project manager should also facilitate with an eye toward team members’ abilities, capacity, and any upcoming dependencies on the product roadmap.

6. Establish a timeframe for the sprint

Each sprint should have a time limit, a concrete ending point where it’s time for another sprint review and then a new sprint. If you’re in a two-week sprint cadence, your team can assume the timeframe. If not, make sure the whole team understands and agrees on an ending point for the current sprint.

Usually, this ending point looks a lot like a sprint retrospective.

7. Field questions from the entire Scrum team

The final component of the sprint planning event should allow team members to ask any remaining questions related to the upcoming sprint. Team members may have questions about specific deliverables, what a successful sprint would look like, stakeholder priorities, or anything else connected to the sprint. As long as the questions remain relevant and on topic, no question should be off limits.

Check out Range’s sprint planning template today

For followers of agile methodologies like Scrum, the sprint planning meeting is one of the most crucial of all Scrum events: It sets the scope, focuses the team, and motivates all involved toward better performance.

Of course, an effective sprint planning meeting starts with a strong meeting agenda, and there will be plenty to discuss over the course of this meeting. You’ll need a place to store and track this sprint iteration and all the team plans discussed in the meeting.

• Collaborate better with more effective meetings
• Easily facilitate balanced discussions that make every meeting worthwhile
• Keep everyone included and on track with much less effort.
• Build agendas, record actions, and share notes automatically
• Create a recurring agenda for all the topics your team discusses every week from metrics to project updates.
• Empower discussion by building a collaborative agenda & spinning to select others to speak
• Easily document notes from each topic to keep everyone in the loop.
• Share notes via Slack & email

See Range in action today: Check out our powerful sprint planning meeting template now for free.

Having an efficient sprint planning meeting agenda goes a long way in advancing a software product. Agile software development aims to add more value to a software product through incremental development. We call these increments sprints.

A sprint represents a specific amount of work that can be completed in a given amount of time. The sprint planning meeting aims to allow the development team to identify, estimate, and include meaningful work in an upcoming sprint. In this post, we'll be exploring the basic building blocks of a sprint planning meeting agenda.

What Is the Sprint Planning Meeting?

As I mentioned before, a software development sprint represents a grouping of user stories that the development team has committed to completing during the next iteration of the development process. However, before each development sprint can start, the development team must understand the work and commit to completing it in the time allocated for the sprint.

The sprint planning meeting is a formal meeting during which the development team identifies and estimates the work for the next sprint.

It's this understanding of the work and the commitment to complete it that requires a specific kind of meeting to occur.

Let's start by looking at the main goals of the sprint planning meeting.

How do you know this meeting is a success? Or, even better, when should the sprint planning meeting be considered done?

The ultimate goal of the sprint planning meeting is for the development team to commit to completing a significant chunk of work during the coming sprint.

Essentially, choosing work for a sprint involves understanding and estimating the work. In order to achieve this ultimate goal, there are two supporting intermediary goals that also have to happen during this meeting.

Firstly, the product owner gives a vision or justification for the work considered for the next sprint. The product owner identifies and prioritizes what represents meaningful work and why it's meaningful. Consequently, the development team evaluates and actually picks the work for the upcoming sprint.

Let's now focus on who's attending this meeting and develop a sprint planning meeting agenda.

Who's Coming to the Sprint Planning Meeting?

Everyone attends the sprint planning meeting. OK, not the entire company, but the entire development team must attend.  This includes the product owner, scrum master, developers, and quality engineers. Let's look at each of these people and their specific roles to play during the sprint planning meeting.

The Product Owner

What does the product owner need for this specific meeting?

The product owner creates and maintains the product vision, which is usually based on customer input, market research, and company requirements. The product owner keeps the big picture in mind and articulates it frequently to the rest of the team. In addition, the product owner ensures that every user story in the backlog aligns with the product vision.

Therefore, in preparation for the sprint planning meeting, the product owner has already assigned clear priorities to the user stories in the backlog. Having clear priorities aligned with customers' needs ensures that development efforts focus on the most meaningful work.

At the beginning of the sprint planning meeting, the product owner reiterates the product vision and how this coming sprint aligns with the product vision.

The product owner will be successful when the development team has understood the product's vision and how the coming sprint advances this vision.

The Scrum Master

If the team has a separate scrum master role, this person will be ready for the sprint planning meeting with two things: a good understanding of current team velocity and a good understanding of upcoming work schedule restrictions.

Understanding team velocity goes beyond just knowing the number of points the team usually accomplishes during a sprint. It also includes understanding the normal circumstances with the normal team velocity. Risk and variations to normal team velocity include things like changes to the development team changes, technology, or company. The scrum master keeps these things in mind and brings them forth.

Secondly, the scrum master brings forth any time limitations for the upcoming sprint, like vacations and holidays.

The scrum master will be successful when the development team has understood the limitations for the coming sprint.

The Development Team

Everyone involved with doing the work attends this meeting. A development team may contain designers, user experience experts, quality assurance, and developers, of course. Larger companies can have different roles shared between different development teams. However, for this post, we only consider the simpler case when we have one development team dedicated to one product.

How do members of a development team prepare for the sprint planning meeting? Well, it all depends on company culture.

Some companies purposely don't want developers to prepare for this meeting so they can look at the user stories with fresh eyes and without prejudice. Other companies require preparation. These companies expect developers to read through user story descriptions and give some thought to the implementation.

The development team is successful when they have clearly understood, evaluated, and embraced the work for the upcoming sprint.

With all these things in mind, let's put together a sprint planning meeting agenda.

The Sprint Planning Meeting Agenda

Here are the main building blocks for your sprint planning meeting agenda. It's important to mention that these specific events usually blend together into one free-flowing conversation instead of a specific set of steps.

1. Maintain Product Vision

The product owner presents the context for the work considered for the next sprint. The product owner explains where the user stories come from, such as customer requests, customer support, or the marketing department.

In addition, some user stories come from older sprints because they were not completed previously. Lastly, a sprint may also include important bugs. Bringing all of these things together helps form a specific sprint goal.

2. Consider Existing Constraints

The scrum master presents any limitations for the upcoming sprint as well as existing team velocity. Limitations include upcoming holidays and staff vacations. Team velocity helps the team evaluate (velocity should only be used by the team) what they can realistically complete during the coming sprint.

3. Estimate the Work

The development team reads through each piece of work (i.e., user story) and evaluates its complexity. This is notoriously difficult, which is why increasingly teams are turning to tools like LinearB to plan more accurately. For agile development, we estimate complexity, not time required to complete. As a consequence, we assign complexity points to each story we evaluate.

Evaluating upcoming work means that each team member gives their estimation for a user story based on the information presented and each member's experience. Regardless of the voting mechanism used, the goal is to achieve a team consensus where team members are comfortable with the complexity score assigned to each story.

Estimating the work for an upcoming sprint must be a free-flowing conversation.

4. Commit to the Work

Toward the end of the meeting, the team commits to work for the upcoming sprint. Some teams make this a formal event, while others keep it as informal as saying, "Let's get it done!" It's worth repeating that the development team picks what they'll work on during the next sprint. It's not the product owner or the scrum master who ultimately chooses.

The team performing the work determines and commits to the work to be completed.

Do You Have a Sprint Planning Meeting Agenda?

In this post, we explored the basic building blocks for an efficient sprint planning meeting agenda. In addition, we considered what happens during the sprint planning meeting. Having a successful sprint planning meeting is crucial to completing meaningful work and developing your product.

For more tips on how to best plan for a sprint, check out this post.