Sprint Planning

Sprint planning is a Scrum event (ceremony) during which the entire Scrum team prepares the product backlog items they will work on the sprint. The team explains their initial plan for performing the intended for development product backlog items. 

1. What is Sprint Planning?
2. Duration of the Sprint Planning event
3. The purpose of the Sprint Planning event
   1. The Sprint Planning major questions
4. Resources for productive Sprint Planning
   1. The Product Owner prioritizes items for Sprint Planning
   2. Sprint Planning and estimations
   3. How will the increment work be done?
5. Sprint Backlog
6. Freezing the Sprint Backlog at the end of the Sprint Planning event
7. Product Owner Role and Sprint Planning Event
8. Development Team and Sprint Planning Meeting
9. Planning Poker
10. Discussing the estimates
11. Independence among members of the Scrum Development Team
12. Scrum Master and Product Owner may not participate
13. How many Product Backlog Items should be estimated?
14. The Sprint Success prognosis 
15. Sprint Planning and Time Consumption
16. Variations of the Sprint Planning details
17. The explanation

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 the type of upcoming work.

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 the 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 done on a group basis, and the whole Scrum Team is involved. This meeting is one of the foundations of the self-organization idea.

The Scrum Master role ensures that everyone is aware of the meeting’s purpose 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:

Product Backlog

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 many Product Backlog Items to choose for the sprint.

Only the Development Team can decide 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 a Sprint Goal.

How will the increment work be done?

As there are no formal meetings scheduled in the Scrum Process, at a certain point the Development team discusses how exactly it will develop its tasks. Once the members of the Development Team know what they will be working on, they may need to discuss details, implementation methods, and more. They can approach the Product Owner role and ask questions that will help evaluate the workflow. 

Sprint Backlog

The specific Product Backlog Items that the team has chosen to fulfill in the upcoming Sprint are called the Sprint Backlog.

For example, if the total number of items in the Product Backlog is 200, the teams may include only 10 in their Sprint Backlog.

The Development Team looks at the selected Product Backlog Items for the Sprint together 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 relative time, but exact minutes, hours, or days. The development time approach remains the Development Team’s choice.

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 adds or removes 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, he or she 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 should have already prioritized the items. The User Stories at the top of the list are the most important.

Another important responsibility of the Product Owner role is to ensure that the items are prepared for the team and suitable for discussion. Everything in the Product Backlog Items should be well described and not have any crucial information missing.

The items should include Definition of Done and possibly Acceptance Criteria. If something remains unclear for the Development Team, the Product Owner role answers their questions.

Development Team and Sprint Planning Meeting

Only the Development Team determines how it works and how much work it can approximately perform during a Sprint.

Even though the Product Owner has prepared the prioritized Product Backlog Items, from which the team forms its Sprint Backlog, the Development Team has the right to decline to work on particular items if they consider them impossible to develop.

The reason for rejecting an item may also be that, for some reason, it is not adequate or working on it will create technical or other problems for the project.

If there are any questionable items on the Product Backlog, it isn’t logical for the development team to select them for their Sprint Backlog. Instead, they can choose from the following items, as it is assumed that the higher an item on the list is, the more significance it has.

The Velocity of the Development teams determines the Sprint Backlog items collection. If in the previous Sprint it 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 both inexperienced and experienced teams might make inaccurate estimates at the very beginning of the project or often make mistakes in their analysis and planning. These inaccuracies are natural, and Scrum oriented organizations need to understand this.

As work during the Sprint progresses, it is suggested that the Development Team makes more accurate assessments and has a thorough knowledge of the product, planning, and discussions.

Planning Poker

Evaluating the relative time to complete the Product Backlog Items is also a team effort. It is advisable for a single participant to avoid 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 planning technique through which the Development team puts time estimates to the items planned for an upcoming Sprint by "playing with them like in poker".

Each member of the Development Team holds a deck of cards numbered 1 to 21 or starting at 0 (these numbers represent the Story Points). 

One person on the team presents the User Story aloud and publicly to everyone with all of its details.

Then each participant in this "poker planning game" chooses a card with the number of Story Points, which they think would match the User Story best.

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 each card's Story Points (the participants’ assumptions) for a particular User Story, the average value of all cards is used. The 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 reasons for both assumptions are clearly stated and each party shares its opinion on the estimates.

The discussion seeks to identify the reasons for the contrasting assumptions.

Sometimes the difference may be due to a misunderstanding of a User Story. This misunderstanding may mean that either the Product Owner didn’t explain the User Story well enough or a member of the team didn’t carefully consider the content of the User Story. Another common reason for throwing different cards is the possibility that a member of the Development Team has information that the other participant in the game (the one with the contrasting card) does not know.

Let's give an example.

On one hand, 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. This is the reason why the participant chose 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. 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 done while the rest of the team is present. Anyone can take part in the topic if there is something to add and to help find the right solution. Otherwise, the discussion may go beyond a reasonable time frame.

After the discussion, a re-play is performed, and each participant of the Development Team throws a card again. Other participants' opinions may already have been influenced.

Card throwing 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 involvement and teamwork and condemns behavior that would violate fair play principles. He or she makes sure that the duration of the Planning Poker is reasonable, as it is only part of the entire Sprint Planning event. Some teams distinguish between the different planning meetings. They separate them from their official Sprint Planning, during which they have discussions, select specific work for the Sprint Backlog, split their tasks, and create a Sprint Goal (if they need one).

How many Product Backlog Items should be estimated?

There are no official rules for how many Product Backlog Items should be estimated during this "game".

If the team is in their first project Sprint, 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, which can be completed by the Development Team during the Sprint.

We recommend that you estimate a few more additional items because if the Development team 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 determine 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 evaluation “game”, the selection of work for the current Sprint, and all discussions end, there comes another interesting practice, which can be initiated by 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 of all initiatives. Collect the sum of points. Considering the total number of participants and the total points for the success of a Sprint, a high or low overall value is predicted.

If the result of the averaged points is not satisfying, have a discussion, and indicate possible problems.

If the scores for success are high, the Scrum Master role thanks everyone for the active participation and closes the Sprint Planning meeting.

Sprint Planning and Time Consumption

If your Sprint is 1 month, your Sprint Planning will be one full working day. You will have to keep in mind the colleagues are sometimes late, there are lunch breaks, coffee breaks. Observe reasonable limits for such events 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

The different teams have many variations of estimating the time it takes to develop the Product Backlog Items. The Story Points estimates that the teams make, however, are not always carried out during the Sprint Planning event.

Sometimes you may conduct 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 to evaluate time and hold discussions about Product Backlog items. Some teams also have separate time assessment meetings and separate Product Backlog Items discussion meetings.

The explanation

At the end of the Sprint Planning event, the Development Team must be able to present to the Product Owner and Scrum Master the way it intends to work as a self-organizing entity 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.

BVOP suggests the Scrum Master or Product Owner do not “cross-question” or conduct "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 precisely what it will work on and for how long. Keep the technical approaches clear. Other topics stemming from the original Scrum statement can be cited as familiarizing the entire Scrum team with the theory of self-organization.

The following issues related to chapter "Sprint Planning" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of September 7, 2024, 5:52 pm