Stefan Wolpers — April 11, 2018 — April 11, 2018
TL;DR: Scrum Sprint Planning Checklist
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?
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.
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.
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.
- ? 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.
- ? 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.)
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.
Business & Finance Articles on Business 2 Community
(130)
