Resources > Glossary > Agile & Development > Sprint Planning

Agile & Development: Sprint Planning

What Is Sprint Planning?

In the Scrum agile framework, a sprint planning meeting is an event that establishes the product development goal and plan for the upcoming sprint, based on the team’s review of its product backlog.

A successful session will yield two important strategic items:

  1. The sprint goal: A short written summary of what the team plans to accomplish in the next sprint.
  1. The sprint backlog: The list of stories and other product backlog items the team has agreed to work on in the upcoming sprint.

What Details Are Prioritized During a Sprint Planning Meeting?

The objective of sprint planning is to work out the key details regarding the team’s planned work during the next sprint. With that in mind, the sprint team should plan to address at least the following issues during this meeting.

In fact, you can use the following items as the foundation of your team’s meeting agenda:

  1. Decide on the team’s overall strategic objective for the next sprint. (This will be represented as the one- or two-sentence sprint goal.)
  2. Review the product backlog and discuss which items belong on the next sprint backlog and why.
  3. Call for a team consensus on the proposed sprint goal and backlog items (led by the scrum master).
  4. Discuss team capacity.
  5. Discuss known issues that could disrupt or slow progress on the sprint backlog.
  6. Assign the new sprint backlog’s tasks, according to skill sets, capacity, and other relevant criteria.
  7. Estimate the timeframes for each of the tasks assigned and agree on what “done” will look like for each item.
  8. Confirm the timeframe of the upcoming sprint.
  9. Open the meeting to sprint-related questions. (The product owner should be responsible for coordinating this step, to ensure the discussion stays on track.)

Pro tip: To ensure the sprint planning meeting is as productive as possible, it is important to have a well-groomed product backlog. This will reduce confusion during the meeting and will help the team make better-informed decisions about which items to prioritize for the sprint backlog. For these reasons, one best practice is to hold a backlog grooming session before your sprint planning.

How Long Should a Sprint Planning Session Take?

The Scrum framework suggests that sprint planning should be time-boxed, meaning the team should set an upper time limit for each planning session — usually one or two hours for every week of sprint time.

If a company chooses an hour of planning per sprint week, and it operates on two-week sprint cycles, then each sprint meeting should be no more than two hours.

Who Is Involved?

Although sprint planning sessions can at times benefit from input from various members of an organization, the key participants in any sprint planning session will be:

  • The scrum master (who typically runs and coordinates the meeting)
  • The product owner (who will explain the product backlog items, answer backlog questions, and help define the sprint goal)
  • The product manager (who might also be the product owner, but not necessarily)
  • The development team (who will make commitments to the work, estimate timeframes, and explain any capacity or skill-set issues that could prevent work from getting done)

Pro tip: To get the most strategic and creative input from the organization’s development team, it is advisable to bring the product roadmap to sprint planning meetings, not only the product backlog. This will help ensure the development team has more of a big-picture view of the company’s strategic vision for the product, which will help them make more of a strategic contribution to the session.

A Valuable and Efficient Product-Development Session

Even for an organization that doesn’t operate on the Scrum agile framework (but especially for those that do), sprint planning can be an extremely efficient mechanism for moving product development forward.

Building sprint planning into the company’s culture forces the cross-functional team to regularly review its product backlog — and to keep the backlog from becoming a black hole. It encourages the team to frequently review and identify the most strategically advantageous development work to undertake next. And it gives the entire team an opportunity to meet regularly to ask questions, discuss issues, and celebrate the completion of important work.