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

 

Write a comment

Comments: 0