1,758 reads

Scrum Sprint Planning Checklist

by Stefan WolpersApril 5th, 2018

Too Long; Didn't Read

A sprint planning checklist? How dare you: Scrum is a mindset, not a methodology. It is a journey, not a destination. There is no one-size-fits-all-and what else could you possibly cover with a checklist, the mother of all standardized processes?

Companies Mentioned

featured image - Scrum Sprint Planning Checklist

TL;DR: Scrum Sprint Planning Checklist

Well, it always depends on the purpose of a tool’s application. Read more why scrum checklists are a handy tool if applied at an operational, hands-on level, reducing your cognitive load and freeing up time for more relevant things.

The Magic of Checklists

Some of you may be aware that checklists originate from an aviation accident. A new plane with a crew of experienced test-pilots crashed during take-off. It turned out that plane had no mechanical problems at all, the flight crew just forgot a simple step during the take-off procedure.

Probably, it was over-confidence meeting complexity, a feeling of “we know what we have to do, as we do it all the time” that led to the mistake. No matter what it was in the end, the consequence was to make checklists mandatory in aviation. Or in hospitals. Or anywhere, where the complexity of a task at hands may prove to be too high of a cognitive load to trust everything will go smoothly.

So, from my point of view, checklists are not an evil means of imposing standardized processes but a helpful tool for the practitioner even if he or she is a scrum master using a sprint planning checklist.

Agile Transition — A Manual from the Trenches

Download the latest, 212 pages strong version of “Agile Transition — A Hands-on Manual from the Trenches.”

It is available right here**,** and it is free.

Scrum Sprint Planning Checklist — The Details

This sprint planning checklist is tailored to the way my current team is working. In other words, you will likely not be able to apply this checklist to your team without modification. For example, we put a lot of effort into preparing the sprint planning during the weekly product backlog refinement sessions. (We typically plan two to three sprints.)

Practically, the sprint planning itself is a kind of confirmation of what we already decided on during last backlog refinement. We probably adjust the scope of the sprint backlog during the capacity planning. However, it rarely happens that we switch the sprint goal, for example. A typical sprint planning #1 hence takes only between 30 and 60 minutes.

Therefore, if you are working more traditionally, the following sprint planning checklist will lack some steps.

Regarding the following timeline, T=0 refers to the start-date of the upcoming sprint, and T-1 is the day before the start of this sprint. Moreover, T+1 is the day after the sprint planning.

The Sprint Planning Checklist with a Timeline

Preparing the Sprint Planning:

☐ T-2: Address the number of open tickets in the code review & ready for acceptance columns. Ask the team members to focus on moving tickets to done before starting work on new tickets.
☐ T-1: Ask the team members to update the boards.
☐ T-1: Run the sprint review.
☐ T-1: Run the sprint retrospective.

If you enjoyed the article, do me a favor and smack the 👏👏 👏 up to 50 times — your support means the world to me!

If you prefer a notification by email, please sign-up for my weekly newsletter and join 15,952 peers.

During the Sprint Planning:

☐ T=0: Kick-off the sprint planning by sharing a Zoom session for those team members who cannot participate in the sprint planning in person.
☐ T=0: Are all team members present to run the sprint planning? (The absence of the product owner might be a challenge.)
☐ T=0: Clean up the old board(s) with the whole team by checking statuses of each ticket and moving tickets if necessary. Sync the offline boards with the Jira board. (A questions to answer in advance: which board is the leading one? If some team members work remotely during sprint planning, choose the online board.)
☐ T=0: Discuss possible spill-overs: Are those still valuable to be continued? (Spill-overs are a suitable team metric and a good topic for a retrospective. If spill-overs persist over several sprints this could trigger various discussions, for example:☐ Is the sizing of a user story or ticket right?☐ Is the quality of user stories or tickets matching the definition of ready?☐ Would Kanban be better suitable for the team?☐ If user stories or tickets that are not yet done shall not spill-over to the upcoming sprint move them to the product backlog or delete/archive them.
☐ T=0: If not yet available, create a new “sprint” in the team’s online tool, for example, Jira.
☐ T=0: Close the previous sprint:☐ Did we meet the sprint goal?☐ If you use an online tool, make sure that you move all tasks that spill-over into the right buckets, for example, the upcoming sprint or the product backlog.☐ Clear the physical boards off old stickies of the previous sprint.
☐ T=0: Kick-off the next sprint planning:☐ Figure out the available sprint capacity of the team: who can contribute work over the course of the next sprint?☐ Ask the product owner to define the sprint goal.☐ Match capacity with the sprint goal of the product owner: Is this realistic?☐ If the sprint goal and team capacity do not match, try to strip down the scope of the sprint: Can the team deliver a smaller version of the sprint goal?☐ If the team cannot deliver the proposed sprint goal, ask the product owner to come up with a realistic sprint goal.☐ Let the team pick the user stories, and other tasks are needed to meet the sprint goal.☐ Ask the team whether all user stories and other tasks needed to meet the sprint goal meet the team’s definition of ready. (If this is not the case, make sure the issue is addressed, and the team agrees how to deal with the issue collaboratively.)☐ Ask the team whether the scope of work leaves slack time to address unexpected issues.☐ Ask the team whether the scope of work provides the capacity to tackle technical debt as well as bugs to keep technical debt at bay.☐ Create stickies with user stories and tasks for the physical boards. (Make sure that the color codes for the different types of stickies are followed; spikes, user stories, technical task, sub-tasks, and bug all have distinctly different colors.)
☐ T=0: Run an anonymous sprint survey regarding the previous sprint.
☐ T=0: Summarize the results from the retrospective and update the board with the action items.
☐ T=0: Summarize the results of the sprint review.

After the Sprint Planning:

☐ T+1: Sync the offline board(s) with the online board.
☐ T+1: Probably, start collecting data for the upcoming retrospective, for example, by putting up a sprint mailbox.
☐ T+2: Kindly remind the team members to participate in the outstanding sprint survey. The recommended minimum number of participants is eight.
☐ T+3: Publish the results of the sprint survey of the previous sprint.

Scrum Sprint Planning Checklist — The Conclusion

Checklists serve both the junior practitioner — what do I have to do — as well as the experienced agile practitioner to deal with the complexity at hands. Checklists like this example of a sprint planning checklist are by no means a violation of the agile manifesto but lessen the cognitive load of running ceremonies and practices.

Think of scrum checklists as work in progress that needs to be revisited and adjusted regularly. In that respect, scrum checklists are not much different from, for example, working agreements or a definition of done.

Are you using checklists in your daily work as a scrum master or agile coach? Please share with us in the comments.

✋ Do Not Miss Out: Join the 2,900-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.