TL; DR: Scrum Sprint Planning Checklist
A checklist for sprint planning? How dare you: Agile is a mindset, not a methodology. It's a journey, not a destination. There is no one-size-fits-all approach, and what else could you do with a checklist, the mother of all standardized processes?
Well, it always depends on the intended use of a tool. Learn more about why scrum checklists are a useful tool when applied at an operational, practical level, reducing your cognitive load and freeing up time for more relevant things.
Want articles like this from the Scrum Master Survival Guide delivered to your inbox? AsSign up for the Food for Agile Thought newsletterand join 27,000 other subscribers.
The magic of checklists
Some of you may know thisChecklists come from a flight accident. A new plane with a crew of the most experienced test pilots crashed on takeoff. The plane did not appear to have any mechanical problems; The flight crew forgot just one simple step during the takeoff process.
It was probably hubris to face the complexity, the sense of "we know what to do because we're doing it all the time" that led to the failure. Whatever it was, the result was that checklists became mandatory in aviation. Or in hospitals. Or anywhere the complexity of a task turns out to be too much of a cognitive load to be trusted to go smoothly.
So, from my point of view, checklists are not a bad means of enforcing standardized processes, but a useful tool for practitioners, even if they use a Sprint Planning checklist as a Scrum Master.
Scrum Sprint Planning Checklist - Details
This sprint planning checklist is modeled after a former Scrum team at a large multinational traditional utility company at the beginning of their Scrum journey. In other words, you cannot apply this checklist to your Scrum team without reviewing and adapting it. For example, they put a lot of energy into preparing sprint planning during the frequent product backlog refinement sessions. (They continuously planned the next two sprints during the refinement sessions.)
In practice, the sprint planning itself was usually a confirmation of what they had already agreed upon during the refinement of the product backlog. They likely adjust the scope of the planned sprint during capacity planning. However, it was rare that they would replace the previously planned sprint goal with a completely different goal. So a typical sprint planning only lasted one to two hours.
The Scrum team in question was quite large - eight developers - usually joined by two or three remote team members. It used Atlassian tools (Jira, Confluence) and had full control over the build pipeline. In general, the stakeholders had a great deal of influence over where the Scrum team went, and on more than one occasion hindered the team in doing so. The work of the Scrum Master was therefore more of a tactical or operational nature on the shop floor.
Regarding the next timeline, T=0 refers to the start date of the upcoming sprint and T-1 refers to the day before the start of that sprint. Therefore, T+1 is the day after the sprint schedule.
The following sprint planning checklist contains tasks for everyone on the Scrum Team:
Preparation of the sprint planning:
- T-2: Handle the number of open tickets in the Code Review and Ready to Accept columns. Ask team members to focus on moving tickets to Done before working on new tickets.
- T-1: Ask team members to update the sprint boards. (There was both a physical and online Sprintboard that needed to be synchronized.)
- T-1: Run the sprint review. (Question: Did we meet the sprint goal and are we still on track to meet the product goal with the upcoming sprint?)
- T-1: Conduct the Sprint Retrospective. (Choose continuous improvement action items for the upcoming sprint.)
- T-1: Remind all team members about tomorrow's sprint planning.
During sprint planning:
- T=0: Start sprint planning by sharing a Zoom session for those team members who can't attend sprint planning in person.
- T=0: Clean up the old boards with the whole scrum team by walking around the board, checking the status of each ticket and moving tickets if necessary. Sync the offline board with the Jira board. (The team always struggled to answer a simple question: Which board leads? Given the remote team members, it should have been the Jira board.)
- T=0: Discuss the potential spillover: Are those unfinished Product Backlog items still valuable? (Spillovers are an appropriate team metric and a good topic for a retrospective. If spillovers persist across multiple sprints, this should spark several discussions within the team, for example:
- Are the Product Backlog item dimensions correct?
- Is the refinement of the product backlog items sufficient? As a team, do we have a common understanding of why, what and how?
- Finally, would Kanban be a better team fit?
- T=0: If undone Product Backlog items are not carried over into the upcoming Sprint, move them to the Product Backlog or delete/archive them.
- T=0: If not already available, create a new "Sprint" in Jira.
- T=0: close the previous sprint:
- Move any product backlog items that are overflowing to the correct buckets, such as the upcoming sprint or the product backlog.
- Clean the physical board of old stickies from the previous sprint.
- T=0: Kick-off of the next sprint planning:
- As a scrum team, determine the available team capacity: who can do work in the next sprint?
- Ask the product owner to share the business goal that the upcoming sprint aims to achieve.
- Align the Scrum Team's capacity with the Product Owner's business goal: is this realistic?
- If the business goal and the ability to work in a team don't match, try reducing the sprint scope.
- If the team cannot meet the proposed business goal, ask the product owner to come up with a realistic goal.
- Make a sprint goal together.
- The Development Team selects the Product Backlog items required to achieve the Sprint Goal.
- Ask the team if the workload leaves too little time to address unexpected issues.
- Ask the team if the scope of work allows for the opportunity to fix technical issues and bugs. (Avoid the 95+ percent usage trap. Don't become a feature factory at the expense of tech stack quality.)
- The Scrum Team creates stickies for the physical board. (Be sure to follow the color codes for the different types of stickies. Spikes, user stories, technical tasks, subtasks, and bugs all have distinctly different colors.)
- T=0: Take an anonymous sprint survey on the previous sprint. (The sprint survey consisted of four questions: 1. Did we add value to our customers during the last sprint? 2. Has the level of technical debt changed during the last sprint? 3. Would you recommend someone to join this organization? (Friend with an agile mindset? 4. How do you personally feel about your work situation?)
- T=0: Summarize the results of the previous sprint retrospective and update the new sprint board with the action items. (The Scrum Team has publicly communicated its retrospective results.)
After sprint planning:
- T=+1: Synchronize the offline board with the online board. (The team struggled with administrative tasks. Additionally, the role of the Scrum Master was misunderstood and keeping boards in sync was often seen as a Scrum Master's job.)
- T=+1: Start collecting data for the upcoming sprint retrospective, for example by setting up a sprint mailbox.
- T=+2: Remind team members to take the pending sprint survey. (The minimum attendance was eight of the eight developers plus two business analysts, the product owner, and the scrum master.)
- T=+3: Publish the sprint poll results from the previous sprint.
Checklist for Scrum Sprint Planning - The Conclusion
Scrum event checklists can help both the up-and-coming practitioner – what should I do – and the experienced Agile practitioner deal with the complexity. Far from violating the Agile mindset, checklists like this sample sprint planning checklist reduce the cognitive load of running events and practices, while also avoiding unnecessary hassles with the rest of the organization.
Think of scrum checklists as work in progress that needs to be reviewed and updated regularly. In this respect, Scrum checklists do not differ significantly from, for example, working agreements or a definition of done.
Do you use checklists in your daily work as a Scrum Master? Then let us know in the comments.
✋ Don't Miss: Join the 8,500+ strong Hands-on Agile Slack team
I invite you to join this„Hands-on Agile“ Slack-Teamand enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you want to join now, all you have to do is do itEnter your credentials via this Google form, and I'll sign you in. By the way,It is free.
Sprint Planning Checklist - Related Articles
- What questions do you have?
- How would you use this product?
- What excites you about the product increment we reviewed? ...
- How do you feel about the product increment we reviewed? ...
- If you could change one thing about the product we've built, what would you change?
- Not setting a sprint goal.
- Failing to prepare the product backlog.
- Having no agenda for sprint planning.
- Focusing too much on velocity.
- Forbidding changes to the sprint plan.
- Neglecting to double-check the sprint resources.
Sprint Planning answers three questions; Why, What, and How.What are the 3 questions to consider during sprint planning? ›
- Topic One: Why is this sprint valuable? The Product Owner proposes how the product could increase its value and utility in the current sprint. ...
- Topic Two: What can be done this sprint? ...
- Topic Three: How will the chosen work get done?
- The Product Backlog.
- The latest product increment.
- Estimated capacity of the development team during Sprint planning.
- Past performance of the development team.
- Resizing Carry-Over Product Backlog Items (PBIs)
- Assigning Tasks.
- Filling Up the Entire Capacity of the Team.
Effective agile sprint planning has three key parts; a sprint goal, an understanding of team capacity, and a prioritized set of backlog items.What is a common sprint planning mistake? ›
One of the biggest mistakes you can make in sprint planning is to show up unprepared. This means not having a clear and prioritized product backlog, not having a realistic sprint capacity, not having a shared understanding of the sprint goal, and not having the right people involved.How do I get better at sprint planning? ›
- Reserve the same time for sprint planning ⏰
- Set a sprint planning meeting duration and stick to it ⏳
- Complete backlog refinement before sprint planning begins 📝
- Incorporate stakeholder feedback from the sprint review 😍
- Incorporate sprint retrospective insights 💡
At the end of the sprint planning process, teams walk away with two key artifacts: a sprint goal and a sprint backlog. Sprint goal: The goal is a one-to-two-sentence description of what the team plans to accomplish in the upcoming sprint. Sprint backlog: The sprint backlog works as a to-do list for the upcoming sprint.
The purpose of sprint planning is to define what can be delivered in the sprint and how that work will be achieved. Sprint planning is done in collaboration with the whole scrum team.What are the two parts the sprint planning is divided into? ›
The sprint planning meeting consists of two parts. In the first part the product owner shares the sprint vision with the team and presents the backlog for the sprint. In the second part of the sprint planning event the team meets to discuss how the PBIs should be decomposed into developable tasks.What is the first part of the sprint planning? ›
Ensure you come well-prepared to the meeting, and have a clear sprint goal to present to your developers. Go over the product backlog items, and estimate your team's velocity. Evaluate how many items they'll accomplish. Finally, break down those items into tasks, and distribute them to the most capable team members.Which three 3 activities will a product owner likely engage in during a sprint? ›
Answer: Answer questions from the Development Team about items in the current Sprint. Work with the stakeholders. Provide feedback.What three factors are best considered when establishing the sprint length? ›
- Market viability and risk appetite. When competition is fierce, the businesses might not want to risk and would like to deliver products frequently. ...
- Overall length. ...
- Understand. The first step is to name and understand the problem to which this whole process will be devoted. ...
- Diverge. The second stage is focused on creating a solution concept. ...
- Decide. The ideas prepared in step two are evaluated and discussed in this step. ...
- Prototype. ...
It'll allow you to build your prototype, test it, then launch it into the market without wasting big sums of money. Design Sprints comprise five phases: Empathize, Define, Ideate, Prototype, and Test.What are the 4 phases of design sprint? ›
A design sprint has five phases: Understand, Diverge, Converge, Prototype, and Test.What are the 4 qualities of the sprint goal? ›
A Sprint Goal should be targeted, quantifiable, realistic, relevant and time-bound.What is the most important part of the sprint? ›
The retrospective is the most important part of the sprint.
You'll usually estimate story points before a sprint planning meeting, since that's when your team determines how much work they can carry out in an upcoming sprint. Typically, story points take into account three factors that can impact a task's scope and effort, and the story point's value increases accordingly.Who should be in sprint planning? ›
Sprint planning involves the entire Scrum team: the development team, Product Owner, and Scrum Master.Should you assign tickets during sprint planning? ›
For newer scrum teams, assigning tasks during sprint planning acts as something of a safety net – it's reassuring to know who's responsible for which items, and assigning every task can help ease worries that stories will get left behind.How many sessions does sprint planning consist of? ›
Does the Sprint Planning meeting consist of two sessions?? "The Sprint Planning meeting consist of two parts, each one beeing a time-box of one half of the Sprint Planning Meeting duration."Who prepares the sprint goal? ›
A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.Who decides if sprint goal is met? ›
At the end of each sprint, the Scrum team determines whether they have met their goal. However, the team needs to talk about the progress during the daily meeting to keep the goal visible to everybody.Why sprint planning fails? ›
Sprint Planning fails when the team does not consider Sprint Goals or may keep the Sprint Goal as an afterthought. Induce flexibility in the Sprint and encourage the team to take risks while developing important products.What is the most common reason behind sprint failure? ›
Lack of a sprint goal. The most common reason for a scrum team failing to meet their sprint goal is mainly because they simply don't have one. The team just haven't identified and committed to a sprint goal and as such, they haven't got a north star to guide them, and they just push deliver stuff.What is sprint planning for dummies? ›
Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint. In sprint planning, the entire team agrees to complete a set of product backlog items. This agreement defines the sprint backlog and is based on the team's velocity or capacity and the length of the sprint.What day is best for sprint planning? ›
Friday being the last day of the week means that people are usually tired and not as able to concentrate to finish the sprint (they just want to go home for the weekend). Starting the sprint on Monday will tempt teams to work over the weekend to finish stuff that was not finished on Friday.
A sprint planning meeting is when the team (including the Scrum Master, Scrum Product Manager, and Scrum Team) meets to determine which backlog items will be handled in the next sprint. The sprint planning Scrum ceremony is a collaborative process that allows team members to have a say in when work happens.Who owns the sprint backlog? ›
Who Owns the Sprint Backlog? According to the scrum framework, the entire agile team — scrum master, product owner, and development team members — will share ownership of the sprint backlog. This is because all members of the team will bring unique knowledge and insights to the project at the beginning of each sprint.What does a successful sprint look like? ›
A successful Sprint is one that creates a potentially releasable increment of value that satisfy the needs of the stakeholder as determined during the previous refinement and Sprint Review.Who assigns tasks in sprint planning? ›
By the end of the Sprint planning meeting, the tasks that are required to finish on the first day get assigned to the development team. The Scrum master will keep assigning further tasks to the team daily.What is backlog refinement vs sprint planning? ›
Sprint Planning always happens on a particular cadence — at the beginning of the Sprint; while Backlog Refinement can happen on a variable cadence (for teams that have Backlog Refinement sessions, there could be one, or more than one, during any given Sprint, the timing of which is agreed to by the attendees)Who decides when to update the sprint backlog? ›
During the Scrum sprint, team members are expected to update the sprint backlog as new information is available, but minimally once per day. Many teams will do this during the daily scrum.What is the difference between sprint review and sprint planning? ›
The key difference is that a Sprint Review focuses on improving so the team can deliver a better product, whereas a Sprint Retrospective focuses on improving the overall system so the team can work more harmoniously and find flow together.What is done during sprint planning? ›
Sprint planning is an event in the Scrum framework where the team determines the product backlog items they will work on during that sprint and discusses their initial plan for completing those product backlog items.What is discussed in sprint planning meeting? ›
A sprint planning meeting is when the team (including the Scrum Master, Scrum Product Manager, and Scrum Team) meets to determine which backlog items will be handled in the next sprint. The sprint planning Scrum ceremony is a collaborative process that allows team members to have a say in when work happens.What are the two outcomes of a sprint planning meeting? ›
- A sprint goal.
- A sprint backlog.
So, what does a Scrum Master do during Planning meeting then? Something that you would do every time: Remind the purpose of the Sprint Planning and the agenda. Drive the discussion around the Sprint Goal, the Sprint Backlog.What is the main agenda for sprint planning meeting? ›
Sprint planning is the process of: Reviewing the available backlog of work. Scheduling the work that your team will complete in the next sprint based on the amount of time that work is expected to take and team member availability.What is expected at the end of the sprint planning meeting? ›
Toward the end of the Sprint Planning Meeting, the team breaks the selected items into an initial list of Sprint Tasks, and makes a final commitment to attempt the work. Meetings can initially be facilitated by the Scrum Master, who has no decision-making authority at these meetings.Is sprint planning divided into two sessions? ›
Sprint Planning Meeting (Part I & Part II) This meeting is split into two sessions. In the first session, the product owner reviews the list of features and defines what needs to be built during the next sprint. The next session involves identification of tasks that need to be executed, in order to complete the build.Is sprint planning comprised of 2 parts? ›
The sprint planning meeting consists of two parts. In the first part the product owner shares the sprint vision with the team and presents the backlog for the sprint. In the second part of the sprint planning event the team meets to discuss how the PBIs should be decomposed into developable tasks.Who is responsible for sprint planning? ›
Who is Responsible for Sprint Planning? Sprint planning involves every scrum team member – the Scrum Master, Product Owner, and Development Team. The length of the sprint itself should already be determined at this time. Sprint planning is held prior to kicking off each new sprint and is led by the Scrum Master.