It’s the first day of a new sprint! There’s some excitement in the air. The whole team works together to plan the sprint. They have the sprint goal and the backlog, but..
What actually happens in sprint planning?
This article will show you the value of sprint planning and how to practice it well. I will walk through three essential concepts for running your sprint planning session.
The product owner sets the sprint goal, providing direction and communicating what value the team will deliver in this sprint. The sprint goal isn’t prescriptive to how the team will work during the sprint, but it focuses on what must be true when the sprint ends. The goal should also clarify how this sprint builds on the previous sprint.
As the sprint begins, work moves from the product backlog (all the defined work to be done for the product) to the sprint backlog (just what will be done during the sprint). Because work doesn’t get added mid-sprint, the team can focus just on what is in the sprint backlog. There is a sense of urgency to get that work done and a sense of safety that new work and priorities won’t become obstacles to what they’ve selected.
The sprint goal isn’t prescriptive to how the team will work during the sprint, but it focuses on what must be true when the sprint ends.
During sprint planning, the development team plans how to complete the selected work. They communicate this plan to the product owner and scrum master. There’s something about saying a plan out loud to someone else that elevates your focus and commitment, as well as helping to identify gaps.
Planning the sprint is a collaborative process, and each part of the Scrum team has a role to play.
The sprint goal outlines what value the product owner has prioritized for the sprint. While communicating the sprint goal, they will connect it to the previous sprint and probable work for the next sprint.
The product owner stays present throughout sprint planning to answer any questions from the rest of the team. They are also present at the end to hear the team's plan.
The sprint goal tells the team what to do but not how to do it. The development team owns completing the work together and plans how to complete the work together. The team considers who has the skills or knowledge for each product backlog item. They may decide to each take a different part, or they may all swarm around one or two items initially and then decide who will take the remaining items.
The plan helps the team focus and strategize, but they can adjust it as needed. This adjustment happens daily in the standup as the team checks in. They make their progress visible, evaluate where they are and where they need to go and adjust the plan accordingly.
As the dev team plans the sprint, the scrum master is there to help. If the team is getting stuck on what order to tackle what’s in the backlog, the scrum master can remind them they just need to choose how to start because they can adjust as they go. If the team is concerned about a specific PBI or about getting all the work done, then the scrum master may facilitate a pre-mortem to help them identify how the sprint could go awry and plan accordingly.
It’s easy to go overtime in planning, hoping to get everything just right. The Scrum Master helps the team keep to their timebox limit for the meeting, reminding them that they will meet tomorrow for standup and can continue to adjust if needed.
The agenda for sprint planning is pretty straightforward, and the primary challenge is not to go overtime on any of the parts. In general, the sprint planning should be limited to 2 hours for every week the sprint is long.
Sprint Goal [20%] Product owner sets the direction for the sprint. The team identifies which PBIs to pull from the product backlog to the sprint backlog.
Planning [70%] Team makes a plan for how they will complete the selected work. This includes setting an initial order and who will tackle what. It also includes identifying dependencies or needed learning for selected work.
Recap [10%] The team communicates their plan back to the product owner and scrum master.
Scrum has a lot of meetings and it can be hard to keep them straight, especially when you're getting started.
The Scrum meeting checklist has all the details you need to run effective Scrum meetings.
I hope this article provided helpful guidance to run efficient and effective sprint planning sessions. If you want to learn more about Scrum in general, To learn more about Scrum, check out my What is Scrum? A Guide for Everyday People to Learn Scrum. If you have more questions, please feel free to reach out on LinkedIn.
Still not sure about your next step with Scrum? I offer a couple of free coaching sessions each month. You can signup for a free 30-minute coaching session, and we can work together to identify a good next step for you.
The rhythm of scrum consists of various events.
The last on the list is sometimes debated as to whether or not it’s actually a scrum event. I include it because it's critical to creating a cadence of work for the team.
Learn more about the rhythm of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Most scrum events are timeboxed relative to the length of the sprint:
Just because an event has a timebox doesn’t mean it needs to be that long. The timebox is the maximum time allowed for the event.
Learn more about the different scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum events are generally held in the following order
The backlog refinement session is unique in that it can be held anytime.
Explore further the events of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
I included this because it is frequently asked, but the question misunderstands the importance of the scrum events. It’s like asking which of your limbs is most important. You may be able to answer, but they are really all critical.
If pressed for an answer, the daily scrum probably has the greatest impact on the team's effectiveness.
Learn more about the events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Here’s a quick agenda
Learn more about how to facilitate sprint planning. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Think of scrum as a relay race, with each sprint being a lap. The scrum team hands off the “baton” of finished work to itself in the next sprint.
Learn more about the role of a sprint in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The sprint isn’t always included in the list of scrum events. I include it because it's critical to creating a cadence of work for the team. The sprint serves as a container for all other scrum events.
Learn more about sprints in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The sprint backlog is created during sprint planning as PBIs (product backlog items) are moved from the product backlog to the sprint backlog.
Learn more about the sprint planning process and then explore the most common terms in a Scrum glossary.
Scrum events have a clear purpose and agenda but are still very interactive. Facilitation of scrum events is at its best when everyone is engaged, asking or responding to questions. All events are timeboxed, so the facilitator must ensure the team is always moving toward the goal.
Learn more about team member's responsibilities during scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Three strategies for increasing participation in scrum meetings are
Learn more about everyone’s roles and responsibilities during the scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Scrum cultivates shared ownership for all the events, but each still has a facilitator.
Learn more about everyone’s roles and responsibilities during the scrum events. Then explore the most common terms in a Scrum glossary and learn what is Scrum.
The scrum master primarily facilitates two scrum events:
The scrum master can help facilitate other meetings while a new team is beginning to learn scrum.
Learn more about roles during scrum events. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Understand the purpose of the scrum meetings. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Inspection and adaptation (along with transparency) are pillars of scrum, so all events involve them.
Learn more about the role of events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Process improvement aligns closely with the scrum pillars of transparency, inspection and adaptation.
Out of all the events, the retrospective is the most focused on process improvement.
Learn more about events in scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
The scrum of scrums is an extra scrum event used when multiple scrum teams are collaborating together on a single product.
The scrum of scrums follows a similar pattern to the daily scrum session. The session allows the teams to update each other on what has been done, what obstacles have been encountered, and what to do next.
The scrum of scrums allows those teams to stay in sync and account for dependencies that bridge across teams. When facilitated well with healthy teams the scrum of scrum can even create collective ownership you see in self organizing teams.
If multiple scrum teams are collaborating on a single product then ideally both teams care more about it the product as a whole succeeds versus just caring if they did their part. The transparency, evaluation and adaptation from the scrum or scrums can make this possible.
To learn more explore the most common terms in a Scrum glossary.
There are actually two backlogs, the product backlog and the sprint backlog. They each contain the definitive list of work to be done. The product owner keeps the backlog ordered by priority.
Learn to use the backlog in Scrum and check out the sprint backlog vs product backlog in Scrum.
The product backlog prioritizes the features needed in the product. It is a singular visible source of requirements for the product.
The sprint backlog represents the work to do in a given sprint. It is a definitive list of all the scrum team is being asked to produce for the sprint.
Learn more about the sprint backlog vs product backlog in Scrum.
Each item in the backlog represents precise work and value to deliver. Often these PBIs are written using both user stories and acceptance criteria. The PBIs are what gets refined during the backlog refinement session, and if one is too large, it may be broken down into smaller PBIs.
Learn more about how backlogs are used in scrum, the sprint backlog vs product backlog in Scrum and explore the essential Scrum glossary.
The Scrum sprint backlog is a prioritized list of items from the product backlog that the development team plans to complete during the upcoming sprint.
It is a plan for the Sprint and is created during the Sprint Planning meeting where the Development Team decides on how to build the functionality that meets the Sprint Goal. The Sprint Backlog typically includes user stories, bugs, technical work, and other items that the development team needs to work on during the sprint. Each item in the Sprint Backlog has a clear definition of done, so the team knows when the item is considered complete.
The Development Team is responsible for creating and updating their Sprint Backlog throughout the Sprint, making sure they are on track to meet the Sprint Goal. The Sprint Backlog is a working document that helps the Development Team visualize their progress and make any necessary adjustments to their plan as they go along. The Sprint Backlog is also transparent, allowing stakeholders to see what work is being done during the Sprint.
Learn more about the backlogs of Scrum.
In Scrum, the product backlog is a prioritized list of features, bugs, technical work, and other product-related items that need to be addressed by the development team.
It serves as a single source of truth for what needs to be done on the product.
The items in the product backlog are ordered based on their importance to the product owner and the value they bring to the end-user. As the project progresses, the product backlog is constantly updated to reflect new priorities, changes in requirements, and feedback from stakeholders.
The product backlog is a living document that evolves throughout the project's lifecycle. It provides transparency and enables collaboration among all members of the Scrum team.
Learn more about the backlogs in Scrum.
Acceptance criteria is structured using the template
Here are 3 examples:
Checkout process functionality
Advertising campaign
Marketing campaign (Did you know you could use Scrum for marketing)
See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.
Acceptance criteria is written using the following structure:
Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.
Acceptance criteria is broken down into three parts.
Learn more about templates for writing acceptance criteria or learn other essential scrum terms.
A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
Acceptance Criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.
See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.
Acceptance criteria is specific to an individual task, but the definition of done applies to all work done by a team. Acceptance criteria answers the question, “What will be true when this task is completed.” The definition of done answers the question, “What are we committing to do every time we complete a task?”
See more examples and learn to write acceptance criteria or learn other essential scrum terms.
They keep the team focused on the value they create for the end-user and are written using the following format:
See examples of user stories to learn to write your own and explore the essential Scrum glossary.
Acceptance criteria is written using the following structure:
Learn more about how acceptance criteria is used in Scrum and explore the essential Scrum glossary.
A user story focuses on the identity, goals and motivations of the user you’re designing for. It emphasizes the why of the new functionality.
Acceptance Criteria focuses on the action taken by the user to meet their goal. It highlights the what of the new functionality.
See more acceptance criteria examples and learn to write acceptance criteria or learn other essential scrum terms.
Acceptance criteria is structured using the template
Here are 3 examples:
Checkout process functionality
Advertising campaign
Marketing campaign (Did you know you could use Scrum for marketing)
See more acceptance criteria examples and learn to write how to create your own or learn other essential scrum terms.
They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs. Typical measurements include using Fibonacci numbers or t-shirt sizes.
Learn to use story points and explore the essential Scrum glossary.
What if you could turn those conversation into new clients?
Over 5 days, I’ll teach you how to use the power of story through a proven framework to craft the most profitable elevator pitch you’ve ever written.