The Scrum Team’s guide to Sprint Planning

Agile methodologies are on the rise. In the 15th State of Agile Report, Digital.ai revealed that Agile adoption jumped 49% among software development teams between 2020 and 2021. Last year, 37% of software development teams used Agile methodology. By 2021, that figure had jumped to 86%.

The authors point to volatile, unpredictable working environments as the main reason so many teams have recently adopted Agile.

Among Agile methodologies, Scrum is the leading framework. The fact that software development is so unpredictable points to the deep need for effective planning.

This article will guide you through everything you need to know about an essential component of the Scrum framework — Sprint Planning.

What is Sprint Planning?

Sprint Planning is the process of deciding what work the team will take on during a specified chunk of time. Scrum Teams work in time-boxed iterations called Sprints, which usually last two weeks to a month. Sprint Planning is one of the four types of Scrum ceremonies. (The other three are Daily Scrum, Sprint Review, and Retrospective.)

Sprint Planning isn’t a standalone meeting that happens once at the start of a project (like the project kick-off). Rather, it’s a recurring meeting that takes place with every Sprint.

Who’s involved in Sprint Planning?

As the official Scrum Guide says, Sprint Planning is a collaborative effort that involves the entire Scrum Team. The Scrum Team consists of these three roles:

1. The Product Owner
2. The Scrum Master
3. The Developers

The Product Owner acts as a liaison between the business side and the development side. They’re accountable for representing the needs of the stakeholders and managing the product backlog so that the business objectives and the work of the developers are aligned. The Product Owner ensures that the entire Scrum Team is delivering as much value as possible.

The Scrum Master sees to it that the Scrum Team is working as effectively as they can. The way that they do this is by implementing Scrum. They coach the Developers, the Product Owner, and even the entire organization so that everyone has a firm grasp on Scrum theory and practice.

The Developers, or Development Team Members, are self-organizing and cross-functional individuals whose responsibility is to deliver value through the Sprint. They execute the plan. “Developers” doesn’t just refer to engineers either. A Developer can be a designer, a writer, a programmer, and more.

Best practices for Sprint Planning

Timebox your meeting.

As a rule of thumb, the meeting should be limited to two hours per week of iteration. For example, if your team works in two-week Sprints, set aside no more than four hours for Sprint Planning.

Leave enough wiggle room in your plan.

It’s tempting to use Sprint Planning to pump out the most detailed plan you can. After all, as Benjamin Franklin said, “If you fail to plan, you are planning to fail.” We’re here to tell you: Don’t get caught up in the fine details.

Instead, implement just-in-time planning (JIT). With JIT, the team plans just enough to get started. Remember: Agile is partly about letting the work emerge over the course of the project. New information and insights pop up every day.

Sprint Planning process

Here's what to do before, during, and after your Spring Planning meeting to help ensure success.

Before the meeting

First up, we have the prep work: backlog refinement. During this step, the Product Owner adds clarity to the Product Backlog and decides which items should be prioritized for the next Sprint. These items should meet the team’s “definition of ready.”

Here’s what backlog refinement can look like:

• Saying goodbye to irrelevant or obsolete backlog items
• Rearranging items according to priority
• Estimating items (assigning story points)
• Breaking large items into smaller, manageable items
• Adding clarity to relatively vague items

Even though the backlog refinement step is the Product Owner’s responsibility, the Product Owner can involve other team members for additional insight and assistance.

Now is also the time for the Product Owner to verify everyone’s schedules, checking for upcoming holidays, vacations, etc. They should gauge the team’s capacity, which means approximating how many hours everyone will dedicate to the upcoming Sprint. Clockwise makes this step easier through Team Analytics, a feature that gives insight into how much Focus Time and meeting time your team members have.

If this isn’t your team’s first time working together, it’s also a good time to estimate velocity, the rate that your team completes work.

Now, create and send out an agenda to attendees. That concludes the pre-planning phase!

At the meeting

First, the Product Owner proposes Product Backlog Items for the upcoming Sprint — and their reasoning.

The rest of the team offers their feedback, explaining why the team should or should not include the proposed items in the Sprint. If they agree with the Product Owner’s proposal, what are the steps they’ll take to tackle the items?

And if they don’t agree with the Product Owner’s ideas, why? Does an item need to be broken down further? Are details still fuzzy after backlog refinement? Are there dependencies that haven’t been identified?

As the team negotiates, they take items off the Product Backlog and transfer them onto the Sprint Backlog. By the end of the meeting, the Scrum Team will have three things: a clear Sprint Goal, the Sprint Backlog, and a plan for how they’ll get started.

Sprint Planning tools

To plan for your next Sprint, here’s what you’ll need:

1. Meeting agenda, so that your team can prepare for the Sprint Planning meeting, thus saving time
2. Team schedule, so you know everyone’s availability for the Sprint
3. Video conferencing software if your team is remote
4. A physical or virtual board to visualize the work

Moving forward

If we had to choose, there are three points we’d like to leave you with as you prepare for your next Scrum project or Sprint Planning session:

1. Remember that Sprint Planning is collaborative,
2. Don’t waste time planning the entire Sprint, and
3. Keep in mind that Scrum is meant to be a learning process.

Trust that your team will find its rhythm!

‍