What is achieved in Sprint Planning?
The team selects Product Backlog Items to forecast the work for the Sprint. Sprint Planning creates a definition of what is to be built and a flexible plan. The outcome is a Sprint Backlog that contains Product Backlog Items, a plan for delivering them, and one or more team improvement items. In addition to the Sprint Backlog, the team also creates a Sprint Goal.
This plan is created by the collaborative work of the entire Scrum Team.
The set of selected Product Backlog Items that the Development Team thinks they can complete and the associated work is called a forecast of functionality. The term forecast was called a commitment in older versions of The Scrum Guide.
Who leads and controls Sprint Planning?
The entire Scrum Team gathers for the Sprint Planning. If the Development Team invited any external technical/domain experts, they participate as well. No individual leads or controls this meeting.
The Scrum Master ensures that the event takes place and that attendants understand its purpose. The planning should answer two questions:
• What can be delivered in the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?
The Scrum Master teaches the Scrum Team to keep it within the time-box. Its duration is up to eight hours for a one-month Sprint. For shorter Sprints, it is usually shorter.
What happens in Sprint Planning?
In the first phase of Sprint Planning, the team begins Topic One by selecting the Product Backlog Items and setting the Sprint Goal. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog Items that, if completed in the Sprint, would achieve the Sprint Goal. The Product Owner will introduce the Product Backlog Items that are “ready” - already refined to a state agreed upon by the Development Team and Product Owner. Just in time refinement will lead to poorly understood product needs and result in poor Sprint Planning. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. The selected items are moved to the Sprint Backlog.
After the Development Team forecasts the Product Backlog Items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog. The Sprint Goal provides guidance to the Development Team on why it is building the Increment.
The Sprint Goal is a tool for team coherence. The selected Product Backlog Items deliver one coherent function, which can be the Sprint Goal. The coherence between the Product Backlog Items is made transparent by the Sprint Goal. This is important because it provides an opportunity for team members to work together and offers some flexibility of adjusting the Product Backlog Items when required. Lack of coherence may lead the team to working on separate initiatives. So, the Sprint Goal is a tool to verify and create this coherence. As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than what the Development Team expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint.
Having selected the Product Backlog Items and the Sprint Goal, the team moves to Topic Two, the second phase of Sprint Planning. The Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint.
The Development Team usually starts by designing the system and then identifies the work needed to convert the selected Product Backlog Items into a working product Increment. Based on the estimate of the work, the Development Team plans enough work to match the available capacity. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog Items with the Product Owner.
The Product Backlog Items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
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.
-------------------Question- 28--------------------------
Which of the following does the Sprint Goal provide?
a) Guidance to the team on why it is building the Increment
b) Flexibility to the team about the functionalities implemented in this Sprint
c) Coherence so that team members can work together
d) All the above
-------Answer-------
The Sprint Goal provides guidance to the Development Team. It also provides some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog Items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together toward a common but specific goal. Correct answer is ‘d.’
-------------------Question- 28--------------------------
Should the entire Sprint work be decomposed within Sprint Planning?
Not necessarily. The Development Team decomposes the work planned for the first few days of the Sprint by the end of this meeting, often to units of one day or less. Development Team members collaboratively assign these work units among themselves.
-------------------Question- 29--------------------------
Which estimation unit must be used by the Development Team for the work needed to convert the selected Product Backlog Items into a working product Increment?
a) Function Points
b) Ideal Hours
c) Story Points
d) Any useful sizing technique
-------Answer-------
The work can be of varying size or estimated effort. Correct answer is ‘d.’
-------------------Question- 29--------------------------
Note the emphasis on the rule that only the Development Team finalizes how much they can develop within that Sprint. No one else can persuade them with different expectations.
Summary
• In Sprint Planning, the plan for the Sprint work is created by the collaborative work of the entire Scrum Team.
• Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
• In Topic One, the first phase of Sprint Planning, the Development Team works to forecast the functionality that can be done in this Sprint.
• The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.
• After the forecast, the Scrum Team crafts a Sprint Goal.
• The Sprint Goal is an objective that will be met within the Sprint through the implementation of the selected Product Backlog Items.
• In Topic Two, the second phase of Sprint Planning, the Development Team decides how it will build this functionality into a “Done” product Increment.
• The Product Backlog Items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
• Work planned for the first days of the Sprint is decomposed by the end of this meeting, often to units of one day or less.
• The Development Team self-organizes to undertake the work in the Sprint Backlog.
• If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog.