Breaking Down Sprint Planning

What’s the Purpose?

Sprint Planning gives the Scrum Team an opportunity to determine what working, potentially releasable increment will be developed next.   The Product Owner will have an objective in mind for an increment that needs to be delivered in order to increase the value of the product.  The Development Team will work with Product Owner in determining which Product Backlog Items (PBIs) achieve that objective, which creates the Sprint Goal.   The Development Team then decides how to turn those PBIs into a deliverable increment.

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 answers the following:

  • What can be delivered in the Increment resulting from the upcoming Sprint?

  • How will the work needed to deliver the Increment be achieved?

 

Who can Attend and Participate in the Sprint Planning?

The Scrum Guide does not limit who may attend the Sprint Planning.  Because the plan is a collaborative effort of the entire Scrum Team, at least the Product Owner, Development Team and Scrum Master must attend.  The Scrum Team may determine that other attendees would be beneficial, such as key stakeholders, other delivery team’s members, architectural, design, or business experts, etc., however, the efficiency of the meeting, Scrum roles and purposes, and Agile principles should not be compromised by the addition of attendees outside the Scrum Team.

 

How Long is the Sprint Planning?

The Sprint Planning session is a time-boxed event.  For a one-month Sprint, it may not exceed eight hours.  While it is normal to have a shorter Sprint Planning session for a shorter Sprint, the maximum time-box is still up to eight hours.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

How long are your Sprint Planning sessions?

 

How does the Sprint Planning Happen?

The Sprint Planning is broken down into two topics.  What and how?  These two topics may be explicitly separated, making a clear distinction between each, or they may be combined.  This should be experimented with by the Scrum Team.

 

The What

The Product Owner should enter the Sprint Planning with an objective of what will be accomplished over the next Sprint.   The Product Backlog should reflect this, with the PBIs that achieve this objective at the top of the Backlog.  Preferably, the PBIs have been groomed to some extent, so that the Development Team already understands at least the basics of each item and the relative size of each item.   The Product Owner should discuss this objective with the rest of the Scrum Team.  

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 Development Team can then begin working down the Product Backlog.  Each item should be discussed (or groomed) enough that the Development Team believes it is ready to be executed in the Sprint.

Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.

The Development Team should keep in mind its velocity and its capacity for the Sprint.  Are Developers going to be on leave? Are there meetings or training sessions that will consume a large amount of their time?  Is there anything else that might cause a reduction in the capacity of the Development Team for this Sprint?  

The Development Team will determine how much work it believes it can complete as Done per the Scrum Team’s Definition of Done.  It’s important to remember that the Development Team is responsible for turning PBIs into working software, therefore, only the Development Team can decide how much work is taken on in one Sprint.  The Product Owner may demonstrate demand for work and if there is doubt over the value being delivered over the course of a Sprint due to the amount of work taken on it should be discussed in the Sprint Review and Retrospective.

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.

From there, the Development Team and Product Owner negotiate the scope of the objective to create a Sprint Goal.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. 

The How

The how is probably the most overlooked topic of the Sprint Planning.  This is where the Development Team really starts to plan and solutionize the work.   Development Teams will often break down the PBIs into sub-tasks, preferably to a size no larger than one day.   

…(work) is decomposed by the end of this meeting, often to units of one day or less.

The Development Team may begin to coordinate who will take on certain work, however, cherry picking work is often seen as an anti-pattern and should be avoided as it hinders knowledge sharing and cross-functionality.  

By the end of the how topic, the Development Team should have a plan for the Sprint, which can be assessed as the Sprint progresses.  Not all work will be known and not all work will be planned in great detail.  The plan should evolve over the course of the Sprint.  This plan is called the Sprint Backlog.  

The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Sprint Backlog may consist only of PBIs and their sub-tasks, but it may also consist of a schedule or timeline, technical notes, lists of risks, resources, etc. that help the Development Team self-organise and manage the progression towards achieving the Sprint Goal.   Only the Development Team will decide how it intends to achieve the Sprint Goal.

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.

Each day, in the Daily Scrum, the Development Team will inspect its progress towards the Sprint Goal using the Sprint Backlog and metrics such as a Burndown Chart as a guide.

How much time do you spend on creating a sufficient Sprint Backlog?

 

What does the Scrum Master do During the Sprint Planning?

The Scrum Master will likely facilitate Sprint Planning; however, this is not always necessary.

(The Scrum Master helps by) Facilitating Scrum events as requested or needed.

The Scrum Master must ensure that the Sprint Planning occurs but does not exceed the pre-determined time-box.  The Scrum Master must also work with the Product Owner and Developer to understand the goal of Sprint Planning and that the Scrum rules and Agile principles are maintained.

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.

 

The Sprint Planning Event per the Scrum Guide

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.

Sprint Planning answers the following:

  • What can be delivered in the Increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?

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.

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, and it provides guidance to the Development Team on why it is building the Increment.

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 in order 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.

If you have any suggestions (grammar, punctuation, spelling, content, etc.) please post a comment below! This article is a living document!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s