Pragmatic sprint planning agenda

Author: Alexey Krivitsky

I was recently planning a long absence at my client, so I've crafted a checklist for new facilitators of Scrum meetings.

Here's an example for Pragmatic Sprint Planning - a key Scrum meeting.

I'm assuming you're using some sort of issue tracking system, but of course the agenda has nothing to do with a specific tool, so feel free to replace "your tool" which whatever tool you have at hand.

Meeting goal:

agree on the sprint goal and scope on the level of backlog items for the upcoming sprint

Before the meeting:

agree on definition of done
if previous sprint is not closed, review all open stories and close them or move to backlog
review the sprint wall and bring all non-finished items to the meeting
print backlog items that shall fit to the next sprint with some extra ones (if you prefer an offline way of planning)

Materials you'll need:

a flip-chart sheet
big post-its
printed backlog items from 'your tool' - optional

On the meeting:

write down the Sprint name (we use the current date as a name) as a title of the flip-chart sheet
- create a new Sprint in 'your tool'
PO presents the idealistic sprint goal - write it down on a large post-it and stick to the flip-chart, so that it can be re-formulated during the meeting
review upcoming non-production activities like vacations, offsites - write them down
- make a table on a flip-chart sheet with all sprint dates and team member names
- invite everyone to mark their planned absences
- discuss if this sprint has any special events like code freeze, release, test session, etc. that can result in unplanned work - add this to the calendar
go through backlog items one by one (in 'your tool' or with printed cards), for every product backlog item repeat:
- team clarifies the item if needed
- if item is not estimated - estimate now
- team discusses if they can finish all sprint items if the current item is added to the sprint (given the definition of done)
- if everyone agrees it is realistic, add the item to the sprint and move to the next one
stop when team feels the sprint scope is not doable
review the sprint scope and see if it makes sense like it is now
- if not reiterate by swapping backlog items
- make sure all team members still find the scope realistic
double-check if the current sprint's velocity is comparable to historical velocities of past few sprints
- if not - discuss what makes the current sprint different
help PO formulate the current sprint goal based on the agreed scope - write it down
start the sprint in 'your tool'

Right after the meeting:

clean the sprint wall
print all backlog items (stories, bugs) from 'your tool' and put on the sprint wall
facilitate an activity of breaking the items down into tasks
create a sprint mail for stakeholders