What is Sprint planning?

The Sprint plan is the event used in Scrum to start the Sprint. The goal of iteration planning is to define what the Sprint can deliver and how the work will be done. Iterative planning requires the entire Scrum team to work together.

Unlike the final sprint in sports, the Sprint in Scrum requires the team to be on top speed all the time to deliver working software, while learning and improving all the time.

In Scrum, the Sprint is a period of time when everything gets done. It’s just that before you start, you need to set Sprint conditions: for example, you need to decide on the length of the time cycle, Sprint goals, and where to start. The Sprint plan is organized around the tasks and priorities of the Sprint. If well organized, Sprint planning can also create an environment that is passionate and challenging and leads to success. Poor Sprint planning can lead to team failure by setting unrealistic goals.

  • What to do — The Product Owner explains the Sprint goals and the PBI that will help achieve them. The Scrum team then decides what needs to be done in the upcoming Sprint and what needs to be done to achieve the Sprint goals.
  • How – The development team plans the work based on the Sprint goals that need to be delivered. The development team and the Product Owner agree on a Sprint plan based on value and effort.
  • Who will do it — Sprint planning must involve the Product Owner and development team. The Product Owner sets Sprint goals based on the value orientation of the Product. The development team needs to figure out if that goal can be achieved. Both must be involved, and the absence of either will result in the failure of the Sprint.
  • The input — Product Backlog is a very important starting point for Sprint planning, as it provides the “basic features” table that may become part of the current Sprint. In addition, the team also needs to look at the work done in the increment to see progress and the amount of work remaining.
  • Output — The most important purpose of the Sprint planning meeting is for the team to explain the Sprint goal and how to achieve it. These will be reflected in the Sprint Backlog.

Advance preparation for Sprint planning meeting

There are some basic requirements for a great Sprint. The Product Owner should be prepared to lay the foundation for the Sprint, combining lessons learned from the previous Sprint Review meeting, stakeholder feedback, and their vision for the Product. In terms of transparency, the Product Backlog should be updated to ensure clarity and accuracy. Backlog Refinement is an optional event in Scrum because some backlogs do not need to be combed and optimized. But for most teams, it’s best to get the team together to review and optimize the backlog before the Sprint planning meeting.

Expert tip: Hold a backlog clearing meeting in the middle of a 2-week Sprint. It’s good for the team to think beyond the current Sprint to the next. This not only prepares you for Sprint planning, but also provides a different perspective for evaluating your current efforts.

Limit Sprint planning time

Sprint planning should be limited to two hours per week. So, for a two-week Sprint, the planning session will last no more than two hours. This is called timeboxing, which sets the maximum amount of time a team can take to complete a task, and in that context, plans the Sprint. The Scrum Master is responsible for ensuring that meetings are completed within the specified time. If the team achieves satisfactory results within the time limit, the meeting is considered to have been completed successfully. The time limit only emphasizes the maximum time, and there is no limit on the minimum time.

Expert tip: Make Sprint goals the focus of Sprint planning and don’t focus too much on Backlog details. Focusing on the goal rather than the specific task gives the team more energy to find the best way to achieve the goal.

Focus on the results, not the work

When planning a Sprint, it’s easy to get bogged down in the details of which task should be done first, who should do it, and how long it will take to complete it. For more complex work, the initial information is limited, and most of the judgment is based on assumptions. Scrum is a completely experience-based process, which means that a lot of work cannot be planned in advance, but rather learned by doing and fed back into the development process. Sprint goals represent Sprint goals at a high level, and backlog lists can be written with a results-oriented mind. User stories are a great way to describe work from a user’s perspective. As shown in the figure below, the user story should focus on flaws, problems, and improvements to what the customer ultimately wants to achieve, rather than observed problems.


Experts say that being unsure of something is not the same as keeping it in the dark. Don’t ignore the unknowns, because they are the hard work the team must do on the ground. But don’t cover them up or hide them with vague descriptions. Instead, when you don’t know something, acknowledge your ignorance and list it as a job to learn more about.

Estimation is necessary, but it does not mean pretending to know the unknown

Sprint planning requires a degree of forethought. The team needs to be clear about what can and cannot be accomplished in the Sprint: estimated and actual workload. Workload estimates are often confused with commitments. Projections are essentially predictions made by the team based on current knowledge. Methods of measuring workload, such as Story points and T-shirt sizing, provide teams with different perspectives to analyze and view problems. They are not artifacts that can help the team discover the truth without having enough information. Therefore, the more unknowns there are, the less accurate the estimates will be. Good estimates are based on an environment of trust, where the team can freely exchange information and test hypotheses through continuous learning and improvement. If the previous estimate turns out to be wrong after the work is done, the later estimate will either be much larger to make sure it doesn’t go wrong again. Or take longer to estimate so you don’t get it wrong again.

Experts suggest teams try different estimation methods, such as T-shirt sizing or story points. Because different methods analyze the problem from different angles.

Sprint planning best practices

During Sprint planning, it’s easy for teams to get “bogged down in detail” and forget that the whole point of Sprint planning is to have a “just right” plan for the rest of the Sprint. Planning should not be a burden on the team, but should help the team focus on valuable results and ensure that the team stays on track. Good Sprint planning succeeds by defining the results of the output and having a clear plan. But be careful to overdo it. In Sprint planning, focus on goals and a nice Sprint Backlog, not a comprehensive, minute-by-minute work plan for the Sprint. The next step is to prioritize the Product Backlog so that when the team is ahead of schedule with their Sprint goals, they can move on. Scrum is a process framework designed to solve complex problems that require an experiential process (learning by doing). It’s hard to plan ahead, so don’t delude yourself — and admit that you can’t plan perfectly. Instead, focus on the results and get down to work. Even when we’re trying to solve very difficult problems, getting started can be easy.


Worktile’s website: Worktile.com

Contents: Worktile

This article was first published on Worktile’s official blog.