Everything You Need to Know About Sprint Planning

Sprint planning is often easier said than done, unless you’ve got some experience under your belt. A sprint can easily go off track and take a big bite of your budget without fulfilling the goal set. On top of that, bad sprint plans can have a downstream effect on your project operations. We’ve prepared this guide, so you could get better at sprint planning from day one. 

• What is sprint planning
• Roles involved in agile sprint planning
• Choosing the right length for the sprint
• Preparing for the sprint planning meeting
• How to run an agile sprint planning meeting
• Key takeaways

What is sprint planning? 

Sprints have proven to work for thousands, if not millions of teams already, fostering people to get more done and management to fast-forward their inert projects. Once you get it right, the benefits of implementing agile practices won't be long in coming. During the last couple of years, agile has helped many organizations manage changing priorities and improve project visibility among other benefits, such as business alignment, time to market, and increased team productivity. More importantly, 26% of organizations participating in 2020’s Annual State of Agile Survey also noted project cost reduction as an important reason for adopting agile.

What is a sprint?

First things first, a sprint is usually a two-week period of time during which specific tasks must be completed based on what the team has prioritized to deliver to the end user soon. In our previous article, we’ve related a number of reasons why you should work in agile sprints. It’s important not to forget that the main purpose of sprints is to deliver frequently. Before cutting to the chase of how you can streamline sprint planning and increase your team’s speed, let’s look into what sprint planning is.

Sprint planning explained

Sprint planning is a meeting dedicated to one of the Scrum ceremonies, where the team collaborates to agree upon work it’ll be able to complete during the upcoming sprint. Sprint planning sessions are needed to set the foundation for the project and drive the team’s boat at the most optimal pace during the next couple of weeks. To run a successful sprint, you’ll need to know how to organize work and plan activities that can be finished in a short period of time. The purpose of a sprint planning meeting is to identify the sprint goal and sprint backlog.

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

What happens during the sprint planning meeting? Let’s say you’re planning to develop a new important product feature or work on a marketing campaign. During the sprint planning session, the team members will have to ‘groom’ the backlog and say which tasks they’ll work on.

You might think that planning for the next couple of weeks is the easiest thing you’ve ever done. But there’s another side of the coin. The work you’ve planned must fulfill the goal set. This can only happen if you have a healthy backlog. According to Atlassian, a healthy backlog carries out three things:

• Prioritizes each work item, with the most important work listed at the top
• Includes fully-formed user stories the development team can begin to execute on
• Contains an up-to-date estimate for each work item.

Pay attention: To cover a two-week sprint, consider holding a two-hour sprint planning meeting. Ideally, the meeting should be held early in the week so as not to disrupt the team’s flow by the weekend. The question is, who should be present at your sprint planning meeting?

Roles involved in agile sprint planning

Generally, the key roles involved in agile sprint planning – the product owner, scrum master, and the team all need to attend, especially if it’s part of the agile process in software development companies. Let’s take a look at each role.

The Scrum Master: Facilitates the meeting

The scrum master’s role in sprint planning is to make the meeting go as smooth as possible. They book meeting rooms, provide the supplies, align people who participate, make sure that connectivity is in place, and get rid of all potential distractions that could hinder the process. In simple words, they clear up the way for teams to focus on the most important thing – the backlog and the very planning and prioritization. They should also identify the length of the sprint and the best time to hold a sprint planning meeting.

The Product Owner: Clarifies the details of the product backlog

Product owners make sure that the teams have a healthy backlog of items to work on before the sprint planning meeting begins. They are the ones who refine the details on each backlog item and answer related questions coming from the team. Product owners need to spend more time to prepare the sprint planning agenda than other participants, as their role is to prioritize. 

The Team: Defines the work and effort

Teams also perform a critical role in the sprint planning session, as they actually get work done. They should be in full attendance for the meeting and put their heads together to contribute to the estimation and forecasting process as much as they can. Specifically, they will determine how many of the product backlog items they will be able to complete and elaborate on how they will deliver those product backlog items, so each team member can leave with a clear understanding of priorities and what needs to be accomplished during the next sprint.

Choosing the right length for the sprint

How your team eventually performs will depend on many things, the length of the sprint being one of the key factors. There is no one-size-fits-all sprint length though. While Scrum originally encourages teams to work in one-month sprints, many software development teams decided in favor of shorter ones to increase velocity. Velocity is the key metric in scrum, reflecting the amount of work the team can tackle during a single sprint. Thus, working in two-week sprints has become the new game for many. Some teams even switched to one week to get new updates to the end users faster, which is considered to be the shortest agile sprint duration.

That’s why before running a sprint planning meeting, you should choose the right length of the sprint optimal for your team. The length of the sprint depends on team velocity you have at this moment. Adopting the agile approach to work, you most likely want your teams to become faster. We recommend the following length for different types of teams, based on the processes they used before the change: 

• 1-week sprint: For teams that are used to fast-paced work and agile environment and are able to produce product updates and new features in a week.
• 2-week sprint: An optimal speed for every team that wants to work in sprints and increase velocity. 
• 3-week sprint: For teams that aren’t used to fast-paced structured work.

Teams that worked in silos before and were not set for speed and efficient collaboration would prefer the longer sprint length and then shift to shorter sprints.

Let’s take a look at the advantages and disadvantages of shorter and longer sprints respectively.

Shorter sprints

One and two-week sprints open the window of opportunities to learn more with less time. The main advantage of shorter sprints is that they help the teams reveal problems faster. This way, the work is reviewed promptly and teams receive more feedback to improve on the results of their tasks. As the work is broken down into the smallest chunks possible, teams can prioritize more efficiently.

The main disadvantage of shorter sprints (especially 1-week) is that they might be too stressful in the beginning, requiring laser focus and concentration. The good thing is that most teams get used to it after 3-4 sprints.

Longer sprints

The advantage of having sprints that last for three or four weeks is that one doesn’t feel stressed starting out in Scrum. 

The disadvantages of longer sprints, though, manifest themselves in fewer opportunities to improve work processes and slower pace in general.

Running an experiment 

It always makes sense to experiment until you find the best duration for your context. If you do, you’ll see the results and get feedback from your team immediately. It’s a common practice to start with two-week sprints and move from there. 

If you’re satisfied with team velocity and everyone is close to reaching sprint goals, but the progress on the product is far from being meaningful, the sprint length you’ve chosen is probably too short. Try to lengthen the sprint and see what happens.

If the team finds it difficult to reach the sprint goals because saying other important things pop up all the time, then you may have chosen sprints that are too long. Shorten them up to one week and monitor the speed.

Hopefully, you won’t have to deal with two problems above, which means that your team can work productively in two-week sprints.

There’s a 4 sprint rule relating that teams usually adapt to the new Scrum practice in four sprints. If after 4 sprints the team team doesn’t produce good results and feels unhappy, the chosen duration should be discontinued in favor of a shorter or longer sprint.

Preparing for the sprint planning meeting

Tim Snyder, Software Delivery & Agile Transformation Leader at USAA cautions teams against doing sprint planning around backlog items that have not yet been refined. Not doing backlog refinement prior to sprint planning and therefore needing to do it in sprint planning, according to the expert, is one of the mistakes product managers commit not knowing enough about the craft. 

Preliminary planning is recommended to streamline the sprint planning meeting and prevent it from stretching for hours. Splitting the planning process into two parts, you make sure it’s not overly long and everyone is engaged. It also gives you enough time to make all the necessary steps to get ready for the sprint, like reviewing the roadmap, grooming the backlog, and proposing the next sprint goal. 

Experienced product managers prefer to do backlog refinement outside sprint planning. If you’ve decided to work in 2-week sprints, you can divide the planning process into two sessions. At the first one, spend an hour for pre-planning. Sit with a team to prepare a backlog, add new stories and epics, and also estimate the effort a day prior to the actual sprint planning meeting. 

Forecast tip: Some teams struggle with estimation. Work in sprints in Forecast and make more accurate task estimates. The AI will do the math for you based on historical data.

If you don’t use any tool to help you make estimations, then an alternative would be to play sprint planning poker, where the team votes for specific estimates to achieve consensus and discusses why a user story takes this amount of time.

How to run an agile sprint planning meeting

What happens during the sprint planning meeting if you’ve already refined the backlog? As the backlog is groomed, you can now start tackling which tasks the team will be focusing on during the sprint. Collaborating together, the team and the product owner figure out the task with the highest priorities, based on the level of business value they are supposed to generate. Here’s what should be on your sprint planning meeting agenda.

1. Share the sprint goal

Sticking to the outcome you’d like to achieve is a good way to start the meeting. Explain the high-level objective of the sprint and what you’d like to attain in the end. This will help you prioritize between the backlog items as your next step. Marketing teams can focus on the exact numbers of leads and revenue, while development teams might benefit from working with user stories that describe work from the customer’s point of view.

Before specifying the goal, always make sure that it follows the SMART framework, meaning it’s Specific, Measurable, Achievable, Realistic, and Timely enough. A good sprint planning meeting provides an environment where the team is motivated and accomplishes the goals defined. In contrast, a bad meeting sets unrealistic expectations and prevents the team from performing well. 

Now think, does the team leave the sprint planning meeting with a clear upfront understanding of the sprint goal? We can’t stress enough how important it is that everyone can 1) describe the goal of the sprint and 2) interpret how they will start working toward that goal. Not only the sprint backlog can make it visible. Look for any signs of non-verbal communication that could reveal uncertainty. Sometimes they can tell a world of difference. Asking about any concerns will help you nail it down and further promote the culture of openness.

2. Move work from your Product Backlog to Sprint

Next comes the prioritization of product backlog items that fulfill the sprint goal. Once the team has a shared understanding of the sprint objectives, select items from the backlog that go in line with the established sprint goal. Start from the lowest-hanging fruit that you all believe will provide the most value to the end user. If there’s additional capacity available, you can prioritize other tasks as well. 

It happens that sometimes during a sprint planning session the team cannot agree on priorities. If that’s the case, it’s good to start asking the following questions to get the team back on track:

• Which items contribute most to our Sprint goal?
• Which backlog items increase customer value the most?
• Which items promise to be the most beneficial to the business?
• Which items are riskier than others?
• Which items may turn out more expensive later if not done now?
• Which items can be completed, considering the dependencies?
  

It’s easy to get bogged down in the details of the ‘project management’ work ignoring high-level objectives and true customer wants. To keep them in mind when discussing the backlog items, user stories are recommended. They describe the work from a pure customer perspective and shift the focus from issues to outcomes. Try filling in this pattern below:

As <type of user>, I want <a goal> so that <a reason>

This line is popular for a reason. It prevents client expectations from being articulated in a vague, fuzzy way. You’ve probably noticed that filling in the answers, you immediately add a measurable result to the user story and achieve transparency needed to complete work.

3. Assign the scrum team to tasks

This part of the sprint planning session is all about capacity planning. Let the team decide who wants to work on what, based on their experience and roles in the company. Don’t forget to take into account vacations, holidays, or any other circumstances that can disrupt the flow. If the team members have already been assigned, make sure everyone knows if there are dependencies between the items.

Do capture the information in your collaboration tool. Sprint planning can entail a lot of administrative manual tasks, as many teams still use spreadsheets to track their work and thus increase the number of unnecessary data entry points. Trust us, this is not where you’d like to spend time. Having one centralized platform for collaboration company-wide will help you capture and update the information in a few clicks, at the same time keeping everyone on the same page and promoting visibility into crucial processes. Check out these benefits of using project management software and how it pays off.  

4. Set dependencies

Create dependencies between tasks so the team knows the sequence in which they should be accomplished. Experts believe that the less dependencies you create, the better chances the feature will be completed within sprints. If you can’t cut down on dependencies, Forecast has sprint planning tools that allow you to easily build colonies of interdependent tasks.

5. Measure the velocity of your scrum team 

As a manager, you’ll also need to figure out how to measure the velocity of your scrum team and notify the team to give them an additional motivating factor to move on faster with their work. Velocity is the amount of work completed in a set of time that can be measured in hours, story points, or number of tasks. There are multiple ways to measure the running pace and Forecast is one of them. The platform will track it automatically when your teams log time and move tasks to Done. Another common way is to use a burn-down chart. Tracking the velocity daily, you can estimate how much work the team can manage to do in a longer time. 

Scrum sprint planning is a craft, so everyone gets better at it with time and practice. Agile encourages constant improvement, so don’t be upset if your first sprint planning meetings didn’t go as you expected. You’ll learn by doing and tailor the best way to work in sprints in your team. To wrap it up, there are a few key takeaways important to remember.

Key Takeaways

• Set 1 hour per week for the sprint planning session. If the sprint length is two weeks, spend 2 hours respectively.
• Don’t set the sprint length of more than 4 weeks (it’s not a sprint).
• Ideally, schedule sprint planning early in the week. Then the team’s context and flow is disrupted less by the weekend.
• Consider having a pre-planning session to refine the backlog and sprint planning session the next day to discuss priorities and move items from backlog to sprint.
• Make sure the sprint goal is specific, measurable, achievable, realistic, and timely.
• Prioritize backlog items based on customer value and attainability.