How to Run a Successful Sprint Planning Meeting

Share article

sprint-planning

Read other Exadel articles about Agile approach

Successful delivery is impossible without thorough planning, especially in a complex environment. Proper planning is a core of any agile delivery services. High-quality iteration planning is important for the whole Team because it helps all members collaborate effectively. Many teams are implementing Scrum. In this article, we discuss how to run a successful Sprint Planning Meeting.

What is a Sprint Planning Event?

According to the Scrum guide, “Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.”

Essentially, Sprint Planning is when the entire Scrum Team meets to establish the Goal for the upcoming Sprint. They decide which Product Backlog items should be executed to meet the goal and how to execute those items effectively.

If you would like to check how good your Sprint Planning events are, try our Assessment. This Sprint Planning survey will help you understand the strengths and weaknesses of your events so that you can improve the quality of Sprint Planning Events. If you have any questions or need advice in carrying out successful Spring Planning, contact our Agile Delivery Team.

Who runs the Sprint Planning Meeting?

It involves the whole Team, including the Scrum Master, Product Owner, and Developers.

The Scrum Master’s duty is to organize every aspect of the Sprint Planning Event — where, when, and how it will be held and how long it will last. The duration of a Sprint Planning Meeting depends on the length of the Sprint. If you plan the Sprint to last for four weeks, the Sprint Planning Meeting will take up to eight hours; for shorter Sprints it usually takes less time. The Sprint Planning agenda should be presented to the whole Team before the meeting.

How to Run a Successful Sprint Planning Event: Preparation

First, the Product Backlog should be “ready.”

The role of a Product Owner is to maximize product value. All ideas for value maximization live in the Product Backlog. Some Backlog items may not be completely clear, so it’s a good habit to align the understanding of the Scrum Team and make sure that Product Backlog items are ready to be taken into the upcoming Sprint. This process is known as Product Backlog Refinement. During Product Backlog Refinement, the Product Owner makes sure that the Product Backlog items are “ready”. By “ready,” we mean the Definition of Ready. The Definition of Ready is a checklist that represents all the characteristics an item must have to be “ready” to be taken into the Sprint.

If you don’t refine Product Backlog items in advance, then you will probably have to allocate time for this process in the Sprint Planning Meeting.

Second, make sure that Scrum Team capacity and velocity are prepared.

Velocity is a complementary metric in Scrum. It is the number of story points completed in each iteration. By studying historical data from previous Sprints, you can calculate the average Sprint velocity simply by adding all the story points from Sprints and dividing that by the number of Sprints. This number is a reference point for the Team to plan for the Sprint ahead. Let’s say for the last 6 sprints, your Team completed: 54, 62, 58, 60, 61, 58 story points. Then the average number of story points is 59.

Velocity may also give a clue as to how many Sprints we need to complete a feature or epic and help the Product Owner understand when the next version of the Product can be released.

Team capacity is another complementary metric for Sprint Planning. It shows the time available for a Developer to sprint. For example, a Sprint lasts 10 days, and we are spending 6 hours per day on the Sprint, so capacity equals 60 hours for one Developer. We also need to take into account bank holidays and planned vacations when calculating capacity, so there will inevitably be some variation. This is why it’s important to measure capacity in order to make realistic forecasts for Sprint Planning.

Third, make sure the Definition of Done is clear and that everyone on the team understands it.

Definition of Done is a list of requirements that should be achieved before a Product Backlog item can be considered completed. It includes non-functional requirements, as well as process-related requirements.

Usually, development organizations provide an initial Definition of Done, and each Scrum Team adapts it for their particular Product.

Example of a Definition of Done:

  • Code coverage is at least 85%
  • Code is documented
  • No high priority and critical bugs found
  • System response time is less than 50 ms for 1000 users

Fourth, think about the audience.

The Scrum Team may also invite other specialists to join the Sprint Planning Meeting and provide advice, if needed. Discuss within the Scrum Team who should attend and when.

Fifth, think about additional tools needed for the Sprint Planning Meeting

COVID-19 has changed our lives, meaning so many things have moved online. Many teams use online boards (tools like Miro and Mural), online estimation tools (PlanITPoker), online meetings, and more. All of these tools should be prepared, shared, and accessible to Team members.

What Happens During a Sprint Planning Meeting?

According to the Scrum guide, the event should cover the following topics:

  • Why is this Sprint valuable?
  • What can be done during this Sprint?
  • How will we complete the designated work?

Let’s clarify what this means step by step and how to run a Sprint Planning Meeting.

Step 1: Set the Sprint Goal

First, the value of the current Sprint should be defined at Sprint Planning. The Product Owner suggests ways in which the Team can increase Product value in the current Sprint. Ideally, the Product Owner is supposed to suggest a small step from the product roadmap aligned with the product vision and strategy as a candidate for the Sprint Goal. Having discussed the technical feasibility, any possible trade offs, and hypotheses for experiments that could help in taking that step, the Scrum team crafts the Sprint Goal. The Sprint Goal is the single objective for the Sprint. It should be described in one sentence and explain to everyone why the Sprint is valuable.

The Sprint Goal is a commitment for the Developers, but it provides flexibility in terms of the exact work needed to reach the goal. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be harder than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog without affecting the Sprint Goal. Developers don’t do anything that can endanger the Sprint Goal and only work on tasks that help achieve it.

This will help the Team concentrate on development, work together rather than on separate initiatives, and stay focused on outcomes.

Bear in mind that the Sprint Goal is the main indicator for the whole Sprint. While burndown charts and other tools have proven their effectiveness, the main measure of success is achieving the Sprint Goal.

So how do you set a good Sprint Goal?

At Exadel, we think that every Sprint Goal should be SMART – specific, measurable, attainable, relevant, and time-bound. For example, instead of “improve performance,” use “increase page load time by 50%.”

And remember — Agile is a means to achieve the goal, not the goal itself. We use it to improve business performance, so the Sprint Goal should focus on business value.

Step 2: Plan How to Achieve the Sprint Goal

The second step of a Sprint Planning Meeting: the Scrum Team determines which product backlog items should be chosen and included in the current Sprint. It may be difficult to select the items that help to achieve the Sprint Goal. Previous performance, velocity (that we prepared in previous step), and the Definition of Done help resolve this issue and define a reasonable scope for the upcoming iteration. The Product Owner should be available to help Developers clarify, explain, or simplify Product Backlog items if needed.

Step 3: Planning HOW

Third step of Sprint Planning: Developers decompose selected Product Backlog Items into smaller chunks or subtasks that can be completed in one day or less. This is the responsibility of the Developers, since they’re the only ones who can decide how to turn Product Backlog items into value.

Developers typically use capacity (measured at the previous step) to verify that the amount of work is doable within the allocated time and the Sprint Goal is achievable. If they notice that there’s insufficient time to complete all of their tasks, they can renegotiate the scope with the Product Owner.

Special attention should be paid to identifying dependencies between the tasks, especially those on other teams and 3rd party components, which are out of the direct control of the team. It is also helpful to visualize these dependencies so that creating a game plan for how to handle them is easier. If your task tracking system does not provide this level of visualization, you may use the online collaboration tools/whiteboards in addition to your main tracking tool.

Step 4: Wrapping up Sprint Planning Meeting

The Sprint Planning Meeting can finish with a vote of confidence and a Q&A session to make sure that all the team members are on the same page.

How to Measure the Level of Confidence at a Sprint Planning Meeting

To run an effective Sprint Planning Meeting, we recommend the Fist to Five method, which allows you to get quick feedback on issues. After the Product Owner asks whether the Sprint Goal is achievable , every participant of the Sprint Planning Meeting raises their hand showing 0-5 fingers.

It is good practice to repeat the same exercise in Daily Scrums. First to Five

How To Run a Sprint Planning Event: Checklist

It may seem like there’s a think about and do to run a successful Sprint Planning Meeting. But if you keep the following guidelines in mind, you’ll be able to set out a value-adding Sprint and ensure that everyone on your Scrum Team is on the same page:

  • Make sure the Product Backlog is refined
  • Make sure the Product Backlog items are sized
  • Review the Team velocity
  • Review the Team’s availability and calculate capacity
  • Refresh Definition of Done with the Team
  • Prepare online tools as needed
  • Set a Sprint Goal
  • Decide what items should be included in the Sprint Backlog
  • Create sub-tasks
  • Ensure subtasks last no longer than a day
  • Identify dependencies and plan ways to handle them
  • Verify duration of all subtasks against capacity of the Team
  • Make sure that all team members are synchronized by measuring their level of confidence using the Fist To Five method