How to run… Sprint Planning

Today we tackle how to run the Sprint Planning meeting. It’s a tough cookie to get right; but this article should help get you started on the path to success.

Key Facts

  • Up to 4 hours (for a 2 week sprint)
  • Usually held directly after Sprint Review (so that valuable feedback from that meeting can help inform the plan)
  • Required attendees: The whole development team, Scrum Master and Product Owner
  • Optional attendees: Anyone that can help with your plan
  • The whole team collaborates to define a Sprint Goal; the outcome that your investment in this sprint is expected to achieve
  • Come armed with recent team velocity data; you’ll need it to help decide how much work to bring into the next sprint
  • Calculate your team’s capacity i.e. how many people are around this sprint, is anyone on holiday, are there any public holidays, do you have other commitments this sprint which will take time away from sprint work?
  • Items are selected from the product backlog and added to the sprint backlog by the development team
  • The development team decide how much work they feel they can achieve in the sprint; they are not dictated how much work to bring in by anyone.
  • Usually split into two parts; part one is deciding what product backlog items to tackle, part two is deciding how to tackle those product backlog items.
  • At the end of this meeting, you should have a sprint goal and a sprint backlog (a plan on how you are going to achieve it)

The Sprint Goal ๐Ÿฅ…

The very first thing you should do in Sprint Planning is to collaborate as a team on a sprint goal, something that guides the team’s decisions throughout the planning session and the actual sprint, to arrive at the desired outcome.

There should be only one sprint goal, not many. What’s the most valuable thing you need to do right now?

The Product Owner will be of great help here, and can help explain to the team the current state of the product, the market it’s in, and what we think we can target next (some of this will have been covered in Sprint Review already; but it doesn’t hurt to repeat the highlights to the team).

Sprint Goal: The “why” behind the backlog items we select

A sprint goal should be SMART:

  • Specific
  • Measurable
  • Attainable
  • Relevant
  • Time-bound

It should bring cohesiveness to the sprint, it’s the overarching goal of what we are trying to achieve. You could replan every single item in the sprint and still achieve the same sprint goal. The sprint goal should either reduce the risk of something, help to understand something, or validate one of our assumptions.

Example Sprint Goal

Understand how users cast content to their speakers at home

This sprint goal works because it targets something specific. At the end of the sprint we should have a better understanding of what the users are trying to achieve; it’s possible; related to our product and we have a 2 week (one sprint) timeframe to do it in.

In our next sprint review meeting, we’ll discuss how we tried to meet that sprint goal; what we did, what failed, what we learned and what we are planning on doing next. We’ll discuss how we are going to tackle users casting content.

Still struggling with a Sprint Goal?

Try imagining this… If your entire product backlog went up in flames ๐Ÿ”ฅ, what would you build next? Where would you start?

How to calculate your team capacity

This part doesn’t have to be complicated, a lot of the benefit of doing this is realised just by having each person think about when they are around this sprint.

  1. Define start and end dates of sprint
  2. Ask if anyone is on holiday
  3. Check for public holidays
  4. Total up number of days the whole team is available
  5. This is your capacity for the sprint
NameDays available in sprintNotes
David91 day holiday
Brian55 days holiday
Total Capacity (days)54 (/60)
Example of a sprint capacity table

Using the team capacity data, you can compare against the velocity / team capacity data from previous sprints to help guide you on how much work you think you can bring into the sprint you are currently planning.


Before starting sprint planning, it’s really important that your backlog is in a good state, so make sure you’ve refined your backlog with enough ready items so that you don’t have an impediment for the sprint as soon as you start. The purpose of backlog refinement is to make sure we have enough ready backlog items to start the next sprint.

Assuming you have a great product backlog, read on…

Part 1: What are we going to work on?

  • Craft the sprint goal together. Ideally the Product Owner has an idea of what the target is, but decide as a team what the sprint goal is
  • Calculate your team capacity
  • Select items from the product backlog that match the capacity of your team. They should all be near the top, but you might find something related further down the backlog, or in your bug tracking tool.
  • Make sure each item is well understood and that the estimates reflect the work left to complete. Make sure each backlog item satisfies your teams definition of ready.
  • The Product Owner should be present and can help clarify any remaining points. There shouldn’t really be any major surprises at this point.
  • At the end of part 1; you should have a list of stories that will accomplish the sprint goal

Example sprint backlog

Imagine that your team’s average velocity is 20 points per sprint; and that your team is at full capacity. You decide to commit to up to 20 story points this sprint.

Product Backlog Item 12 points
Product Backlog Item 25 points
Product Backlog Item 33 points
Product Backlog Item 43 points
Product Backlog Item 52 points
Product Backlog Item 65 points
Total Commitment20 points
Sprint backlog with estimates

Should you re-estimate work?

In order to respect the scrum pillar of transparency, all items on the product backlog should have up to date estimates so that we can make an informed decision on what to work on next. When a sprint ends, all unfinished work gets returned to the product backlog and should therefore be re-estimated at that point.

If you are starting a sprint, and unfinished product backlog items are not re-estimated, you are violating the scrum pillar of transparency, as some team members have more information than others.

During Sprint Planning, if we notice something hasn’t been re-estimated yet; then it should be updated before we decide to bring it into sprint; it’s new estimate may affect whether it comes into sprint or not. Remember, estimates can go up as well as down…

Part 2: How are we going to do it?

You don’t necessarily need the Product Owner for this part, but it really helps if they are available to answer any immediate questions.

In part 2, the development team decide how they are going to tackle each item on the proposed sprint backlog (the items being brought into this sprint). My teams usually sub-task each backlog item into small chunks before they get started. Not only does this help them understand all the tasks that need to happen, and when they need to happen, it also helps them realise if they have made a mistake in their initial estimates. If an estimate needs tweaking, the team agree whether or not to still pursue the item in the current sprint (including the Product Owner in that decision).

At the end of part 2; the team understands the sprint goal (what we are trying to achieve) and the sprint backlog (how we are going to achieve the goal).

At this stage, we are ready to start the sprint.

5 tips for a great Sprint Planning meeting

1. Always start with the Sprint Goal โœ…

I mean, it’s kind of obvious right, but if you start with the outcome you want to achieve, you are more likely to select the product backlog items that achieve that goal.

It’s also important to have only one sprint goal. In my time as Scrum Master I’ve seen sprint goals that are essentially a list of items to complete. You can do better.

2. Don’t forget any planned absence ๐Ÿ“†

Fairly recently, in one of my team planning sessions, we forgot to check for planned absence. The whole sprint was planned, and although it was possible, it relied heavily on one person getting everything right and done on time. The next day, that person remembered they were on holiday for half the sprint, so we had to replan.

Save yourself the time, and check your team capacity before you get started!

3. Review historical performance data ๐Ÿ“Š

The best way of figuring out how much work you think you can do, is to look at your most recent sprint. But, I tend to look back about 7 sprints, and average out the velocity of the team. The reason for this is that sometimes something else stops your progress, sometimes you have a clear run, sometimes people are off sick inadvertently, or on holiday etc… Looking back 7 sprints, allows you to average out your team velocity. Of course, this only really works if your team has stayed roughly the same for 7 sprints as well.

4. Check everyone is comfortable with the plan before starting the sprint ๐Ÿ‘

I’ve been in scenarios where a senior stakeholder, or someone’s boss is present at the planning session, and the team has felt compelled to commit to what they are expected to complete.

As a development team member reading this, save yourself the pain, only commit to completing the work you think you can achieve. If you run out of work, you can always find more backlog items to bring in.

As a scrum master, do everything you can to ensure the team is happy with the plan before you start the sprint. You are living the values of scrum by doing this; particularly commitment.

5. Leave some space ๐Ÿš€

You don’t have to fill every sprint to the brim, leave some space for unknown things. If you run out of work, you can always regroup and decide what’s most important to tackle next.

For example, if your team velocity is 20, but you only need to take in 15 points of backlog work to achieve the sprint goal, then that’s ok. In my experience, you’ll likely gain new knowledge during the sprint that will generate more backlog items anyway.

Remember, we are measuring outcomes, not output.


I hope you’ve found this article interesting, and that it helps you in how to run a sprint planning meeting next time.

Personally, as a Scrum Master, I’ve struggled getting sprint planning right; it relies so much on others in your team knowing how to break items down into tasks. Trust your team, they know how to do this.

Use your next sprint retrospective meeting to reflect as a team on how your last sprint planning meeting went .

Remember, the ultimate goal of the sprint planning meeting, is to come up with a good plan. Plans can change though, so it’s important that your sprint goal is front and centre of all your planning activities.

I hope this helped you! If you feel like it could help someone else, please share this article with them, and feel free to add any comments below.

Till next time!

Stephen Waring
Stephen Waring

I’m an enthusiastic and energetic Scrum Master who loves everything about Agile!