Sprint Planning & Product Backlog Refinement
Sprint Planning
Sprint Planning is a time-boxed event at the start of the Sprint where the Scrum Team collaborates together to determine what can be done and how the work will be done in the Sprint. The Scrum Guide refers to these as “Topic One: What can be done this Sprint?” and “Topic Two: How will the chosen work get done?”[1]
Part Two: What can be done this Sprint?
In the first topic the Product Owner indicates the intention behind the Sprint, the objectives and the Scrum Team collaborates to understand the work. Only the Development Team can select how many items they will work on during the Sprint and they are the only ones who can determine how much work to bring into the Sprint. The Scrum Team works together to form a Sprint Goal that describes the intentions and positioning of the Sprint, and *why* they are doing the work for the Sprint. (The Scrum Guide also refers to this as providing “coherence” for the work.)
Practical Tips
| Sprint Position | Thinking about the objectives and strategic positioning of the Sprint by the Product Owner ahead of time can help to reduce the impact on Topic One and smooth out the high level thinking about the product. |
| Sprint Objectives | Providing context as to “why” the Sprint objective is important by the Product Owner can help the Development Team to refine their choices of what items to select for the Sprint.
This could be a lightning talk, pitch, sketch or other such information that is helpful to understand the intent and needs of the objective. |
| Capacity | Referring to the previous Sprint capacity will help the Development Team to understand how much work to select for the Sprint that is within their capabilities |
| Roadmap and Vision | A longer term high level vision or roadmap may help the Product Owner to think strategically and the Development Team to align the Sprint to the product |
| Sprint Goal | A well crafted Sprint Goal that provides a reason and context behind why the Development Team are doing this Sprint can help them to think laterally when selecting items to work on for the Sprint, and provide some real focus. |
Part Three: How will the chosen work get done?
The second topic centres on the self organising Development Team and their decisions on how the work is to be done during the Sprint. The items selected during topic one and the plan to deliver them is called the Sprint Backlog. The items selected can be renegotiated with the Product Owner and adjusted if the Development Team determines that they have too much or too little work for the Sprint. At the end of the topic and the Sprint Planning event, the Development Team should be in a position to clearly articulate how they are going to work together during the Sprint to deliver the items and create the Increment.
Practical Tips
| Visibility | Using a visual task board or similar for the Sprint Backlog works really well for teams who can then clearly see what work they have decided upon and maintain it during the Sprint to provide a visible representation of the current state of the work.
Making the work to be done highly visible enables more in depth decision making within the team. |
| Items and Tasks | Some teams like to work with a single tier system to track their items on the Sprint Backlog, however, these items should be small enough that they are at a granular level that can then be completed easily within a few days at most.
Other teams that find it difficult to split items down into small items may instead opt for a 2 tier system that uses a combination of (parent) items and (child) tasks to complete them, which provides a finer granularity for the team to work with and complete easily. |
| Testing Outcomes | Thinking about the testing objectives to be achieved, and questions to be answered when the Development Team work on items can really help to decompose them into smaller testable items, even if they belong to a larger construct or framework. |
| Self-Organizing | Allowing the Development Team to be truly self-organising when selecting what work to do and how to do it will help to use their experience and knowledge effectively to make good tactical decisions for the Sprint. |
| Product Owner Availability | Having the Product Owner around for the Development Team to bounce questions from and clarify things can be very helpful to adjust the composition of the Sprint and set the expectations appropriately. |
| New Items | During the Sprint Planning, it may be appropriate to create new items that were not on the Product Backlog, but make sense to do in the Sprint to achieve the Sprint Goal. |
| Estimation | If the Scrum Team are using sizing estimates and metrics, then it may be appropriate for the Development Team to re-estimate items and size new items to ensure that the sizes reflect the current understanding prior to the work commencing.
Common techniques for sizing include Planning Poker and Affinity Sizing. |
| Adjustment | On completion of the Sprint Planning event it can be a good idea for the whole Scrum Team to take a step back and look at the Sprint Backlog and provide an opportunity for the Development Team to finely adjust it if needed. |
| Forecast Not Commitment | At the end of the Sprint Planning event, the Development Team arrive at a Forecast for the work to be done for the Sprint.
A deeper understanding of the work begins to unfold as the work is done, and so it is possible that the composition of the work may need to be adjusted and adapted as more is known. Hence, it is more appropriate to think of the work composition of a Sprint as a “forecast” rather than a “commitment” and set in stone. |
See Also
- Scrum Framework
- Product Backlog Refinement
- Working With The Product Backlog
- Scrum Artefacts
- Product Backlog Items
- Story Mapping