How to Master Sprint Planning (+Template)

What Should Sprint Planning Include?

Ceremonies within a typical agile methodology cover the following:

• sprint planning
• daily scrum
• sprint review
• sprint retrospective
• backlog refinement

The York IE product strategy and development team is working in the fast-paced world of startups. Our clients are constantly launching, re-launching and tweaking their platforms based on feedback from customers.

Because of this, we’ve implemented a streamlined sprint planning process that condenses the above into three distinct ceremonies:

• sprint retrospective and planning
• backlog refinement and sizing
• daily scrum

In addition, our sprints last two weeks. Other organizations might plan for sprints of one week or one month.

The squad leader or project owner will lead each session. Most teams handle their backlog in a project management tool, such as Notion or Jira. Here’s how to plan for your upcoming sprint:

Sprint Retrospective and Planning Meeting

You’ll start each sprint with a 60-minute kickoff meeting. For reference, we can say this meeting takes place on Monday the 1st.

Let’s start with the retrospective part of the equation. Start the meeting by reviewing the last sprint. What went well? What didn’t go well? What lessons can you document for future sprints? This is your opportunity to put a critical eye on the last two weeks of work.

Then move on to the planning part of the session. This is where you and the team select backlog items for the upcoming sprint and assign them to each team member. The squad is committing to completing each of these items by sprint’s end.

Once this meeting kicks off, all of your work over the next two weeks is accounted for.

Backlog Refinement and Sizing Meeting

One week later — let’s call it Monday the 8th — you’ll have a meeting that sets you up for the upcoming sprint. The backlog refinement and sizing meeting is a look-ahead, rather than an assessment of your current sprint.

The team will refine the scope of backlog items so that everyone clearly understands what it means to be done with a particular task. You’ll rewrite these backlog items if anything has changed due to unforeseen obstacles, such as a bug that blocks progress.

Then move on to sizing, in which you identify the level of effort required to complete each item in the backlog. This may be measured in story points, or eight-hour increments of developer time. For example, a half-point item would require four hours of work from the average developer.

The goal is to achieve a pointed backlog, meaning you know what you’re trying to accomplish and how much effort it will take. While prioritization itself shouldn’t have much direct impact on backlog refinement, it is helpful to maintain at least three sprints’ worth of pointed backlog at a given time.

They’re called development cycles for a reason. The following Monday (the 15th), your team will have another planning/retrospective meeting that helps you clear the deck from the previous sprint before kicking off your next sprint.

Daily Scrum

This is the shortest of the three ceremonies, yet it occurs most frequently. As you’d likely guess, the daily scrum happens each morning for about 20 minutes. Each member will give a quick update on what they accomplished yesterday and what they’re planning to finish today. Full transparency is encouraged; it’s easier to tackle problems as they arise, as opposed to letting them fester.

Sprint Planning Meeting Agenda Examples

Once you’ve established the three sprint ceremonies, you’ll need to structure them to get optimal results.

Sprint Retrospective and Planning Meeting Agenda

Use the lessons learned from your previous sprint to help define how you’ll approach the next one:

• Pull up the previous sprint and verify the completion status of each sprint item, rolling over any unfinished items into the next sprint. (20 minutes)
• Go around the room and share what went well and what didn’t go well from the previous sprint. (20 minutes)
• Pull up groomed backlog items, assigning them to individuals for the upcoming sprint as needed to fill sprint capacity. (20 mins)

Backlog Refinement and Sizing Meeting Agenda

Remember that your goals are to define what still needs to be accomplished and determine how long that will take:

• Pull up backlog items with the status Requirement Gathering or tagged with the appropriate To Be Sized tag, previously prioritized by the product manager or squad leader. (20 minutes)
• Go through each backlog item. Rewrite them as needed so that the outcome is well understood by all relevant stakeholders, and such that it is ready to be sized. (20 minutes)
• Size each item, identifying additional refinement needed for any backlog items bigger than the sprint capacity. (20 minutes)

Daily Scrum Agenda

The daily scrum should be light, informative and fun. It’s sometimes called a daily standup because it’s meant to be quick; no need to get too comfortable! Get your team aligned for another great day of work by going around the room and sharing the following:

• What did you accomplish yesterday?
• What do you plan to accomplish today?
• Are there any blockers to achieving your objectives?

View the daily scrum as a quick checkpoint to determine if the sprint is on track. If any deep dives are needed, schedule a follow-up meeting to tackle them.

How to Master Sprint Planning

To master sprint planning, product development leaders should:

1. ensure their squad agrees on sizing methodology and expected sprint capacity;
2. factor quality assurance into sizing;
3. include a field to capture sizing for backlog items in their project management software; and
4. utilize user stories for backlog items.

1. Ensure your squad agrees on sizing methodology and expected sprint capacity.

Sprints are all about getting your product development team aligned so they can get their work done efficiently. The whole concept is based on transparency and trust, especially when it comes to sizing methodology and sprint capacity. Each team member should feel confident they can achieve what’s assigned to them throughout the sprint planning process.

There are many ways to establish sizing for each backlog item, including “planning poker.” Go around the room and have each team member give you an estimate of how long a task should take; the average will be your final number. You can also do blind submissions, or any other method that a.) lets you arrive at an average and b.) provides a little fun for the team.

2. Factor quality assurance into sizing.

Being done isn’t as simple as finishing the final line of code; you also have to make sure the feature or enhancements work in concert with the rest of the product. For each backlog item, budget a little extra time so that team members can check their work and ensure what they’ve created is useful in the context of the entire sprint.

3. Include a field to capture sizing for backlog items.

Regardless of which project management tool you use, it’s helpful to be diligent with the fields within your backlog. Particularly helpful is including your sizing. Be sure to include a Story Points field (i.e., the estimation we got from our refinement/sizing meeting). This helps increase transparency amongst the team and allows them to prioritize their time.

4. Utilize user stories for backlog items.

User stories are often helpful for adding context to your backlog items. They help you answer the question, “What does this feature accomplish?”

A user story follows this format: As a [PERSONA], I want  [FUNCTIONALITY] so that [OUTCOME].

For example, you might story point a backlog item by saying: “As a new user signing up, I want to be able to swipe my credit card to pay for the platform.” Once you’ve defined this user story, it’s easier to outline what needs to be done, such as an integration with PayPal or Stripe.

Dos and Don’ts for Sprint Planning

As you refine your sprint planning process, it’s important to remember a few best practices:

Do: Reserve sprint bandwidth for the unexpected.

Remember that your sizing requirements are estimates, not foregone conclusions. In some cases, your team might get interrupted by urgent priorities (such as a critical bug) that force you to adapt. Budget extra time to ensure your sprint won’t be completely derailed.

Don’t: Stray too far from the original plan.

There’s a difference between being flexible and being scattered. While it’s important to leave time for the unexpected, you’d like your team to stay responsible for the items they were assigned in the planning session. Otherwise, all of your planning work could be for naught.

Do: Split up work equitably.

Within each sprint, you’ll have backlog items that range widely in level of difficulty. If Team Member X has to work through a painful bug in this sprint, be sure that they’re given a slightly less frustrating workload for the next sprint. Spreading the work will reduce burnout and give each team member an opportunity to make an impact.

Don’t: Adopt a pass/fail mentality.

When we ran our first sprints with the York IE team, I expected things to be a little messy. That’s only natural. The more sprints we do, the better we define our sizing methodology and sprint capacity.

The beauty of sprint planning lies in its cyclical nature. If things go poorly, you’ve got another sprint two weeks later to get yourself on track. Missing the mark isn’t the end of the world, as long as you apply the lessons you learned the next time.

Sprint Planning Template

We’ve explored the sprint planning basics and given you some tips for how to master the sprint planning process. Now it’s time to put this agile methodology to the test!

Download our free sprint planning template to help you structure your next ceremony. With a little collaboration, trust and transparency, your development team should have a strong foundation to ship high-quality work at an efficient pace — and have some fun doing it.