Agile software development is impossible without thorough planning. 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 designing a Sprint Planning agenda that facilitates positive results.
What is Sprint Planning?
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.
A Sprint Planning meeting 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 meeting — 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 Prepare for Sprint Planning
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 Sprint Planning.
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 having historical data from previous Sprints, you can calculate the average Sprint velocity simply by adding all the story points from Sprints and dividing 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 ten days, and we are spending six 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 it will vary. This is why it’s important to measure capacity to make realistic forecasts.
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 meeting and provide advice, if needed. Discuss within the Scrum Team who should attend and when.
Fifth, think about additional tools.
COVID-19 changed our lives, since everything 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 for the 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 chosen work?
Let’s clarify what this means step by step.
Step 1: Set the Sprint Goal
First, the value of the current Sprint should be defined. The Product Owner suggests ways in which the Team can increase Product value in the current Sprint. After that, 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 achieve it. 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 be focused on business value.
Step 2: Plan How to Achieve the Sprint Goal
Secondly, 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
Thirdly, 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 renegotiate the scope with the Product Owner.
Step 4: Wrapping up Sprint Planning
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
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 meeting raises their hand showing 0-5 fingers.
Sprint Planning Meeting Rules Checklist
It may seem like there’s a lot to do and think about in order to have a successful Sprint Planning. 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 in memory Definition of Done
- 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
- 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