Scrum Events — Sprint Planning
Quick Reminder: What is Scrum?
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
— The Scrum Guide —
The Scrum framework consists of roles, events, artifacts and rules. Each part of the Scrum framework serves a specific purpose and is of vital importance to Scrum’s success and usage. Scrum is a lightweight framework, consisting only of 3 Roles, 3 Artifacts and 5 Events:
- Scrum Roles: Product Owner, Scrum Master and Development Team;
- Scrum Artifacts: Product Backlog, Sprint Backlog, Product Increment;
- Scrum Events: the Sprint, the Sprint Planing, the Daily Scrum, the Sprint Review and Sprint Retrospective.
Besides the official Scrum Events, there is also an activity that many Scrum Teams do, which is called Product Backlog Refinement (used to be called Grooming).
All the Scrum Events, including Product Backlog Refinment happen during the Sprint. A Sprint is the heart of Scrum, and is time-boxed period of one month or less, in which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Introduction to the Sprint Planning
The work to be performed in the Sprint is planned at the Sprint Planning. This plan 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. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
In your everyday practice, you might also know the Sprint Planning as “Scrum Sprint Kick-off” or “Scrum Planning Meeting”. Beware that these, and other similar, names are all only used in your everyday practice. Officially, the Event is called Sprint Planning.
Purpose of the Sprint Planning
The purpose of the Sprint Planning Event is to create a Sprint Goal and an actionable plan for the Sprint. The Sprint Planning Event answers two questions:
- What can be delivered as part of the Product Increment in the upcoming Sprint?
- How will the work needed to deliver the Product Increment be achieved?
The Sprint Planning Event consists of two parts, called ‘topics’. Topic one answers the question ‘What can be done this Sprint’. Topic two answers the question: ‘How will the chosen work get ‘Done’?’
Sprint Planning Topic One: What can be done this Sprint?
The Development Team works to forecast the functionality that will be developed during the Sprint. 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 entire Scrum Team collaborates on understanding the work of the Sprint.
The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
Sprint Planning Topic Two: how will the chosen work get done?
Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team 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, both during Sprint Planning and as needed throughout the Sprint.
The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. 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 Development Team may also invite other people to attend to provide technical or domain advice.
By the end of the 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.
Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team 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 rather than on separate initiatives.
As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
The time-box of the Sprint Planning
The time-box for Sprint Planning is 8 Hours, for a Sprint of 4 weeks. For shorter Sprints, the time-box is usually shorter.
Who should attend the Sprint Planning
The participants of the Sprint Planning Event are the Scrum Team members, meaning the Product Owner, Scrum Master and Development Team. The Development Team may invite people outside the Scrum Team if needed, to gain technical or domain advice.
What is Inspected during the Sprint Planning
During the Sprint Planning meeting, the following is being Inspected:
- The Product Backlog;
- The Product Increment delivered in the past Sprint;
- The Definition of Done;
- The Development Teams’ past performance (Velocity);
- The Development Teams’ projected capacity for the current Sprint;
What is Adapted during the Sprint Planning
During the Sprint Planning meeting, the following is being Adapted:
- Sprint Goal
- Sprint Backlog
- Forecast
What is the Meeting Flow for the Sprint Planning
In order to help you in getting started with the Sprint Planning Event, I’ve created a ‘Sprint Planning Flowchart’ (see image below). This flowchart offers insights into what a typical Sprint Planning Event would look like.
Learn more about the Scrum Events
Hopefully this article about the Sprint Planning was valuable to you. If you want to learn more about the other Scrum Events, check out the links below, or join us in a Professional Scrum Product Owner course!
Originally published at www.robbinschuurman.nl on May 22, 2017.
