3 min read

Effective Sprint Planning Sessions make for a successful sprint.

Sprint planning sessions are probably one of my favourite agile rituals, and running a great one can set the scene for sprints to come. It gives the team an opportunity to be ambitious, while also allowing us to reflect on recent experiences to ensure the team is on the right path.
“That absolute alignment of purpose and trust is something that creates greatness.”

― Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time

In my opinion, a lot of the work to be done to facilitate a great sprint planning session lies in the prep you do prior to the meeting. There are a few actions you can take before and during the session that can have a drastic impact on how successful sprint planning can be.

Below I've outlined three tips I stick to when I facilitate my sprint planning sessions. My process is no way perfect, but I've been doing them for a few years now and this is what's working for me and the teams I've been a part of. If you have any tips for me, let me know on twitter!


Think about what your sprint goal could be during Backlog Refinement Sessions

Having a groomed and refined backlog for upcoming work is obviously quite key, however, it's worth keeping in mind that a lean product roadmap using a "Just Enough" product strategy, following a "north star" with a mission statement, clearly outlined problem and/or using goal setting frameworks like OKRs, is a sound approach.

Outlining a high level solution for your next initiative by identifying the earliest points you can deliver value to customers typically means that the team has some clear epics they can refine.
Allowing the team to dive into more of the nitty gritty solution an epic at a time naturally builds up your backlog, and as long as you're refining two or three epics ahead of your current sprint you'll have plenty of goals to achieve without the drag of months of planned work. This fosters opportunity to pivot away from the current approach to a new one if feedback from customers leads you to that conclusion.

Over the past twelve months or so I've moved away from booking scheduled refinement sessions, instead opting for ad-hoc sessions. This flexibility means these meetings are much more meaningful, since solutioning has come far enough along to actually book the session in the first place. These sessions are also a great place to start thinking about what our sprint goal could be for the piece of work we're refining.

Reflect on the previous sprint goal during retrospectives

My second tip might be an obvious point if you've been a part of an agile team for a while, but Agile retrospectives are an important tool in identifying productive action items in improving overall team health, and are also a great place to really question how previous sprint goals went.

I've noticed some teams can fall into the trap of just discussing the general "ways of working" of the team during retrospectives, which can be great from time to time and should be visited, but most retrospectives in my opinion should be about how successful the past sprint has been. Did the team achieve the goal they set out to hit? If they didn't, what were the blockers? Can we remove them?

Having the team members each rate the success of the sprint goal on a sliding scale can be a great indicator of team synergy, as well as getting an idea how everyone felt the past sprint. Tracking this over time is a great way to gauge improvement as well.

An example of rating the sprint on a sliding scale.

The team sets the sprint goal

This can be an easy thing to forget, especially for new product teams, but in scrum we ask the team to set a goal for the sprint. Ultimately the team know how much they can get done in any period of time, and leading the team to set a great sprint goal empowers them to stay focused and see value and purpose in what they're working on and towards, which will ensure the teams successful sprint.

Where a great product manager can step in is the guidance towards that great sprint goal. Instead of having unclear and uninspiring sprint goals like "Fix 5 bugs" or "Update user documentation", lead them towards an improved vision in what they're hoping to achieve.

This great post by Robert Galen suggests imagining you're going to invite the entire company to your sprint review, and you're going to send an email invite out. What would the headline of your email be? That's a great indicator of what your sprint goal should be. Or at least inspiration to lead you to set a great goal.