Help Card - Sprint Planning

About Sprint Planning

Every sprint begins with sprint planning. In this meeting we take the highest priority stories from the product backlog, discuss them, estimate the effort required to complete them and place them in the sprint backlog. We continue this until the delivery team is happy that the sprint is full (and they mustn’t be pressured to accept more).

This meeting is about open communication. Regardless of the skills and experience of the individuals, all input is valuable. This is a team effort, no egos allowed.

The planning meeting is timeboxed to 8 hours. However, most of the time we’ll be managing projects with a distributed team, travelling to the client site for planning and we’ll need to fit the sprint review into the same day. Occasionally we need to flex our timeboxes so that we can do as much in person as possible.

Who’s Involved

This is a mandatory meeting for the delivery team, the delivery manager and the product owner. Additionally certain subject matter experts from the client or 3rd parties may need to attend all or part of the meeting.

Delivery Team Discusses the user stories in detail, agrees approach to each story, estimates the effort required.

Delivery Manager Runs the meeting, keeps the agenda, focus on objectives.

Product Owner Explains the objectives for the meeting. Supports the delivery team.

Before the Meeting

Sprint planning is an intense day so it’s important to prepare properly.

Backlog scouted

  • The PO has confirmed the priorities

  • The stories have been defined well, functional requirements and acceptance criteria are recorded

  • The lead developer has checked the stories for accuracy

Equipment you might need

  • Whiteboard

  • Post-its

  • Projector/big screen (and leads)

Meeting invite

  • Invites issued and attendees confirmed

Confirm team

  • Availability of all team members checked (holiday, sick leave checked)

Sprint Summary Report

  • You have created a sprint summary report using the template, you’ve added the project goals and basic project details and you’ve added this to your project repository: Convivio > Clients > Active Clients > Client Name |

You’ll complete the rest of the details during the sprint review.

Risk Register

  • You have created a risk register using the template and you’ve added this to the project repository:

    Convivio > Clients > Active Clients > Client Name


There are two artefacts that sprint planning will produce:

Sprint Goal

  • a brief explanation of what the sprint should produce

Sprint Backlog

  • a list of user stories and tasks that will achieve the sprint goal



(5 minutes)

Opening Start the meeting on time.

Open the meeting, make any introductions necessary.

Summarise the previous sprint, any achievements and details of risks or issues we’re carrying. Keep it relaxed but professional. Lead the meeting, don’t allow others to take over.

Sprint Velocity Explain how many story points we completed in the previous sprint and how this fits into our average for the programme to date.

This is sprint x of y. It’s good to know how far we’ve progressed because this can affect the decisions that the team needs to make. If this is an early sprint then the team will have to go with gut feel.

Previous Retrospective Actions Cover any actions from the previous sprint retrospective to make sure the improvements are implemented.

Handover to PO

(5 minutes)

Hand over to the Product Owner, asking them to explain the scope and purpose of this sprint and how it fits in with the overall programme. Is there a particular theme that the stories will follow? Are there any changes to the programme that will affect our work?

Don’t allow the PO to take over at this point. You need to keep control of the meeting.

Build the sprint backlog

  1. Select the highest priority user story from the product backlog

  2. Read the user story to the team

  3. The PO explains the definition of done for the story

  4. Allow the team time to discuss the story and to ask questions to turn the story into a list of tasks

  5. Do you need to update the story with anything that’s been discussed or agreed?

  6. Are there any risks or dependencies to consider?

  7. Check that the team is ready to estimate

  8. Estimate the user story and update the story

  9. Move the user story into the sprint backlog

  10. If the team is happy that there is more room left in the backlog then select another story. If not, close the sprint backlog and end the session

Closing the meeting

The session is completed when:

  1. The team have confirmed that the backlog is full

  2. The team have added tasks to each of the stories (where necessary)

  3. All stories have been estimated

  4. The Product Owner is happy that the contents (the selection, not the quantity) of the backlog will satisfy the sprint goals

  5. The stories and tasks have been recorded in our management tool

Summarise the sprint

It’s good to finish by summarising the sprint goals and perhaps picking out a couple of key stories to illustrate the bulk of the work.

If any risks have been identified then be sure to have captured them in the risk register, assigned responsibility and agreed the next step to manage them.

Ask if there are any further questions.

Thank everyone and wish them well for the sprint.

Confirm the next meetings, including the time and location for the next daily standup.


We are not machines

Sprint planning is intensive. Expect people to be able to properly concentrate for no more than 60 minutes. Suggest regular breaks for drinks, snacks, lunch and fresh air. Encourage the team to call for breaks when they need them too.

Common Issues

You’re likely to encounter some tough questions from time to time. Luckily, we’ve all encountered them. There is a separate helpcard for Common Issues.

Last updated