Sprint planning in Scrum

At our last retrospective, the Vision Tasks team decided to restructure our sprint timetable. With our two-week sprints running from Monday to Friday, it felt disjointed holding the end of sprint review and retrospective on the Monday morning of the new sprint; sprint planning was then squeezed into a one-hour slot on Monday afternoon.

With the new timetable, the sprint review and retrospective are now held on the afternoon of the last Friday of sprint. This should help us round off the sprint nicely without the hiatus of a weekend. But it also frees up the whole day on the first Monday of sprint for planning, which is what I want to explore in this post.

Planning in two acts

During sprint planning the team is asked to answer two questions:

  • What can be delivered during this sprint?
  • How will this work be achieved?

These don’t need to be separate meetings but what is important is that both questions be answered: what then how.

In my experience, new teams often only answer the ‘what?’ They drag enough stories onto the sprint backlog to match their velocity then kick-off the sprint with no real sense if what they have committed to is achievable or not.

The ‘how?’ part takes all the Scrum values to work at and perfect: commitment, courage, focus, openness, and respect.


There are three things required going in to a sprint planning meeting

  1. a refined, prioritised backlog.
  2. an understanding of the team’s velocity, that is how many story points a team can complete in a sprint.
  3. an understanding of the team’s capacity for the next sprint, in hours.


When working out the team’s capacity for development work, each team member should take the total number of hours for the sprint (number of days × hours worked, e.g. 10 × 7 hours) minus any time spent in meetings (daily scrum, backlog refinement, sprint review, sprint retrospective and planning).

Then deduct an hour or two of ‘slack’ for each day to account for dealing with email, distractions, requests from other teams, etc.


The Scrum Guide sets aside a maximum of eight hours for a one-month sprint with a recommendation that shorter sprints are proportionally shorter. So, around four hours for a two-week sprint.

Part 1: What can be delivered during this sprint?

During the first part of the meeting, the product owner presents to the team the next-highest priority items on the backlog. Using the team’s velocity as a guide, the team estimates how much work they think they can deliver during the next sprint.

It can be helpful to keep an eye on the team’s definition of ready to determine whether stories are ready to be pulled onto a sprint, and the definition of done to be clear about what will need to be done to deliver it.

If any new information or insights have come to light, this is the last opportunity before the sprint starts to re-estimate any stories.

Part 2: How will this work be achieved?

Where I have found many teams go awry is that they have misunderstood the Agile Manifesto’s statement about “responding to change over following a plan” to mean “don’t have a plan”. It surprises them to learn that actually more planning is asked of them.

User stories, remember, are not requirements. While they represent user requirements they don’t document them. They are reminders to have conversations to figure out what needs to be done and how to do it. That conversation starts in backlog refinement and gets continued in this phase of sprint planning.

“To acquire confidence in what it can get done, many development teams break down each [user story] into a set of tasks […] The development team then provides an estimate (typically in hours) of the effort required to complete each task. Breaking product backlog items into tasks is a form of design and just-in-time planning for how to get the features done.”

— Essential Scrum by Kenneth S Rubin (Addison Wesley, 2013)

It’s up to the team how they do this but each story should be examined one by one, tasked-out and estimated in ideal hours. You may wish to break the team up to focus on particular areas of speciality, or you may wish for the whole team to discuss everything.

There are many benefits to this approach.

First is the wisdom of crowds. Because everybody is invited to contribute their experience and insights into every story, each story benefits from the input of the whole team about how that feature will be built, tested and delivered.

Newer team members get exposure to parts of the application they may not have encountered yet and can ask questions for clarity.

In thinking each story through at a deeper, more practical level, it can reveal things that had not yet been considered. There might be a realisation about the order certain stories need to be worked on. Anything useful that comes from these discussions should be recorded on the card so they are not forgotten.

Because every team member has helped think through every story, if someone unexpectedly goes off sick, other team members can step in to take up the slack more easily.

It is also easier to manage team capacity at this point than during the sprint. Once stories have been tasked-out and estimated in ideal hours the team can figure out who would be best suited for each task. The duration of those tasks then gets deducted from the team members’ capacity totals until there is assurance that everyone on the team has enough work to do during the sprint.

If there is clear shortfall or over-commitment, then the sprint backlog can be adjusted as appropriate: push items back onto the backlog or pull over more, break them down and estimate them.

At the end of this phase of the whole team should be clear about what the sprint goals are and how they will be realised.


The final ceremony during the sprint planning meeting is for the team to vote on how confident it is that it will deliver its commitment. This can be done using Planning Poker™ cards or simple finger-voting, showing one, two, three, four or five fingers depending on one’s level of confidence.

If the team are confident they can deliver everything the sprint begins. If not, they can explore why and make adjustments as appropriate.

Things will change, the team will discover things they hadn’t considered or couldn’t see at the time. Some tasks will be harder than they expected. Others will be simpler. But by taking the time to work together to plan as far as they can see, they set themselves up well for success.

Originally published on the Vision internal blog.

Published by

Gareth Saunders

I’m Gareth J M Saunders, 52 years old, 6′ 4″, father of 3 boys (including twins). Enneagram type FOUR and introvert (INFP), I am a non-stipendiary priest in the Scottish Episcopal Church, I sing with the NYCGB alumni choir, play guitar, play mahjong, write, draw and laugh… Former Scrum master at Safeguard Global, Sky and Vision/Cegedim. Former web architect and agile project manager at the University of St Andrews and previously warden at Agnes Blackadder Hall.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.