What Is a Sprint Planning Meeting?
Software development teams rely on sprints to help them keep pace with the rollout of new software versions, called iterations. With competing demands for what to include in an iteration, a development team must be very clear about what it should focus on during a sprint — for example, should certain bug fixes take precedence over rolling out new features, or vice versa?
Agile has also become popular in other fields and industries because this focused approach can boost effectiveness, productivity, and quality.
Before a sprint gets under way, the project team participates in a sprint planning session. This session reaches two key decisions:
-
Sprint Goal: This refers to what can be delivered during the sprint.
-
Sprint Backlog: The list of tasks to be completed during the sprint to achieve that goal.
Sprint planning is a time-limited exercise, and usually takes place for one hour a week over a period of about eight weeks.
Smartsheet Agile Project Template
Plan, manage, and visualize your projects with Smartsheet.
Stay on top of your Agile projects with this ready-to-use Smartsheet template. Track tasks by start and end dates, see how changes impact your timeline with dependencies, and keep everyone aligned with progress updates, task assignments, and automated workflows. Perfect for teams that need to adapt quickly and keep stakeholders in the loop.
Sprint Planning Fits with Scrum and Other Agile Methods
Sprint planning plays an important role in the universe of Agile development methodologies which prioritize responsiveness, flexibility, and continuous improvement, and seek to help organizations excel at managing work in a world where priorities and markets are shifting rapidly. As customer requirements and competition evolve, sprint planning determines what work to tackle next.
In software, sprint planning determines which product changes or features can be delivered and how to roll them out most efficiently in the next iteration. This planning process ensures that the team tackles a realistic amount of work and accomplishes the most important work first. After all, there’s only so much that can be accomplished during a sprint without compromising quality.
Sprint planning is also used for hybrid Agile methods, such as Scrumban, a portmanteau of Scrum and Kanban, the visually-based, pull-oriented work system associated with Toyota. Scrumban combines fixed-length iterations with a standardized hand-off process, which means that more than one specialized team can work on a single work item.
To understand how sprint planning works with Scrum, it helps to first review the key roles and processes of the method. During sprint planning, the project team will work with the product owner (the key stakeholder in the company or organization for the product) and is facilitated by a Scrum master (the individual who acts as a servant-leader by making sure the process flows, by coaching the team, and by helping everyone communicate and understand the mission).
These participants create a sprint backlog, which is a list of features or changes drawn from the product backlog that will be developed and rolled out at the end of the sprint. The sprint backlog is shaped by the sprint goal, i.e., that which can be delivered during the sprint.
“The most common mistake I’ve seen is when a team tries to plan a sprint when the product backlog is not ready with good user stories that are immediately actionable,” says Scrum Master Scott Luse of Dassault Systèmes and other companies. “Another, less common, mistake is to conduct a sprint planning meeting without having the product owner in the room to discuss the work and sprint goals. In both cases, the sprint will typically start with a low chance of success. A good Scrum master should protect the team and ensure this doesn’t happen” he adds.
Scrum and Agile expert Laura Neves, Program Manager at Microsoft, urges teams to make sure at the start that everyone is on the same page in terms of language and terminology.
“A super simple, but very useful habit: Always spell out your acronyms when writing down the sprint goals, roadmaps, and definition of done. Don’t ever assume that everyone knows exactly what those are, especially when there are newcomers to the team. Save yourself a lot of explaining and reworking. Spelling them [acronyms] out also forces you to reassess the freshness of long-used concepts. Do you (and your team) really remember what is supposed to happen from start to finish in your E2E flow?” she asks.
Want a more agile approach to managing projects?
Learn all there is to know about Agile project management and tips to help you start implementing Agile PM best practices.
How Long Is a Sprint Planning Meeting?
Scrum experts generally recommend spending about one hour on sprint planning for each week of the sprint, for a total of up to eight hours. Highly complex projects may require more time. And, it may take nearly twice as long depending on the maturity of the Scrum team.
To see why the amount of time a team’s been together is such a significant factor in determining the length of a sprint, we’ll look at the work of psychologist Bruce Tuckman, who in 1965 proposed the idea that group development proceeds through set stages:
-
Forming: When a new team gathers or new members are brought into a team
-
Storming: When they begin to butt heads over how to work
-
Norming: When team members come to terms with everyone’s roles and relationships in the group
-
Performing: When a team begins to hit its stride, maximizing productivity and minimizing friction between teammates
It’s little wonder, then, that teams still in the early stages of development need more planning time to build consensus than do teams that have been working together for longer.
This acclimation factor may explain why sprint planning is seen by some critics as a waste of time. Conversely, Scrum experts say sprint planning is a vital precursor to any sprint. For one thing, sprint planning improves the efficiency of a sprint and prevents developers from biting off more than they can chew. The process also builds consensus with the project owner about the sprint’s deliverables. Moreover, it gives Agile developers a sense of authority over their work and stops them from feeling like they’re constantly trying to reconcile competing demands with their own capacity for work.
“It's vitally important that the team drives the sprint goal and commits to something it can deliver. As much as the product owner wants to hear team members promise the moon and the stars, they can always bring in more work later if they complete what they’ve committed to,” says Jeff Crowl, a Scrum Master and Agile coach who has worked at Nike, T-Mobile, and other companies. “This goes double for a scaled enterprise, where other teams' sprints could actively depend on the work being done in two weeks,” he notes
Defining the Sprint Goal Is Crucial to Success
Experts say that the effort put into defining the sprint goal pays dividends by helping the team ensure that the sprint provides maximum value to the organization and its customers.
The team writes the sprint goal in collaboration with the product owner, and the goal statement is short (only a few sentences).
Richard Hundhausen, President of Accentient Inc., which coaches companies in Scrum, says that the sprint goal is crucial: “I’d say the most common mistake is not collaborating with the product owner to create a sprint goal. Scrum teams typically jump right to forecasting without any consideration for a common theme for the work (the sprint goal). Without having a sprint goal, what will the Scrum team commit to? During the daily scrum, what goal will the development team plan their next 24 hours around?”
Scrum Trainer David Sabine of Agile consultancy Berteig says that without a clearly defined sprint goal, participants will struggle to determine what to tackle in the sprint. “The most common mistake in Sprint planning is that the team fails to achieve a clear sprint goal, making it impossible for team members to regulate the types of activity that belong in the sprint and the types of activity that do not,” he says.
Like goals in general, good sprint goals are SMART (specific, measurable, achievable, realistic, and time-bound). For example, a good sprint goal for an online freelancing platform development team might read something like, “Create an earnings report generator that provides verification of freelancing income earned in a tax year,” or, “Create a multimedia messaging interface within the platform instead of having freelancers and clients rely on third-party messaging services.” Clearly stated goals make it easy to communicate objectives and progress to those not directly involved in the sprint.
A handful of considerations go into drawing up a sprint goal. For example, how do lower-level goals, designed to be achieved within a single sprint, fit in with high-level strategic objectives or the long-term vision for a product? Which of the tasks in the product backlog are relevant to the sprint goal and should be included in the sprint backlog? And, are the sprint goals achievable and realistic based on the number of resources and developers available? Remember to factor in holidays, team members’ vacations, and company events when looking at the time available.
The sprint goal is not a mere formality to be completed and then cast aside once the sprint actually gets under way. Besides defining the direction for all work to be completed during the sprint, it’s also the standard by which the success of a sprint is gauged at the post-sprint review. So, it pays to have a goal that the team, given its resources, can actually meet.
Defining the Sprint Backlog Sets Up the Team’s Work Plan
The sprint backlog comprises a list of tasks to be completed during a sprint. While it’s drawn up collaboratively by the Scrum team and the product owner, the latter does not usually engage in the granular sprint planning process. Scrum teams by definition are self-organizing, so team members drive the process. Often, the product owner is not in a good position to know how the team should conquer the tasks. In fact, the owner’s close involvement in this part of planning may even be counterproductive.
Instead, the role of the product owner is usually one of specifying the sprint goal, preparing candidate items for the sprint backlog, stating requirements for these items, and negotiating with the developer team over the makeup of the backlog until both parties reach a consensus.
Of course, the product owner reserves the right to ask questions about the items on the sprint backlog, their order, and how they’re supposed to be accomplished. The Scrum team will prepare both a list of backlog items that they commit to delivering and a list of tasks and subtasks necessary to complete these items. In the process, the team also estimates the amount of effort needed to complete each backlog item, usually using shorthand sizing terms, such as shirt sizes or story points.
Ron Madison, a Scrum Master at PayPal, says that it’s important at this stage to know what work comprises each task. “A mature team does tasking of stories before sprint planning, including both development and quality assurance,” he points out.
The amount of work for a single sprint must stay manageable, usually with some buffer time built in. Having 20 percent of sprint capacity allotted as “slack time” is not unusual. To do this, teams use a metric called sprint velocity, which is the amount of work, in story points, completed during a single sprint. Typically you use figures from the most recent sprint; this practice is called using “yesterday’s weather,” since it’s believed that the previous sprint’s velocity is the most accurate predictor of the next sprint’s. Sprint velocity is adjusted based on the availability of team members and the constitution of the Scrum team.
“The most common mistake is overfilling a sprint with work,” says Troy Magennis, President of Focused Objective, a software development consulting firm. “If you are doing lots of first time work, uncertainty will be very high, so it's preferable to acknowledge that fact up front and leave space to get customer satisfaction for and high quality from the stories you do choose. The second and third biggest mistakes of sprint planning are also overfilling. Don't let quality suffer because you bite off more than the team can chew.”
Sprint planning may be split into two separate phases: the WHAT meeting and the HOW meeting. During the WHAT meeting, the sprint goal is defined, the sprint backlog is created, and team capacity is decided. During the HOW meeting, the Scrum team creates the list of tasks needed to complete each backlog item. In software, these tasks typically span design, implementation, testing, and documentation, and each should take no more than a couple of days to complete. If a task does take more than a couple of days, it indicates that the items on the sprint backlog are too large for sprint work; they may need to be split up.
Then, the Scrum team estimates the amount of work in people hours required to complete backlog items, and calculates the likely total duration of the sprint’s activities. Based on the Scrum team’s capacity, if the members feel they can tackle more (or less) during a sprint, they may request an iteration adjustment to increase or decrease the scope of work.
Mike Cohn, President of Mountain Goat Software, cautions teams against overplanning. “The biggest problem I see during sprint planning is teams taking it too seriously. They do this by trying to identify every task they'll need to do. That level of detail isn't needed. Identify enough tasks to know you're selecting the right product backlog items, but that doesn't mean you have to include every little task. ‘Get in, get’ out should be the rule for sprint planning,” he says.
Who Is Present for Sprint Meetings?
A sprint planning session will involve input from three main stakeholders: the scrum team, the scrum master, and the product owner.
The Scrum team consists of the developers who take on the nuts and bolts of the project. During the sprint planning meeting, it’s the team’s job to estimate and argue for what can and should be taken on during a single sprint. The Scrum team will then commit itself to meeting the sprint goals, working on the project, and ensuring delivery of a new iteration that meets the requirements that were spelled out during sprint planning.
The Scrum master is a facilitator, liaison, and coach for the Scrum team. They’re typically older, more experienced developers who understand how the team’s work builds into overarching strategic objectives, long-term goals, and customer relationships. The Scrum master manages the team’s external relationships (including the relationship with the product owner) and ensures that the team follows the principles of Agile development. At the sprint planning session, the Scrum master guides the Scrum team to set suitable objectives for each sprint, serving as a negotiator between developers and product owner.
Laurens Bonnema, a Scrum Consultant with Xebia, says the Scrum master’s role is crucial to making sure the team acts as “value-driven problem solvers.” Says Bonnema, “An experienced Scrum master will help the team recognize the importance of a sprint goal and work with it to craft one at the start of the sprint planning. Usually, just asking the question, ‘So, what shall we focus on next sprint?’ will help a team select and slice the work.”
The product owner is the project’s chief stakeholder, the person or party for whom the project is being built. The extent to which the product owner gets involved in sprint planning varies, but they tend to be hands-off with regard to lower-level task planning. Instead, they reserve their authority for stating the sprint goal, selecting and prioritizing items on the sprint backlog, and stipulating acceptance requirements for each item.
What Is the Goal of the Sprint Review Meeting?
Sprint planning, ironically, starts with finishing the previous sprint. At the end of each sprint, hold a review meeting, in which the Scrum team goes over what it accomplished and demonstrates how new features and functions work.
Usually, the Scrum team, product owner, Scrum master, other developers in the organization, management, and other stakeholders attend the sprint review. Keep the atmosphere informal, and the conversation fairly fluid.
During this session, evaluate the team’s work against the sprint goal that they set during the sprint planning meeting. Did the team accomplish each sprint backlog item? Did you meet the overarching sprint goal? Were there any lessons to apply to the next sprint?
Preparing for a Sprint Planning Meeting
Before heading into a sprint meeting, it’s a good idea to check the product roadmap. This strategic document outlines how a product will evolve over a long series of sprints and iterations. Items that eventually appear on the sprint backlog must be aligned with the product roadmap, so it pays to have the roadmap fresh in your mind. If sprint backlog items aren’t aligned with the product roadmap, the product risks losing direction.
Download Excel Template
Try Smartsheet Template
You should also hold a pre-planning meeting with representatives from the Scrum team, Scrum master, and project owner. This meeting, held a few days before the main sprint planning meeting, gives everyone the chance to groom the backlog. Backlog grooming is the process of prioritizing, estimating, detailing, and determining acceptance criteria for backlog items. It expedites the planning session itself and allows for greater productivity during a sprint by more accurately matching the amount of work required with the capacity available.
“One of the biggest mistakes that I see related to sprint planning is an overall lack of preparation and solid understanding of the stories prior to the meeting. This [problem] can cause a myriad of issues. Teams need to fully understand a story before they can commit to the work, and, most often, a single one-to-four-hour meeting just isn’t going to cut it,” says Jennifer Guilbert, a Scrum Master with Capstone Consulting.
“I recommend adding a mid-sprint checkpoint or grooming activity to get the team together with the product owner to review the stories added to the next sprint backlog, ask questions, and get clarification well in advance of the next sprint planning meeting. [Doing] this will make your sprint planning much more efficient and can even cut the time in half,” she says.
Download Product Backlog Template - Excel
Download Sprint Backlog Template - Excel
Other major stakeholders may benefit from attending a pre-planning meeting, as it gives everyone a chance to make sure they’re happy with the prioritization of items on the backlog. This is also a good time to bring the UX designer on board so they can start thinking about any design changes required for completed backlog items.
When it comes to using techniques to determine the prioritization of backlog items, bug fixes and glitch repairs will typically rate highest on the sprint backlog. Another common practice is to use business prioritization, in which you ask which item(s) on the backlog stand to benefit the business most, and therefore assign them highest priority. There are a few possible factors to look at, such as the risk involved in or mitigated by the backlog item and the amount of business value an item is expected to generate. Where those metrics are lacking, the MoSCoW prioritization method, which prioritizes each item as a must have, should have, could have, or would like to have, can also be a helpful technique. And, of course, you should draw from the Scrum master’s experience in prioritizing backlogs; after all, they’re there as an advisor for the team.
A pre-planning meeting of this sort also helps the product owner make sure that items on the backlog meet the team’s definition of ready — that is, immediately actionable. Since sprints don’t leave much room for wasting time, development teams will have a set of criteria for backlog items that tell whether the items are ready to be worked on.
Typically, you prepare the backlog items with the largest values for readiness first. For a typical team working on typical tasks, the definition of ready may include any or all of the following: story point values being assigned; dependencies being removed; testable examples being created; and acceptance criteria being defined. One simple acronym to explain a solid definition of ready is INVEST: independent, negotiable, valuable, estimable, small, and testable. Stories validated using INVEST are ready to move to the sprint backlog.
Similarly, the product owner can save some time during the planning meeting by establishing acceptance criteria for backlog items. A simple, objective description of what a backlog item implementation must, should, and could achieve will expedite discussions of acceptance criteria during the full planning meeting.
“The most common mistakes I see in sprint planning are stories that don’t have an acceptance criteria and product owners not showing up. Another mistake I see on the part of Scrum masters is trying to assign all stories to a specific team member,” says Aleksandr Kofman, a Scrum Master at information provider Elsevier.
The Steps in a Sprint Planning Meeting
Here’s how the typical sprint planning meeting proceeds:
-
Paint the Big Picture: Before the meeting gets under way, the Scrum master reminds the team of what they’re broadly trying to achieve and how it fits into the strategic goals or roadmap for a product. It’s also helpful if the product owner comes prepared to talk about two sprints-worth of items in order to contextualize where the product is headed over the medium term.
-
Bring Everyone up to Speed: Now is the time to exchange any information that those involved with the upcoming sprint should know. Recent additions to the backlog, changes in team member availability, or new stakeholder input could all be shared at this point.
-
Present the Target Velocity for the Upcoming Sprint: The velocity is the total number of user stories completed during a sprint. Typically, this figure is derived from the last completed sprint (the yesterday’s weather principle). If the membership — not the numbers — of the Scrum team has changed since then, use the average velocity over the last three sprints. If this is your team’s first sprint, a good ballpark figure is eight story points per developer per sprint; you can always adjust this later.
-
Confirm Team Capacity: Team capacity is calculated as the total number of people hours that the sprint will span. So, for a 10-person Scrum team working 10-hour work days on a 10-day project, the capacity would be 1,000 hours. But, teams usually deduct 20 to 40 percent from maximum capacity to give a more realistic number that takes into account downtime, overhead, and lost working hours. Also, given unavoidable dependencies between backlog items, the practical capacity may be further reduced by a kind of domino effect, in which delayed tasks push back those that succeed them. If any factors are anticipated to affect the sprint velocity or the team capacity, record them at this stage.
-
Review the Definition of Done: The definition of done is a snapshot of what the resulting iteration will look like at the end of the sprint. It’s important that those performing the work and those inspecting it agree on a definition of done before the sprint begins.
-
Decide Which Product Backlog Items Will Go onto the Sprint Backlog: At this stage, the Scrum team will also decide whether any of the backlog items are too large to be completed in a single sprint and need to be deferred.
-
Determine Resource Needs, Outline Who Will Do What, and Estimate the Work Owned: If there’s too much work for the Scrum team to reasonably handle, that will become evident to the Scrum master at this point. Assign the work and ensure that individuals’ assignments match their capacity.
-
Define the Acceptance Criteria: The acceptance criteria are measurable standards for whether a backlog item has been successfully completed. Specifying these criteria is the project owner’s prerogative, though the Scrum team may have some leeway to negotiate via the Scrum master.
-
Confirm and Record Any Assumptions, New Issues, or Dependencies Identified During Planning: This information should be integrated into the product backlog.
-
Call for Consensus: This is the Scrum master’s prerogative. At about the same time, the Scrum team and product owner will indicate whether they think this is the best possible plan for the sprint.
-
Elaborate on the Tasks Involved: If the Scrum team needs more information, especially regarding specificities of items on the sprint backlog, ask any other necessary questions at this point, so you can turn user stories into detailed tasks.
How to Organize and Run a Sprint Planning Meeting
You may be running your first sprint planning meeting or looking to make your meetings more productive. Knowing what needs to be covered is important, but you’ll also want to make sure you have the logistics nailed down and supplies handy.
For a month-long sprint, you’ll need to budget about four hours of time — one hour of meeting time for each week of sprint time. Ideally, you will meet in person, but if you have remote team members, make sure your conferencing technology works well.
For those gathering in person, you need a workspace large enough to accommodate everyone. Have a visual system like sticky notes, a whiteboard, or an electronic tool. (Get a few different colored sticky notes to represent backlog items.) And, since the team is going to be in there a while, you’ll need snacks and coffee to keep people from getting cranky.
Download Sprint Planning Meeting Agenda
Before the meeting gets under way, post the sprint goal and velocity in the meeting room, so everyone can refer to it.
“Sprint planning should be highly interactive,” says Certified Scrum Trainer Adam Weisbart, who has worked with Oracle, Symantec, Hewlett Packard, and Pfizer. “If you use a software tool to wrangle Scrum artifacts, print out your product backlog items and tape them to the wall instead for this meeting. Have people close their laptops and shut off their phones, and have face-to-face conversations around these physical items. You'll be amazed at how much more life this brings to your meeting and your product,” he adds.
Use your sticky notes to document backlog items: Each type of item goes on a different color sticky note. You’ll need at least three colors: one for user stories, one for tasks, and one for bugs. The sticky notes then go up on the wall or board in order of priority. You’ll want to recreate this visual backlog for any remote team members.
When you are ready to start the meeting, open by celebrating what the team achieved during the last sprint to get things started off on the right foot. Next, the Scrum master or product owner will introduce the candidate stories for the sprint backlog, including any left over from the last sprint. If it didn’t happen in pre-planning, the stories will have to be sized, and there are a few ways to do this. Some teams use t-shirt sizing (XS, S, M, M+, L, XL, XXL, XXXL), while others assign story points using the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21).
Regardless of which sizing system you use, the relative values are more important than their raw values. Start with two stories, decide which is larger, then place them in order. Next, take a third story and decide how large it is compared to the other two, add it to the ranking, and so on. The sum of the story points should be less than the team’s velocity. Any product backlog items going to the sprint backlog also need to be validated as being ready to be worked on.
For the Scrum team, parsing each user story can take a long time, and there are a number of steps to consider. For one, is this story up to date, or has its definition changed? Is there new information to consider? Are estimates for the story still valid?
Scrum Master Andrey Grubin of gaming company PlasmaNet says stories should be evaluated in the context of the sprint goal. “Try to determine from capacity, past velocity, and an overall comfort level within the team whether the proposed stories are achievable within the sprint. Don’t hesitate to consult the product owner if there are any questions or concerns around the proposed stories,” he recommends.
Once the definition of the story is fixed, it must be broken down into tasks. (Some of these tasks will become user stories in their own right.) The team will decide what specialist skill sets, if any, are needed to handle these tasks, and will also ask how to test the story.
Just like with story points and velocity, the estimated length of tasks should be less than the team’s capacity for the sprint. Tasks and user stories that are moved to the sprint backlog will be assigned due dates, taking into account the number of working days and whether any team members are going on holiday or will be working on the Scrum team part time.
Remember, it’s not just user stories and their constituent tasks that get space on the backlog; bug fixes do too, so they take up some of the Scrum team’s capacity. But, how does one decide how much space each backlog item gets? One way is to allocate a fixed proportion of capacity — say 20% — to bug fixes. Another is to connect bug fixes to user stories and then size and prioritize them like user stories.
Lastly, the Scrum team, Scrum master, and product owner will create a definition of done, including some sort of testing metric to help ensure the quality of the new iteration.
Ideally, the sprint planning session will conclude by having met some target outcomes. These include the following: having the Scrum team feel comfortable with the goal, and, in turn, having the goal align with the strategic vision and roadmap for a product; adequately documenting the sprint plan; creating a burndown chart (a graph that plots work left to do against time remaining) to show planned work progress; and having each developer on the Scrum team know exactly what they’re going to be working on once the sprint begins.
With the sprint backlog in order and the sprint goal in mind, the sprint is ready to begin.
Sprint Planning for Agile Marketing
While software developers are the quintessential Agile professionals, they’re not the only ones. Many marketing teams are also enthusiastically embracing Agile.
Of course, marketers have no fixed iterations of software to release. What they do have are ongoing (often long-term) projects that comprise a variety of activities. They need to constantly juggle priorities over the short and medium terms, often with a clear objective in mind for each new set of efforts.
So, for marketers, adopting Agile methods is a way to be able to react in a coordinated manner to changing market conditions while maximizing efficiency and moving toward a clearly stated goal.
For the most part, sprints and sprint planning for software development and marketing are very similar. There are a few significant differences, however.
For one thing, the length of marketing sprints tends to be shorter than that of software development sprints. The typical marketing sprint does not take longer than two weeks, while in software development, sprints lasting one or two months are not uncommon.
Second, changes to the sprint backlog during the course of the sprint are more common in marketing than they are in software development. This difference relates to the more rigid constraints imposed by the technical tasks involved in software development, while marketing lends itself to being more fluid.
Third, there are likely to be more wide-ranging specializations in a marketing Scrum team than in a software development Scrum team, since the former encompasses more disciplines.
Best Practices for Sprint Planning
Experts recommend some best practices to get the most out of your sprint planning meeting.
When sending out the invite for the meeting, include the agenda. Also, consider adding a link to the candidate user stories from the product backlog, so the developers have some time to peruse them before the sprint meeting.
When the product owner is preparing a list of candidate user stories from the product backlog, they should select stories totaling more than the Scrum team’s capacity. This is because the Scrum master and Scrum team are likely to reject some user stories or postpone them for a later sprint. If the product owner has picked stories that take up less than the team’s full capacity, rejected stories will result in wasted capacity during the sprint.
Remember that during the sprint planning meeting, it’s the Scrum master, not the product owner, who takes charge. Like the Scrum team, the product owner is more of a contributor to the meeting: Product owners answer any questions the developers have, explain user stories, and negotiate acceptance criteria under the mediation of the Scrum master.
It’s also helpful to remind everyone about how they can contribute most effectively and what they can and cannot expect from other participants. The product owner, for example, takes the lead in creating the sprint goal and is responsible for defining the scope of the sprint, extensively detailing each user story — complete with a definition of done — and prioritizing the product backlog.
The Scrum master arranges the logistics of the meeting and negotiates key metrics, like sprint velocity and practical team capacity. They also take the lead in finalizing the sprint backlog and moderate negotiations between the product owner and the Scrum team.
“The most common mistake made during sprint planning is not having a clear idea about the team's capacity and, hence, ending up with inconsistent velocity, which, again, induces errors on estimated commitments to be made by the team,” says Parashuram Bellikatti, a specialist in Agile transformations and Director of the Global Agile Centre for Excellence in Bangalore.
The Scrum team collates whatever information it needs for the upcoming sprint and commits to a sprint backlog it knows it can reasonably deliver. It’s also the team’s duty to inform the Scrum master if it’s not going to be available at any point during the sprint.
One common source of dysfunction in sprint planning, says Agile coach Kevin Brunner, is the person in charge of the backlog. If they haven’t prepared for the meeting or don’t trust the team to make decisions on its own, the team’s mindset becomes one of avoidance instead of commitment. The developers in particular may complain that the meeting is a waste of time, since the user stories haven’t been fleshed out or since their presence isn’t required because their Scrum master or product owner makes all the decisions unilaterally anyway.
To foster a healthy team dynamic, Brunner says the Scrum master can follow three principles:
-
Visualizing: Fast-forward to the end of a sprint with a successfully completed iteration and work backwards from there to negotiate acceptance criteria and extract the information needed to deliver the completed iteration. Visualizing gives the team the a concrete end product around which its efforts will coalesce.
-
Cultivating: The habit of making team decisions by consensus and listening to and respecting the team members’ input. Cultivation also allows the team the time it needs to make decisions, and ensures buy-in to key aspects of the sprint, such as the scope and time estimates.
-
Reflecting: The habit of looking back at a sprint once it’s over in order to ask what went well, what didn’t, and how things could be improved.
A healthy team dynamic, says Agile coach Tony Solomita, is defined by three habits: preparing the backlog prior to the planning meeting, listening to what everyone has to say in the process of making estimations and finalizing the sprint backlog, and respecting the product owner’s authority over why a particular feature is needed and the developers’ authority over how that feature will be delivered.
Frequently Asked Questions in Sprint Planning
Here are the most frequently asked questions regarding sprint planning:
How are dependencies between tasks best handled? There are several ways to mitigate the potential time-wasting effects of task dependencies. First, task planning during the sprint planning meeting can actively minimize or eliminate complex dependencies as you break down user stories into tasks. Second, you can build buffer time between dependent tasks where possible. Third, the use of loosely coupled, adaptable designs and development techniques, such as mock objects, can help developers cope with the effects of dependencies. And, fourth, having developers work in proximity to one another can preempt dependency-related problems by facilitating communication.
How much should each team member sign up for? Using the yesterday’s weather principle, each team member should sign up to tackle no more than the total number of story points they did in the last sprint.
How are iterations planned if team sizes vary? While recurring changes in team sizes are not ideal, they are sometimes unavoidable. If the size of a team changes, compute the average number of story points tackled per developer in the last sprint, and multiply it by the number of developers participating in the upcoming sprint to obtain a ballpark figure for sprint velocity. You may have to further adjust this figure based on exactly who is leaving and joining the team.
How is overhead, such as time spent in meetings or writing emails, accounted for? There is no rule of thumb for calculating overhead, since it varies from team to team. Most teams simply assume that a consistent length of time is spent on overhead in each sprint and that the sprint velocity of previous sprints accurately reflects time spent on overheads.
How should bug-fixing be accounted for? There are a couple of ways to approach this. One is to treat bugs as user stories, estimating the amount of work involved just like for other items on the sprint backlog. Another, riskier approach is to not assign story points to bugs, which lowers the team velocity. The risk of this approach is that it only works if you perform the same amount of work on bug-fixing in each iteration. If the amount of work on bug-fixing varies, the velocity will change drastically from sprint to sprint, making planning for future sprints much more difficult.
Why should iterations always be the same length? The answer, in a nutshell, is rhythm and consistency. The sequence of a sprint proceeds much more smoothly if it follows a regular, easily predictable cycle, which greatly simplifies sprint planning.
How is time spent on testing and documentation accounted for? The easiest way to do this is to include time spent on testing and documentation as a separate task for each user story. An alternative is to create a separate item on the sprint backlog for testing and documentation.
Should feature estimates be revised during iteration planning? Only if the original estimate is wildly inaccurate.
Should task estimates be revised during an iteration? No. Once you’ve completed iteration planning, leave the task estimates as they are. Of course, the Scrum master will likely make a note of why the team chose to change a task, so they can reflect this information in future sprint planning..
Should all teams operate on the same iteration schedule? This depends on the number of Scrum teams working in tandem and the availability of supporting staff. If there were no constraints on having multiple teams work on iterations that started and ended at the same times, the resulting synchronization would be of great benefit for management. It would reduce the risk of one team's work forcing changes onto another's sprint backlog, since teams would coordinate with one another regarding their sprint planning. In practice, however, Scrum teams do not work in isolation, and there are a limited number of people who fill supporting roles across multiple Scrum teams and appreciate iterations with staggered start and end dates.
Common Sprint Planning Mistakes and Warning Signs
The experienced Scrum master knows the warning signs that indicate sprint planning isn’t going as well as it should be. Here’s what to look out for.
If a team repeatedly fails to complete its sprint backlog — if they continually push user stories into the next sprint — that’s a sign that the group is overestimating its own velocity and overbooking itself. To ensure that planning is accurate (and actually useful), the Scrum master will need to adjust the Scrum team’s velocity downwards.
If, however, the same features are being pushed repeatedly into the next sprint, the team is likely deliberately avoiding tackling certain user stories or bug fixes. This situation merits an exploration of whether there are issues around these user stories or bugs that are not being raised during sprint planning.
A failure to complete the sprint backlog could also point to overdesigning, which is a case of the developers going above and beyond in their work, effectively doing more than is necessary. This would prompt a review of the requirements for requested features to make sure the team isn’t expending any unnecessary effort.
What Not to Do: Typical Mistakes in Sprint Planning
A sprint planning session can be sabotaged by some common pitfalls:
-
The Product Owner Creates the Sprint Backlog on Their Own without Input from the Developers: This commits the Scrum team to a backlog they had no say in creating. It reduces both their engagement with the planning process and the likelihood that the sprint will meet its stated goal.
-
The Scrum Master Shows the Candidate User Stories to the Developers for the First Time at the Sprint Planning Meeting: A needless waste of time, this makes planning meetings drag on much longer than they should. Provided you’ve groomed the backlog, it’s quite straightforward to include the candidate user stories in the agenda for the meeting. Having user stories that do not meet the INVEST criteria will lead to similar problems.
-
The Team Doesn’t Settle on a Definition of Done: When this happens, the team delivers a product that is incomplete at the end of the iteration. A sign that this problem may be looming is not having all the items on the sprint backlog split into a series of manageable tasks.
-
Subtasks Aren’t Thoroughly Estimated: You may spot this problem when tasks do not seem to be estimated accurately relative to one another. (A very complex task is not a big enough multiple of a simple task.)
-
The Scrum Master Takes Too Long to Collate the Sprint Backlog into an Electronic Tool: This can mean that the Scrum team works blind for the first days of the sprint, unable to see its true progress.
-
The Candidate User Stories Aren’t Discussed with Other Stakeholders before Being Added to the Sprint Backlog: Again, this type of mistake invites unhappy stakeholders to request that the backlog be changed after the sprint has gotten underway. Some product owners may do this too, even after they’ve signed off on the original sprint backlog, and it can be very frustrating. For some Scrum teams, a degree of change to the backlog may be virtually unavoidable. If this is the case, there are a number of possible remedies. One is to increase the length of the sprint or intentionally underestimate the sprint’s capacity so that there’s more leeway should work need to be added. For teams whose work is frequently interrupted, the best solution may be to simply roll with the punches and reduce the amount of time spent on sprint planning, since the activity cannot truly serve its intended purpose.
-
The Scrum Team Does Not Detail Tasks and Subtasks Adequately: This is usually a sign that the team is bored by planning and just wants to get going. Inadequate detailing runs the risk of throwing estimates out of whack when developers discover that tasks were more time consuming than they anticipated.
-
Members of the Team Are Reluctant to Discuss Steps: This robs the rest of a team of the opportunity to learn.
-
The Team Does Not Have a Scrum Master to Take Charge of Planning: Without a Scrum master to control the pace of the planning session, everyone will seek to get it done as soon as possible, which may result in either a frustratingly ineffective planning session or the skipping of key details.
Improve Sprint Planning with Smartsheet for Project Management
From simple task management and project planning to complex resource and portfolio management, Smartsheet helps you improve collaboration and increase work velocity -- empowering you to get more done.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.