Sprint planning meeting agenda: what does it look like?

The sprint planning meeting is a key event in the Scrum framework. Being the first meeting before the beginning of a new sprint, it sets the scene for the upcoming week—if not more.

In the sprint planning meeting, you’ll comb through the product backlog, decide on action items, define a sprint goal, and dive into multiple user stories.

With so much material to cover, you’d do well to create an agenda to keep you on track during the meeting—that way, you won’t forget anything.

Read on to familiarize yourself with a standard sprint planning meeting agenda, and organize a fantastic meeting.

Review the last sprint

Before planning your next sprint, you’d do well to begin the meeting with a review of the previous one.

Briefly go over what was accomplished and what wasn’t, and brainstorm some ways to make the upcoming sprint more productive.

This shouldn’t be a challenge, as you’ve likely already hosted a sprint retrospective that addressed these topics.

Essentially, all you need to do is recap that meeting and emphasize the main takeaways.

One method for this is with a meeting recording tool like Otter. This resource turns voice conversations into smart notes, making it perfect for keeping track of meeting minutes.

Simply enable Otter during your sprint review or retrospective, and you’ll have the meetings fully recorded.

Then, draw up the meeting notes at the start of your sprint planning meeting, and search for keywords such as accomplishment, improve, different, etc.

The search function looks like this:

Use these meeting minutes to summarize the final meetings of your previous sprint, and you’ll have a sprint review ready-made.

If, by any chance, the transcript reveals that the previous sprint didn’t go particularly well, it’s essential to maintain a positive attitude and not dwell on the setbacks.

No matter how much the backlog grows, an optimistic approach will bring your developers’ spirits back up.

Michael Quinn, a leading UX designer, perhaps expressed the sentiment best:

Congratulate your developers on what they did accomplish, and get them excited for what’s ahead. They’re sure to remain motivated and will likely tackle the next sprint in high spirits.

Communicate new information

Once you’ve gone over the previous sprint, it’s best to convey new information about the project immediately.

Nothing is constant in software development, and stakeholders are likely to change their minds about the features. As these updates come in, ensure your team is informed.

The most effective method for communicating information is in person—which is precisely why you should bring it up during the sprint planning meeting.

Take a look at the graph below for further clarification:

Per this visual, your developers are more likely to remember what you tell them in direct, face-to-face interactions.

Once you’ve presented the new requirements or edited the design scheme (or anything else that has changed), ensure to record the latest information in the documentation.

Although face-to-face communication makes a significant impact, it’s still essential to have the knowledge noted down, just in case someone forgets.

In other words, it’s a good idea to invest in documentation software that is easy to update and edit. Atlassian’s Confluence is a popular option used by many companies worldwide.

Here’s what editing a page looks like in Confluence:

As shown above, Confluence’s main appeal is its collaborative editing feature. You and your developers can access the document simultaneously, making changes in one group effort.

This aspect is advantageous if one of your developers gains some new information.

They won’t have to wait for you to approve their edits but can directly correct the documentation themselves.

Check development team availability

After going over the latest developments, it’s time to take stock of your developers’ availability.

You might want to start distributing tasks immediately, but there’s no point in doing so without knowing your team members’ schedules.

For example, some of your developers might be on vacation, on sick leave, or working on other projects.

When these external factors occur, you’re automatically left with less time (meaning fewer resources) to complete your workload.

The easiest way to determine availability is to look at your employees’ calendars.

It’s irrelevant if you’re using Google Calendar, Office 365, or any other tool—take a peek to see what their schedule looks like.

If you’re using Google Calendars, this is particularly easy, as team members can share their calendars with specific people. Here’s how:

Once your developers have shared their calendars, it’s easy to see how much time they can devote to the sprint in the upcoming period.

However, that being said, it’s essential not to calculate their available hours as 8 hours × 5 days=40 hours per week. The equation, unfortunately, isn’t that simple.

Realistically, no one can work productively for eight hours straight.

You’ll have to include downtime, planning mistakes, and surprise developments in those eight hours, automatically bringing the number down.

For this reason, it’s a good idea to follow this guideline:

You’d have to be exceedingly optimistic to think your developers will code without bug fixes or refactoring.

By following Stefan’s guidelines, you’ll give your developers some buffer time when these surprises inevitably crop up.

Determine which product backlog items to include

With your team’s availability calculated, it’s time to decide which product backlog items to include in this sprint.

You and your developers are ultimately working toward creating a functioning product, and the product backlog serves as a list of tasks to help you accomplish that goal.

The Scrum Guide defines the product backlog as follows:

The key word here is emergent—the product backlog will always grow and will never be depleted.

That’s why choosing the items to tackle during the sprint is essential, as you can’t take on all of them.

When selecting your backlog items, try following these five steps:

Start by describing the backlog item. By illustrating what that particular item does, your team will understand the feature in full and can decide if it’s necessary to implement it.

Then, discuss the acceptance criteria—what success looks like for this item.

Ask yourselves what needs to happen for the stakeholders to consider the item finished, and you’ll have your answer.

Following this, estimate the item’s complexity. Think about how difficult it is to meet the acceptance criteria and if you have the resources to finish the item in time. Is it a realistic goal?

If it’s viable, double-check if the item can even be worked on. Does your team have enough information to start implementing it? Will anything block your work?

Finally, discuss if you have enough remaining space in the sprint. Consider how much work you’ve already allocated for it and how much you accomplished in the last sprint.

Using those benchmarks, you’ll gauge if you have room for another backlog item.

Identify the new sprint goal

Your chosen product backlog items should all lead to one overarching objective—the sprint goal.

This sprint goal defines what your team is trying to accomplish during the sprint and will give your developers direction.

To identify a sprint goal, first, determine a focus area. Ask yourselves what features are most important.

Has the company introduced new registration methods, or are you redesigning the homepage? Where have users reported the most bugs?

With these answers in mind, you’ll pin down a focus area. This is essential for a successful sprint, as the CEO of the startup Magoosh emphasizes:

With a concrete focus area, you and your developers will quickly identify your sprint goal.

It’s essential to keep in mind that you don’t decide on the sprint goal alone, despite being the team lead. Instead, it should be a team effort, with each developer giving their own opinion.

A straightforward method to achieve this is to create a poll.

Distribute a survey to your developers (make sure to include an option of other), and have everyone include their input that way.

This method is handy if you’re worried that your developers won’t be truthful or will just go along with the majority. With an anonymous poll, they’re more likely to be honest.

Here’s a poll example, courtesy of Polly:

Polly is an online tool that facilitates gathering information in the form of polls and even allows employees to rank their answers.

With this feature, you’ll have a clear, measured outlook on your employees’ priorities and can easily reach a fair consensus on the sprint goal.

Estimate user stories

Now that you have a sprint goal, you can estimate user stories. The smallest units of work in the Agile framework, user stories pave the way for completing a product backlog item.

For example, imagine choosing enable signing in with Apple as a backlog item. That concept should be retold from the perspective of an end-user, using this formula:

As a <who>, I want <what>, so that <why>

Following the previous example, possible user stories are:

• As a user, I want to sign in with Apple, so that I don’t need to create a separate account
• As a user, I want to receive a sign-in email confirmation, so that I know I have been successful

Furthermore, user stories place a specific issue at the forefront. As Agile educator Manuel Küblböck put it:

This negotiable implementation is why you’ll have to estimate each user story, as they all have varying levels of complexity.

The most widespread tactic for user story estimation is planning poker.

Each developer is handed a stack of cards with a number printed on each card, typically following the Fibonacci sequence.

Then, each developer chooses the most representative number when a user story is read out. The higher numbers indicate greater complexity and the lower less complexity.

With this tactic, you ensure the frankness of your developers. If most show the same number, that estimation is accepted.

If the rankings vary, each employee will argue their case, and the team can deliberate.

This practice was introduced for the following reason:

With planning poker, your team’s estimation process should be much faster and, more importantly, fair.

Discuss the velocity of the sprint

Having planned out your user stories, your next step is discussing the velocity of the upcoming sprint.

Velocity is one of the essential measurements in Scrum, as it counts the amount of work a team will accomplish in a sprint.

The usual equation for calculating velocity is adding the total number of story points per sprint, then dividing that number by the number of sprints.

For example, if you amassed 30 story points in the first two sprints but only 20 in the later 20, the equation would be:

30+30+20+20=100/4=25

Your team’s velocity amounts to 25.

However, this number shouldn’t be a target for your team’s performance. Consider Goodhart’s law:

Velocity depends on story point estimates. If you treat velocity as something that needs to improve, your team will intentionally give higher story points to the user stories.

All this accomplishes is that your employees assign a higher value to the workload without the inherent value changing.

Instead of forcing rises in velocity, use the metric as a benchmark for how much work your team can realistically take on.

For example, try investing in a velocity chart like the one below:

As you can see, the chart measures how much work you committed to in the previous sprints vs. how much work was actually completed.

With this visualization, you can gauge how much velocity will realistically fit into the upcoming sprint and, consequently, how many story points you’ll be able to include.

Leave time for questions

At the end of the sprint planning meeting, make sure you block out some time for questions.

It’s crucial to have a concluding period where employees can raise any concerns or voice any uncertainties they might have.

After all, most sprint planning meetings go on for over an hour, so it’s not unusual for concentration to drop.

Furthermore, sprints tend to last at least two weeks. Given this long period, you want to ensure your developers understand what they’re trying to accomplish and what the objectives are.

Hypercontext’s Director of Engineering has also highlighted this point:

It’s much preferred to clear up any misunderstandings at the beginning of the sprint instead of finding out halfway through that one developer has misunderstood the task.

While your employees are asking questions, it’s probably wise to step down and have the Product Owner take the stage.

The Product Owner’s primary goal is to represent the product and is, by default, the most knowledgeable individual about the product.

This topic was recently discussed in a Reddit thread, where a Product Owner highlighted that they were always available for questions during the sprint planning:

Although the Product Owner usually isn’t involved in the detailed software development planning, it is still essential they make an appearance to address any concerns your team members might have.

Product Owners tend to have the most communication with stakeholders, so they should be particularly adept at clarifying acceptance criteria and product requirements.

Conclusion

An agenda is a priceless asset when organizing your sprint planning meeting, as it ensures you don’t forget to address any important points.

Start the agenda with a review of the last sprint, and then communicate any new developments that occurred in the meantime.

After checking your developers’ availability, you can determine which product backlog items to include.

Next is identifying the new sprint goal, followed by estimating the user stories. With that information, you can then discuss the upcoming sprint’s velocity.

Finally, leave some time in the end for questions.

Follow this agenda, and you’re good to go—your meeting will be a resounding success.