The Sprint Planning Checklist

(Germany)

November 9, 2020

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 — Age-of-Product.com

Do you want to get articles like this one from the Scrum Master Survival Guide in your inbox? Then sign up for the Food for Agile Thought newsletter and join 27k other subscribers.

Join the 28th Hands-on Agile Meetup on November 19, 2020: Scrum Guide 2020

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

Download the ’Scrum Anti-Patterns Guide’ for Free

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