The Sprint Planning Checklist (2024)

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.

The Sprint Planning Checklist (1)

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 Sprint Planning Checklist (2)

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.)

The Sprint Planning Checklist (3)

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.

The Sprint Planning Checklist (4)

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

Download the ’Scrum Anti-Patterns Guide’ for Free

Download the ‘Remote Agile Guide’ for Free

As an experienced Agile enthusiast with a deep understanding of Scrum methodologies, I find the skepticism towards using a Scrum Sprint Planning Checklist quite understandable. Agile, after all, is often perceived as a flexible and adaptive approach, more focused on values and principles than strict processes. However, my expertise leads me to assert that tools like checklists can indeed be valuable at an operational level, offering tangible benefits for Scrum Teams.

The reference to the origin of checklists in aviation accidents is apt. It highlights the critical role they play in preventing human errors, even among experienced professionals. The example of a new plane crash due to the crew's oversight emphasizes the importance of systematically following predefined steps, especially in complex situations. This underlines the essence of checklists as cognitive aids, reducing the risk of overlooking crucial aspects during high-pressure activities, such as Sprint Planning.

Contrary to the perception that checklists impose standardized processes, I argue that they serve as practical tools for practitioners, including Scrum Masters. The emphasis here is on their role in reducing cognitive load, allowing teams to focus on more meaningful tasks. My recommendation aligns with the view that checklists are not about making individuals 'stupid' but about augmenting their capabilities, as explored in "The Checklist Manifesto: How to Get Things Right."

Now, delving into the specifics of the provided Scrum Sprint Planning Checklist:

  1. Preparation Phase (T-2 and T-1):

    • Address open tickets in "code review" and "ready for acceptance columns."
    • Update Sprint boards, both physical and online.
    • Run Sprint Review and Sprint Retrospective.
    • Remind team members of upcoming Sprint Planning.
  2. During Sprint Planning (T=0):

    • Kick off Sprint Planning with a Zoom session for remote team members.
    • Clean up old boards, syncing physical and Jira boards.
    • Discuss possible spill-over of unfinished Product Backlog items.
    • Move undone items to the Product Backlog or delete/archive them.
    • Create a new "Sprint" in Jira.
    • Close the previous Sprint, addressing spill-over items.
    • Figure out available team capacity and align it with the business objective.
    • Collaboratively create a Sprint Goal.
    • Pick Product Backlog items needed to meet the Sprint Goal.
    • Run an anonymous Sprint survey.
    • Summarize results from the previous Sprint Retrospective.
  3. After Sprint Planning (T=+1 to T=+3):

    • Sync offline board with online board.
    • Start collecting data for the upcoming Sprint Retrospective.
    • Remind team members to participate in the outstanding Sprint survey.
    • Publish results of the Sprint survey from the previous Sprint.

The checklist reflects a practical approach tailored to the specific context of a large Scrum Team in a traditional utility company. The emphasis on syncing boards, addressing spill-over items, and involving team members in surveys aligns with the principles of transparency, inspection, and adaptation inherent in Scrum.

In conclusion, this Scrum Sprint Planning Checklist is not a rigid prescription but a flexible guide that emphasizes collaboration, communication, and continuous improvement—core tenets of the Agile mindset. It underscores the idea that checklists, when thoughtfully applied, can enhance the agility of Scrum Teams rather than restrict it. If you're a Scrum Master or practitioner, consider integrating such checklists into your workflow and adapt them to your team's unique needs for optimal results.

The Sprint Planning Checklist (2024)


Top Articles
Latest Posts
Article information

Author: Arline Emard IV

Last Updated:

Views: 6103

Rating: 4.1 / 5 (72 voted)

Reviews: 87% of readers found this page helpful

Author information

Name: Arline Emard IV

Birthday: 1996-07-10

Address: 8912 Hintz Shore, West Louie, AZ 69363-0747

Phone: +13454700762376

Job: Administration Technician

Hobby: Paintball, Horseback riding, Cycling, Running, Macrame, Playing musical instruments, Soapmaking

Introduction: My name is Arline Emard IV, I am a cheerful, gorgeous, colorful, joyous, excited, super, inquisitive person who loves writing and wants to share my knowledge and understanding with you.