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 “Part Two: What can be done this Sprint?” and “Part Three: How will the chosen work get done?”[1]
Topic One: Why Is This Sprint Valuable?
The Product Owner proposes where the value is for the Sprint, and the Scrum Team works together to form a Sprint Goal that describes the intended outcomes of the Sprint, and *why* this is valuable for the stakeholders.
Practical Tips
| Sprint Goal | Providing context as to “why” the Sprint is important and valuable 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. |
| 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. |
Topic Two: What can be done this Sprint?
In the second topic the Developers select which items from the Product Backlog will help to achieve the Sprint Goal. The Developers may also refine the selected items to help with the composition of the Sprint and achieve the Sprint Goal more efficiently. The Development Team may have a good understanding of their past performance, their capacity for a Sprint, and their Definition of Done to help select the most appropriate items for the Sprint.
Practical Tips
| 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 |
Topic Three: How will the chosen work get done?
The third 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. |
Product Backlog Refinement
In the Scrum Guide, Product Backlog Refinement is mentioned but is not defined as an explicit event. However, this activity enables the Product Owner and the Development Team to refine items on the Product Backlog, which can include splitting items, decomposing them into smaller items, reordering the Product Backlog and sizing items by the Development Team. The general guidance is for the Development Team not to spend more than 10% of their capacity with Product Backlog Refinement activities, however the Product Owner can refine the Product Backlog as often as needed. When Product Backlog items are refined to sufficient detail that they can be “Done” within a Sprint, they are deemed to be “Ready”.
Practical Tips
| High Level | The Product Backlog Refinement can be used as a high level strategic activity to consider the overall objectives of the product and which items will yield the most value. |
| Value | The *true* value of the delivery of product Increments may not be immediately obvious when work starts, however, over the time the value in the work can begin to become clear, which will then act as a catalyst to reorder items, create new ones and trade-off old items to narrow down on where the value is. |
| Adaptation | It may be useful to consider Product Backlog Refinement as an adaptation of the scope with respect to the transparency and inspection from the other Scrum events. |
| Maintenance | Keep the Product Backlog fresh and constantly maintained with the current understanding of the product. Avoid leaving it to fester with initial assumptions and be prepared to make some bold adjustments as the feedback data becomes available. |
| Activities | Some Product Backlog Refinement activities may include the following:
|
| Include The Customer | For best results inviting the customer or stakeholders to Product Backlog Refinement sessions can help to provide additional context and positioning for items. |
See Also
- Scrum Framework
- Product Backlog Refinement
- Working With The Product Backlog
- Scrum Artefacts
- Product Backlog Items
- Story Mapping