How I run SAFe Sprint Planning

What 3 years of experience has lead me too — it is best to be prepared.

First though

I want to preface this with, the way you do sprint planning should match the people in the team. This means there is no perfect way for every group. This is what I find works.

For some teams, I have been more number focused. For others, less.

Also, my context lately is purely in SAFe. I don’t love SAFe as you may see below but this seems to be the way Enterprises are going:

What is the point?

  • To plan what work we will do as a team
  • To be able to update other teams after on dependencies
  • To look forward and spot challenges

Actions before sprint planning

It is best to be prepared. Reproductive Health Supplies Coalition

The worst thing in sprint planning is the team sat watching someone click around a computer.

Respect your team’s time, every minute should be useful. To save time in sprint planning:

  • All stories should be signed off that are in ready for sign off
  • The team should know and tell of their holiday plans
  • The next sprint should be prepared that roughly fits the estimated capacity you got from PI Planning
  • Each story should have a ‘Must’, ‘Should’ and ‘Could’ label on it, to help with priority order when planning
  • The stories should be in an order that reflects priority and possibility to build
  • All stories estimated to go in the next sprint should ideally be groomed (if not more) and when grooming discuss the ability to split the story scope if possible/required (I promise this is helpful when in sprint planning as smaller stories can fit better).
  • All documents used in planning should be easily accessible — holiday trackers, PI Planning goals and outputs, major EPICs to be worked on.

When ready let’s start sprint planning.

Open the current sprint:

Open the current sprint and ask each developer how many points are left in each story.

  • They needn’t explain why, as that should have been discussed in the retro (see appendix below).

On the jira tickets mark the stories with a ‘Carried’ label.

  • This helps you identify them in the next sprint and hence focus on the most urgent stories.

Once completed, we may close the sprint.

  • When closing we can place the stories not completed in the next sprint that we will start — there is an easy option if you use JIRA.

Review the goals

We should review the goals progress as a reminder to the team on what is important — using what we did in PI Planning.

This is an opportunity for risks and actions to be thought about. It is amazing how after a sprint, you point back to what we want to achieve by the end of the increment and then suddenly something comes apparent that we need to be able to do that!

Who is in the next sprint?

Create an estimate for the next sprint’s capacity of points using a calculator or through discussing last few sprints committed and actual, with the time off in those sprints.

  • Some teams prefer to estimate than be told, some teams prefer to get a calculator to do the aths than them guess. Do whatever the team prefers.

Record these estimated values for your next sprint planning. It is useful for saying “last time we estimated X and now [more people are on holiday / fewer days working / etc]”.

Now look ahead:

Look at the next prepared sprint:

Ungroomed stories?

Are all stories refined, ready for dev and estimated?

  • If not, you should have
  • Do this now, preferably always starting at the EPIC level to help understanding and wider context and then drill into the individual stories you need to get estimates for

When estimating, I suggest to use Planning Poker.

Now let’s start planning

How do the total story points inside this sprint compare to what the team wants to aim for?

If too little:

  • Look at your backlog and move in stories associated with the goals (should be marked with ‘Must’)

If too many:

  • Can any stories be split into two by breaking down scope?
  • Are all stories absolutely mandatory for the goals or release?
  • The least urgent stories/features should be removed. These should be marked with ‘Could’ or ‘Should’

Is there enough work for *all* your team?

If not, commit to some stories but accept that you will start other stories and they will not be finished. We are able to have stories being finished outside the sprint!

Note: Make it clear and obvious about what features should be picked up when the committed stories are all taken and nothing else can be assisted with — we usually put this on the top of the next sprint/backlog.

How happy and confident is the team with all this?

Once happy with points and work in the sprint, we must ask our teams to provide a confidence level for completing only the committed-to stories.

Are they overwhelmed? Do they think they will be able to finish more? Is there something else coming that we haven’t captured in our plan of the next two weeks?

  • The confidence vote should be blind voting so no one can influence others.
  • We usually use confidence votes of 0–5 , 5 being “This sprint’s committed stories will easily be completed”
  • This should encourage discussion and again raise any risks and actions that should be also aimed at.

Thank the team!

This shouldn’t need reminding. It can be a long meeting!

Oh and finally, have your first standup of the sprint!


  • All stories in ready for sign off should be signed off before sprint planning starts, even if that means delaying sprint planning couple of minutes. Everyone would prefer to see a slight delay while you speak to one person, rather than sit and watch you. Also this helps provide stable velocity and prioritise getting stories to users.
  • The Sprint Retro should happen before the sprint planning, and it has been noticed that discussion is more actionable and progressive when they are in separate sessions. However, within Retro it can be useful to go through the current sprint and discuss the stories. We must do whatever works best for the teams.

Do you have any tips that you want to share?

This is by no means perfect or complete. But it is a start. What should I add?

Founder of and Product Owner @ dunnhumby; just genuinely interested in a lot of things. Built racecars, built electronics, now building software

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store