TL; DR: Scrum Sprint Planning Checklist
A Sprint Planning checklist? How dare you: Agile is a mindset, not a methodology. It is a journey, not a destination. There is no one-size-fits-all approach, and what else could you possibly cover with a checklist, the mother of all standardized processes?
Well, it always depends on the purpose of a tool’s application. Read more about why Scrum checklists are a handy tool if applied at an operational, hands-on level, reduce your cognitive load, and free up time for more relevant things.
🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.
The Magic of Checklists
Some of you may be aware that checklists originate from an aviation accident. A new plane with a crew of most experienced test-pilots crashed during take-off. It turned out that the plane had no mechanical problems at all, the flight crew just forgot a simple step during the take-off procedure.
It was probably 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 hand may prove to be too high of a cognitive load to trust everything will go smoothly.
So, from my perspective, checklists are not an evil means of imposing standardized processes but a helpful tool for practitioners even if they are a Scrum Master using a Sprint Planning checklist.
Also, checklists do not make you stupid. (My reading tip: The Checklist Manifesto: How to Get Things Right.)
Cannot see the form?
Please click here.
Scrum Sprint Planning Checklist – The Details
This Sprint Planning checklist is modeled after a former Scrum Team of a large multi-national, traditional utility company at the beginning of its Scrum journey. In other words, you will not be able to apply this checklist to your Scrum Team without inspection and adaptation. For example, they put a lot of effort into preparing the Sprint Planning during the frequent Product Backlog refinement sessions. (They continuously planned the next two Sprints during the refinement sessions.)
Practically, the Sprint Planning itself was most often a confirmation of what they already agreed on during the Product Backlog refinement. They probably adjust the scope of the planned Sprint during capacity planning. However, it rarely happened that they replaced the previously anticipated Sprint Goal for a completely different goal. A typical Sprint Planning hence took only between one or two hours.
The Scrum Team in question was rather large—eight developers—, mostly co-located with two or three team members joining remotely. It used Atlassian tools (Jira, Confluence) and had full control over its build-pipeline. Generally, the stakeholders had a significant influence on where the Scrum Team was heading, impeding the team on more than one occasion in the process. The work of the Scrum Master was hence more of a tactical or operational nature at the shop-floor.
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. Consequently, T+1 is the day after the Sprint Planning.
The following Sprint Planning checklist includes tasks for everyone on the Scrum Team:
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 Sprint boards. (There were both a physical and an online Sprint board that needed to be synced.)
- T-1: Run the Sprint Review. (Ask: Did we meet the Sprint Goal, and are we still on track to meet the product goal with the upcoming Sprint?)
- T-1: Run the Sprint Retrospective. (Pick continuous improvement action items for the upcoming Sprint.)
- T-1: Remind all team members of tomorrow’s Sprint Planning.
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: Cleaning up the old board(s) with the whole Scrum Team by walking the board and checking each ticket’s status, and moving tickets if necessary. Sync the offline board with the Jira board. (The team always struggled with answering a simple question: Which board is the leading one? Given the remote team members, it should have been the Jira board.)
- T=0: Discuss the possible spill-over: Are those unfinished Product Backlog items still valuable? (Spill-overs are a suitable team metric and a good topic for a Retrospective. If spill-overs persist over several Sprints, this should trigger various discussions in the team, for example:
- Is the sizing of the Product Backlog items right?
- Is the refinement of the Product Backlog items adequate? Do we as a team have a shared understanding of the why, what, and how?
- And ultimately: Would Kanban be better suitable for the team?
- T=0: If undone Product Backlog items shall not spill-over to the upcoming Sprint, then move them to the Product Backlog or delete/archive them.
- T=0: If not yet available, create a new “Sprint” in Jira.
- T=0: Close the previous Sprint:
- Move all Product Backlog items that will spill-over into the right buckets, for example, the upcoming Sprint or the Product Backlog.
- Clear the physical board off old stickies of the previous Sprint.
- T=0: Kick-off the next Sprint Planning:
- As the Scrum Team, figure out the available team capacity: Who can contribute work throughout the next Sprint?
- Ask the Product Owner to share the business objective the upcoming Sprint shall accomplish.
- Match the Scrum Team’s capacity with the business objective of the Product Owner: Is this realistic?
- If the business objective and team capacity do not match, try to strip down the Sprint scope.
- If the team cannot deliver the proposed business objective, ask the Product Owner to come up with a realistic goal.
- Collaboratively, create a Sprint Goal.
- The Development Team picks the Product Backlog items needed to meet the Sprint Goal.
- 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 and bugs. (Avoid the 95-plus percent utilization trap. Don’t become a feature factory at the expense of the quality of the tech stack.)
- The Scrum team creates stickies for the physical board. (Ensure that the color codes for the different types of stickies are followed; spikes, user stories, technical tasks, sub-tasks, and bug all have distinctly different colors.)
- T=0: Run an anonymous Sprint survey regarding the previous Sprint. (The Sprint survey covered four questions: 1. Did we deliver value to our customers during the recent Sprint? 2. Has the level of technical debt changed during the last Sprint? 3. Would you recommend a job opening at this organization to a good friend with an agile mindset? 4. How are you personally feeling about your job situation?)
- T=0: Summarize the results from the previous Sprint Retrospective and update the new Sprint board with the action items. (The Scrum Team communicated their Retrospective results openly.)
After the Sprint Planning:
- T=+1: Sync the offline board with the online board. (The team had a hard time dealing with administrative tasks. Moreover, misunderstanding the role of the Scrum Master, the syncing of the boards was often regarded to be a Scrum Master task.)
- T=+1: Start collecting data for the upcoming Sprint Retrospective, for example, by putting up a Sprint mailbox.
- T=+2: Kindly remind the team members to participate in the outstanding Sprint survey. (The minimum number of participants was eight out of eight developers plus two business analysts, the Product Owner, and the Scrum Master.)
- T=+3: Publish the results of the Sprint survey of the previous Sprint.
Scrum Sprint Planning Checklist — The Conclusion
Scrum event checklists can serve both the junior practitioner—what do I have to do—and the experienced agile practitioner to deal with the complexity at hand. Checklists like this example of a Sprint Planning checklist are by no means a violation of the agile mindset but lessen the cognitive load of running events and practices, thus avoiding unnecessary issues with the rest of the organization.
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? Please share it with us in the comments.
✋ Do Not Miss Out: Join the 8,500-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.
If you like to join now, all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📖 Sprint Planning Checklist — Related Articles
28 Product Backlog and Refinement Anti-Patterns
Scrum: 19 Sprint Planning Anti-Patterns.
Hiring: 47 Scrum Master Interview Questions To Avoid Agile Imposters
Download the ’Scrum Anti-Patterns Guide’ for Free
Download the ‘Remote Agile Guide’ for Free
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
My team members (me included) often forget agreements happened on the fly or in a verbal way. One good example: “Oh snap, we should do a resource check next time as xy test environment is not configured the way we need it. ” We missed this check like 3 times. So we created a planning checklist where we examine PBIs and figure out specific to-dos for them.
We have more “team specific” activities like this for each and every scrum event, so we have checklists for all of them. These are maintained by the team of course.
It depends 😉
Checklists can be good and bad.
When used by management as a way to command and control they are bad in my experience.
When the team starts a checklist as not to forget things and let it grow organically,
– adding new things that were forgotten once
– more important, removing steps that are no longer relevant
then it can be a powerful tool.
There is also a dark side to checklists.
I’ve noticed that it can become a mechanical process that prevents innovation.
Sometimes forgetting something and in stead doing something different can be an eye opener that you wouldn’t have when just going trough the motions.
So, yes, checklists can be a good thing, but handle with care 😉
my 2 cents
The sprint survey is an anonymous poll, comprising of four (NPS-style) questions:
1. What value did we deliver to customers the last sprint? (0 to 10.)
2. What is the current level of technical debt? (0 to 10.)
3. Would you recommend [your organization] as an employer/client to a friend with an agile mindset? (0 to 10.)
4. How happy are you personally with your situation? (0 to 10.)
Hi Stefan,
Great article. I totally agree that usage of checklists definitely enhance the process and we can, off course, be agile there too by regularly updating the checklist as and whenever we learn and retrospect by working with a team.
Towards the end of the article, you’ve mentioned about ‘Sprint survey’. I have never been introduced to this concept. Could you please brief me about what it is?
Thanks!