Sprint planning is a Scrum event where the team prepares the product backlog items they will work on during that sprint and explains their initial plan for performing those product backlog items.
What is Sprint Planning?
The event that marks the start of each sprint is called Sprint Planning. This is a meeting during which the Development Team and the Product Owner role agree on what work will be done during the sprint.
Participants in this meeting are the entire Scrum team (Development Team, Scrum Master, and Product Owner role). Stakeholders may be invited to provide additional information, although this is rare, and it is the responsibility of the Product Owner role to provide all available information.
Duration of the Sprint Planning event
For a one-month sprint, the maximum time for this event is 8 hours.
For a two-week sprint, it will be 4 hours, respectively. And so on.
The Scrum Master role ensures that the Scrum team adheres to the meeting time limit, as well as keeping all participants focused and monitoring violations of Scrum principles and rules.
The purpose of the Sprint Planning event
The purpose of the Sprint Planning event is to plan and prepare the work for the upcoming sprint. The planning is on a group basis, and the whole Scrum Team is involved. This meeting is one of the foundations of the idea of self-organization.
The Scrum Master role ensures that everyone is aware of the purpose of the meeting and the benefits of the event.
The Sprint Planning major questions
The Sprint Planning event should answer the following main topics:
What can be delivered at the end of the sprint?
How will the increment work be done?
Resources for productive Sprint Planning
The primary resources needed for this event are the following:
Latest increment (the latest product version from the last sprint)
Team capacity and velocity
The Product Owner prioritizes items for Sprint Planning
The Product Owner role has previously prioritized Product Backlog Items and may make additional adjustments during the meeting.
Sprint Planning and estimations
The Development team estimates how much Product Backlog Items will choose for the sprint.
Only the Development Team can judge what it can accomplish during a sprint without the other roles putting pressure or influence on it.
After the Development team predicts which Product Backlog Items it can perform during the sprint, the entire Scrum team together defines and formulates a Sprint Goal.
How will the increment work be done?
As there are no formal meetings scheduled in the Scrum Process for discussions and details, now is a moment when the Development team will discuss how exactly it will develop its tasks. Once the members of the Development Team know what they will be working on, they may need a discussion to discuss details, implementation methods, and more. They can approach the Product Owner role and ask questions that will help in judging the workflow.
The specific Product Backlog Items that the team has chosen to fulfill in the upcoming sprint are called Sprint Backlog.
For example, if we have 200 Collected Items in the Product Backlog, in the Sprint Backlog for this sprint, the team may have selected 10, for example.
The development team looks at the selected Product Backlog Items together for the sprint and starts breaking them down into small tasks. The word task here is correct.
A User Story can be broken down into multiple tasks.
For example, if a Use Story describes:
"As a User, I need to create an account."
The team can create many tasks related to this User Story.
One task might be, for example, creating web form fields. Another task might be programming the account creation logic. A third task may be to test the newly created user registration, etc.
The development team can create an unlimited number of tasks that are actually related to a single User Story.
Tasks that are created during planning can also receive a relative estimate of the development time, similar to User Stories. However, many teams, instead of relative values, forecast a specific fixed time for their tasks. User Story tasks may no longer have a relativity time, but specifically minutes, hours, or days. The development time approach remains the choice of the Development Team.
Freezing the Sprint Backlog at the end of the Sprint Planning event
After arranging the Sprint Backlog list and creating separate tasks for each item, it is strongly recommended that no one else add or remove Product Backlog Items in that list. Only the Development Team is allowed to manage their Sprint Backlog.
The Product Owner role is not allowed to make any changes or modifications to the Sprint Backlog. If the Product Owner role has a strong need to add or remove an item for some reason, it should approach the Scrum Master role and explain its concerns and needs. The Scrum Master role will convey the desire of the Product Owner role to the Development team. If the Development Team agrees, the needs of the Product Owner role can be met.
Product Owner Role and Sprint Planning Event
Before planning the sprint, the Product Owner role was supposed to have prioritized items. The most prominent top positions in the Product Backlog are the most important User Stories.
Another important responsibility of the Product Owner role is to ensure that the items are ready for review by the team and suitable for discussion. Everything in the Product Backlog Items should be well described and not have any crucial missing information.
The items should include Definitions of Done and possibly Acceptance Criteria. If something remains unclear to the Development Team, the Product Owner role answers their questions.
Development Team and Sprint Planning Meeting
The Development Team determines how it works and how much work it can approximately perform during a sprint. Only the Development Team can determine these topics.
Although the Product Owner role has prioritized Product Backlog Items and it is assumed that the Development Team will make its choice by selecting items for its Sprint Backlog, the Development Team has the right to refuse to work on an item that the team considered impossible to develop.
The reason for rejecting an item may also be that the item, for some reason, is not adequate or working on it will create problems for the project of technical or other nature.
If there are any questionable items in Product Backlog, it is logical for the development team to select for their Sprint Backlog different items ordered just below the problematic ones, since it is assumed that the ordering of the items in the Product Backlog follows some order.
The collection of the items in the Sprint Backlog is decided according to the Velocity of the Development Team. If the Velocity of the Development Team in the previous sprint was, for example, 130 points, during the Sprint Planning event, the Development Team would select for its Sprint Backlog a total of approximately 130 points.
It is assumed that inexperienced teams or experienced teams, but at the very beginning of the project, make inaccurate estimates or often make mistakes in their analysis and planning. These inaccuracies are natural, and Scrum oriented organizations need to understand this.
As work progresses and passes through the Sprints, it is suggested that the Development Team should make more accurate assessments and have a thorough knowledge of the product, planning, and discussions.
Evaluating the relative time to a Product Backlog Items is also a team effort, and it is advisable to avoid one participant making an assessment, regardless of his or her role in the team.
Planning Poker is a popular term in the Scrum teams. This is a gaming technique through which the Development team puts time estimates of items planned for an upcoming sprint by "playing them at poker".
Each member of the Development Team holds a deck of cards numbered 1 to 21 (or starting at 0)
One person on the team presents the User Story publicly and aloud to everyone. All descriptions in the User Story are read.
Then each participant in this "poker planning game" chooses a card with the number that is supposed to be set as Story Points for the specific User Story.
Each Development Team member places their card on the table without showing the card number.
After each team member places their cards on the table, it's time to turn all the cards and see the numbers.
Unless there is a significant difference between the number of cards thrown (participant assumptions) for Story Points of a particular User Story, the average value of all cards (the average guess of the team) is assumed, and play continues for subsequent Product Backlog Items.
Discussing the estimates
In case the participants' cards show very different values, for example, there is a card with the number 3 and a card with the number 13, the team members who have made these contrasting assumptions start a discussion. The reason why everyone has made their assumption is asked, and each party shares its opinion on its estimate (card selection).
This discussion seeks to identify the problem of differences between the cards thrown.
Sometimes the difference may be due to misunderstanding of User Story. This misunderstanding may mean that either the Product Owner role has not tried well enough to explain the User Story or the member of the team has not carefully considered the content of the User Story. Another common reason for throwing different cards is the possibility that a member of the Development Team may have information that the other participant in the game (the one with the opposite card) does not know.
Let's give an example.
A “low card” participant may know a very easy method to implement a functionality or embed a component, and the other members may not be aware of that easy method. That was the reason this team member tossed a small number card.
On the other hand, we may have the following case. The player (participant) with the highest card, who should typically open a discussion with the participant with the smallest card, may already have tried this "easy and fast" way of getting the job done. There were problems. It has been found that the easy way may only create additional problems. The opponent with the weak card is not yet aware of this fact.
The discussion serves to identify problems, opportunities, and solutions. The debate is public to the rest of the team. Anyone can take part in the topic if there is something to add and help find the right solution. Otherwise, the discussion may go beyond a productive norm.
After the discussion, a re-play is performed, and each participant of the Development Team again throws a card. Other participants' opinions may already have been influenced.
Raffles and discussions are made until consensus is reached.
Independence among members of the Scrum Development Team
The Planning Poker meeting aims to achieve independence among members of the Development Team and provokes the idea that anyone can throw their card without worrying about the rest. No one should throw their card after the Development team has already revealed the card numbers.
Often, new members of the Development Team are very distracted by this "game" and are afraid to throw their cards until they somehow understand what cards were thrown by senior team members.
This practice also aims at transparency, individualism, and openness. The aim is also to develop time-assessment skills among newcomers.
Keep in mind that this approach is just a popular technique for estimating development time. Each team can choose its own transparent and effective ways.
Scrum Master and Product Owner may not participate
Scrum Master and Product Owner roles do not have regulated official participation in this technique. The Scrum Master role participates in its discretion without interfering with the team and can monitor transparency, respect for team members, and honesty.
The Scrum Master role encourages beginner involvement and teamwork and condemns behavior that would violate fair play principles. Keep an eye out for a reasonable time throughout Planning Poker, which is only part of the entire Sprint Planning event. Some teams distinguish between planning meetings and separate them from their official Sprint Planning, during which they discuss with their Product Owner and select the specific work for the current Sprint Backlog, split their tasks, and create a Sprint Goal (if they do).
How much Product Backlog Items should be estimated?
There are no official rules for how much Product Backlog Items should be estimated during this "game".
If the team is in their first sprint for the project, it is advisable to play as many items as possible in a reasonable amount of time.
If the team is in another sprint, they can play an approximate number of User Stories that the Development team can absorb during the sprint.
We recommend that you estimate a few more additional items because if the Development team accidentally finishes their work earlier, they can "insert" a few additional Product Backlog items into their Sprint Backlog that have already been evaluated. It will be very easy to gauge exactly how many items to add in the remaining days of the sprint.
Planning Poker is not practiced by all Scrum teams, as this "game" can take a long time, and the team may experience inconvenience and distress over time. Time estimation can also be accomplished through faster group discussions by the Development team.
When there are ambiguities or missing information on some items, and it is not possible to retrieve additional information, the Development team, in theory, should still be able to evaluate them by assuming the most accurate estimate possible.
After the end of the long "game" with the evaluation of development time, after selecting the work for the current Sprint, all discussions and defining the purpose of the sprint, the participants can do another interesting practice, at the initiative of the Scrum Master role.
The Sprint Success prognosis
Each member of the Scrum team indicates a number from 0 to 3, thus personally and individually proposing their success to the sprint. 0 means failure (Unfulfilled sprint goal, work in progress, or problems). 3 means success and achievement in all initiatives. Collect the sum of points. Considering the total number of participants and the total points for the success of a sprint, consider whether you have a high or low overall value.
If the result of the averaged points is not satisfying, have a discussion, and discuss possible problems.
If the scores for success are high, the Scrum Master role thanks everyone for the grueling participation of everyone and closes the Sprint Planning meeting.
Sprint Planning and Time Consumption
If your Sprint is from 1 month, your Sprint Planning will be one full day. You will have late colleagues, lunch breaks, a coffee break. Observe reasonable limits and seek optimized discussions, processes, and results.
The Scrum Master role interrupts all Scrum events, ceremonies, and meetings on time so that valuable time is not wasted.
Variations of the Sprint Planning details
There are many variations of the different teams in estimating the time it takes to develop the Product Backlog Items. However, the valuation of Story Points values is often not performed in multiple teams during sprint planning.
Sometimes you may meet additional informal meetings and events such as Product Backlog Items Grooming Meeting and various others. These are special meetings that bring the whole team together again and only evaluate time and discussions about Product Backlog items. Some teams also have separate time assessment meetings and separate Product Backlog Items discussion meetings.
At the end of the Sprint Planning event, the Development Team must be able to present to the Product Owner and Scrum Master the roles of how it intends to work as a self-organizing team to achieve the purpose of the sprint and to develop the expected work.
The original text in the Scrum Guide:
"By the end of Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment."
We prefer not to interpret this abstract paragraph from the official Scrum Guide and leave the interpretation to you.
However, BVOP recommends that you do not engage in "torture" or "behavioral interview" dialogues and do not provoke unnecessary problems. Scrum Master and Product Owner roles should be reasonable and expect the same from the Development Team.
Let the whole Scrum team know very well precisely what it will work and how it will work. Keep the technical approaches discussed and clear. Other topics stemming from the original Scrum statement can be cited as familiarizing the entire Scrum team with the theory of self-organization.