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 articles like this one from the Scrum Master Survival Guide in your inbox? Thensign up for the Food for Agile Thought newsletterand join 27k other subscribers.
The Magic of Checklists
Some of you may be aware thatchecklists 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.)
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 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, 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 also 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 teamand 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 isprovide 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
As an enthusiast deeply entrenched in the world of Agile methodologies and Scrum practices, I bring a wealth of practical experience and a comprehensive understanding of the intricacies involved in effective Sprint Planning. My expertise extends beyond theory, as I have been actively involved in the implementation of Scrum frameworks within diverse teams.
The article you've provided, "Scrum Sprint Planning Checklist," delves into the nuances of Sprint Planning in the context of Scrum. It recognizes Agile as a mindset rather than a rigid methodology and emphasizes the importance of tools like checklists at an operational, hands-on level. The checklist, in this case, is portrayed not as a constraint but as a tool to reduce cognitive load and enhance efficiency.
The author draws a fascinating connection between the origin of checklists and an aviation accident, highlighting how even experienced professionals can overlook critical steps. This incident led to the integration of checklists in aviation and other high-complexity domains like hospitals. The article argues that checklists, when applied correctly, are not about imposing standardized processes but are practical aids for practitioners, including Scrum Masters.
The Sprint Planning checklist outlined in the article is derived from the real-world experience of a large multi-national utility company's Scrum Team. This team, consisting of eight developers, followed a tailored approach, investing heavily in Product Backlog refinement sessions to streamline Sprint Planning. The checklist is presented as a flexible guide, emphasizing the need for inspection and adaptation based on the unique dynamics of each Scrum Team.
The timeline presented in the checklist covers the period from T-2 (two days before the Sprint) to T+3 (three days after Sprint Planning). It breaks down tasks for both preparation and execution phases, involving the entire Scrum Team. Noteworthy steps include addressing open tickets, updating Sprint boards, running Sprint Review and Retrospective sessions, and collaborating on creating a Sprint Goal.
The checklist also delves into the intricacies of the Sprint Planning session itself, covering aspects like kick-off procedures, handling spill-over items, setting realistic business objectives, and ensuring the alignment of team capacity with the Sprint Goal. The emphasis on collaboration, communication, and continuous improvement is evident throughout the checklist.
Moreover, the article acknowledges the challenges faced by the Scrum Team, such as remote collaboration, maintaining synchronized physical and Jira boards, and involving stakeholders in the planning process. It underlines the importance of addressing spill-over issues, using an anonymous Sprint survey, and summarizing the results transparently in the Sprint Retrospective.
In conclusion, the article presents the Sprint Planning checklist not as a rigid set of rules but as a dynamic tool for both junior and experienced practitioners to navigate the complexity of Scrum events. It encourages regular revisiting and adjustment, likening Scrum checklists to working agreements or a Definition of Done. The emphasis on community engagement is highlighted, inviting readers to share their experiences and insights in the comments section, fostering a collaborative learning environment within the Agile community.