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
Write a comment