How to run your first sprint planning meeting

If your team has adopted the Agile methodology, you’re probably slowly incorporating the Scrum framework into your day-to-day work life. 

You’ve already practiced for your daily huddles and estimated how long your first sprint will be.

However, before any of that can come to life, there’s one essential component to kickstart your first sprint—the sprint planning meeting.

If you can nail your first sprint planning meeting, you’re already halfway towards reaching your sprint goal. Feeling nervous? Don’t be, this article is here to help you.

Read on, and you’re sure to run your first-ever sprint planning meeting like a pro.

The first ingredient of a beneficial sprint planning meeting is quality preparation. 

Without this initial step, the meeting will end up unstructured, unhelpful and unproductive for your developers.

Let’s start at the beginning—setting the meeting date and time. Imagine doing this at random, selecting whenever suits you most. 

There’s a real risk key players might be unavailable at the time of your choosing. 

What if the product owner is on vacation? What if your senior developer has another meeting? You’re excluding decision-makers from what is arguably the most crucial part of the sprint.

Therefore, make sure to schedule the meeting when everyone is available. If there’s too much information to juggle, an online tool like Clockwise can help you. 

This app will automatically inform you if there’s a conflict, as shown below:

Not only does the app indicate when team members are otherwise engaged, but it also suggests the ideal time for a meeting based on their availability. 

This feature is invaluable for choosing a meeting time.

When selecting the length of the meeting slot, we suggest following this standard guideline:

If you’re planning a two-week sprint, the meeting shouldn’t last more than four hours. With that in mind, set aside half of the workday to hash out all of the details with your team. 

You might not need the entire four hours, but overestimating is always preferable to underestimating.

Once you’ve secured a meeting period, it’s time to construct and distribute your meeting agenda. 

No meeting is complete without one—the agenda will ensure you stay on-topic, address all the issues you need to, and adhere to the planned structure.

If you’ve never devised an agenda beforehand, there are plenty of templates to use as a starting point. Here’s an example:

Use this agenda as a starting point, and then slowly amend the outline as it best suits your team’s needs.

As part of your agenda, it’s a good idea to include some time to discuss all your story points—estimates of how much effort specific tasks will require. 

Story points indicate how difficult you expect assignments to be and are ranked based on these characteristics:

As you can see, the lower-effort tasks are marked by a lower number and the more complex workload by higher numbers.

It’s vital to decide on the story points for tasks well in advance, as it’s often the best method for gauging how much you’ll be able to get done in a sprint. 

If all of your tasks end up in the double digits, it might be a good idea to cut down or switch them out for simpler ones.

After you’ve prepared everything, it’s time to begin the meeting itself. 

As per the example template in the previous section, it’s always a good idea to start the sprint planning by presenting the goal itself.

The sprint goal is defined as follows:

In other words, the sprint goal serves as a sort of beacon, an overarching objective your team strives to reach by the end of the sprint. 

With this sprint goal in mind, your team should feel more motivated to collaborate, as they’re all aware that they’re moving toward the same aim. 

One Reddit user commented on the importance of this:

The group responsibility should encourage your developers to cooperate and work as best as they can, both to prove themselves and to support the efforts of the other team members. 

The sprint goal also provides direction. If your developers should ever feel unsure during the sprint, they always have a reference point to remind them of what they’re striving to accomplish.

For this reason, it’s always better to present the sprint goal before diving into the backlog items. Dave West, CEO of Scrum.org, explains why:

The sprint goal serves as guidance for what tasks to complete. Although your backlog might be substantial, it is still second place to what will help you achieve the sprint goal. 

You might even devise alternatives that make certain backlog items redundant.

For example, let’s say your sprint goal is to release a manual LED control screen for paired devices (where before, only automatic was possible). 

In that scenario, you can easily remove backlog items such as implement a sequence that utilizes the full LED spectrum or introduce a program that lasts over 90 seconds.

With the new manual set-up, you won’t have to worry about the countless possible automatic configurations. 

Instead, the user can manually choose whichever program they prefer, and items from your backlog will be removed accordingly. 

We suggest following the SMART goal-setting methodology when deciding on this sprint goal. The framework is as follows:

A SMART sprint goal will encompass all of the above attributes. These characteristics provide guidance and particularities necessary when building software—there’s no room for ambiguity.

To draw on from the previous example, a SMART goal would be:

This SMART goal has an exact time definition, is extremely specific, and is attainable. 

With this methodology, the developers have a clear sense of direction and know precisely what they’re trying to achieve.

Once the sprint goal’s been defined, the next item on the agenda is discussing the product backlog items.

A comprehensive list recounting everything that needs to eventually make it into the product, the product backlog is never complete, never empty, and constantly changing. 

Given its large scope, it’s essential to prioritize and choose the items your team aims to complete during the sprint.

Here’s an example of a standard product backlog:

As you can see, all of these features would benefit your software, but some take priority over others. 

For instance, changing one’s username on their own is nowhere near as important as having a search function.

While at the sprint planning meeting, together, you and your developers will need to choose which backlog items contribute most toward the sprint goal and therefore have the highest priority.

However, don’t forget to look at the story points as well. If the sum of all the story points is too high, your developers might be biting off more than they can chew.

After you’ve agreed on which features to focus on, those items are moved from the product backlog into the sprint backlog. 

The sprint backlog is essentially a list of features the team has committed to delivering during that sprint, whereas the product backlog covers all possible features.

The graph below outlines the differences between the two:

As you can see above, the sprint backlog is a subset of the product backlog, listing all the features that should be completed in the sprint. 

This helps your team decide on their tasks for that sprint.

When managing the product backlog, it’s best to adhere to the DEEP principle:

Every time you’re thinking of adding an item to the product backlog, take a moment to assess if that item contributes toward the DEEP principle. 

Is the entry detailed enough for everyone on your team to understand? 

Have you assigned the story points? How high of a priority is it? 

Answer these questions before blindly posting new items.

Upholding a DEEP backlog will significantly facilitate your backlog discussions as the backlog itself gains quality. 

To ensure your backlog stays DEEP, the co-creator of the approach offers the following advice:

Speak to the product owner and your developers about the product backlog regularly. 

This can be done two or three days before the end of the sprint or during the sprint planning meeting itself, but ensure you continuously refine the backlog—it’ll make future planning much more manageable. 

Having pinpointed what backlog items your team will focus on, the next step is to estimate your team’s velocity. 

This metric is one of the most critical measurements in sprint planning, as it determines how much work your team will be able to accomplish during the sprint. 

Scrum Inc defines team velocity as follows:

Team velocity will be challenging to determine for your first sprint, as it’s best calculated once your team has gone through multiple sprints. 

However, for future reference, the standard equation is the sum of completed user story points divided by the number of completed sprints.

For example, imagine that in the first sprint, your team completed 25 story points, 30 in the second, and 35 in the third. The velocity is then calculated as:

25+30+35=90/3=30

The final number can later be used as a reference point for future sprints to estimate how much can be accomplished. 

It’s also a fantastic guide for the product backlog, as it helps determine how many items to pick up.

These estimates will likely waver when you first start estimating, but as your team completes more and more sprints, the number will stabilize. 

A research paper conducted a case study recently that confirmed these findings, stating:

In other words, don’t give up if you’re disheartened at the beginning. Stick with the practice—it will eventually pay off.

Furthermore, the velocity will naturally increase as your team grows and gets used to working together. A familiar team tends to also be a high-functioning one.

For this same reason, it’s important to never compare your team’s velocity to another’s. 

Velocity often improves based purely on your developers’ affinity with one another and can’t be decided based on technical knowledge or years of experience. 

Derek Huether, a principal solutions engineer at Atlassian, has also commented on this:

Just because you’re aware of other teams that have a higher velocity than your own, this doesn’t mean your developers are unproductive. They simply have a different rhythm, 

If you want foolproof data on this rhythm, online tools can help you keep track of velocity. 

Jira is famous for its velocity chart, which numerically records the estimated velocity and the actual completion rate.

Here’s the chart below:

The chart is fantastic for displaying how well your team keeps up with their commitments. 

Using these visuals, you’ll gradually understand how much you can realistically execute and devise more accurate estimates. 

The final yet essential step in a sprint planning meeting is determining task ownership. You’ll need to assign tasks to your team members and decide who will take on what responsibilities.

One of the easiest methods to do so is via a Scrum Board. A visual tool to help organize sprints, a typical Scrum Board is usually divided into four columns:

Here’s an example Scrum Board:

This Jira Scrum Board is a fantastic tool. Not only does it show status, but it also displays the users responsible for that task. 

This resource gives you a clear overview of who’s on top of what.

Tasks are most easily distributed by breaking down the items in the sprint backlog. In other words, each sprint backlog item is achieved by completing various tasks. 

The visual below explains the concept well:

For example, imagine if your sprint backlog item was allow users to update shipping information. 

That item can then be divided into tasks such as update security tests, sketch app screen with designers, update API for shipping, etc.

Furthermore, just as backlog items should be as detailed as possible, these tasks should also be extremely specific. 

The more detail you provide, the more direction you give your developers, and the better they can gauge which tasks to take on. 

This Reddit user offers an example of this:

In keeping with this example, imagine presenting this task to your employees. 

The exact wording makes it easy to choose the best person for the job, as you can ask them directly who enjoys creating database tables. That individual will then likely gladly volunteer.

On the other hand, if you had simply delegated the entire improve data model item, you’d have more difficulty choosing the right person. 

Knowing precisely what the task involves significantly facilitates distributing it. 

After delegating the tasks, it’s a good idea to let your developers assess their assignments before beginning work. 

That way, they can assess whether their tasks are achievable with a level head.

Nicholas Muldoon, the co-founder of Easy Agile, has a similar strategy:

By giving your developers some buffer time between assigning tasks and beginning the work, you allow them to draw up some initial ideas and reflect on if the task is a good fit for them.

If it turns out that they’d rather not take on an assignment, or if they feel out of their depth, there’s nothing to worry about. It’s still the beginning of the sprint, and you’ll have plenty of time to reorganize.

Your first-ever sprint planning meeting is an important milestone for the sprint and your career. If you pull off a quality planning meeting, you’ve already done half the sprint work.

Ensure you come well-prepared to the meeting, and have a clear sprint goal to present to your developers.

Go over the product backlog items, and estimate your team’s velocity. Evaluate how many items they’ll accomplish.

Finally, break down those items into tasks, and distribute them to the most capable team members.

Follow these five practices, and you can’t go wrong—your sprint planning meeting will go off without a hitch.