by The Scrum framework consists of Scrum Teams and their associated accountabilities, artifacts, events and rules as defined in the Scrum Guide.
Scrum events
Sprint Planning definition
Sprint Planning purpose
- Sprint Planning is a mandatory Event of Scrum and is a feedback loop that members can inspect the Product Backlog and select enough work to develop during the Sprint.
Sprint Planning inputs
- The three Sprint Planning meeting inputs are :
- Product Backlog
- Projected Development Capacity
- Past Development Performance
Sprint Planning outputs
- Outputs of Sprint Planning are the Sprint Backlog and its commitment the Sprint Goal.
- The Sprint Backlog itself contains selected Product Backlog Items and their related tasks, the plan to do the work.
- This resulting plan is created by the collaborative work of the entire Scrum Team.
- The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
Sprint Backlog and Sprint Goal
- The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
- Sprint goal is the commitment for the Sprint.
Sprint Goal
- A good sprint goal provides the same guiding effect that we observe from a good product vision.
- It provides context for the Developers, allowing them to make good decisions when executing on their commitment.
- It also helps the Product Owner focus by providing a need for the Product Owner to have a strong theme or goal.
- Merely re-stating the stories committed to in Sprint Planning will not be sufficient to provide this focus.
- It requires a grasp of the business value and the ability to communicate this as a coherent goal on the tactical level of the Sprint.
- An inability to articulate a sprint goal is usually symptomatic of poor product vision.
- This is “feature soup” and at the sprint level: “story soup”.
- A good sprint goal also provides the team with some “wiggle room” in terms of meeting their commitment.
- If the team runs into trouble during the sprint, examine their ability to deliver in light of the sprint goal to see if there is room to de-scope items without affecting the goal.
- Finally, the sprint goal is also used as an acid-test of whether a sprint should be terminated.
- Termination is a drastic and hopefully infrequent event in most Scrum Team’s lives.
- If however the environment or assumptions for choosing the sprint goal no longer match the reality, this could be cause for the Product Owner to choose to terminate.
Sprint Planning time-box
- Sprint Planning is a time-boxed event of 8 hours or less to start a Sprint.
Sprint Planning participants
- The Scrum Team.
- The Sprint Goal is created through all Scrum Team members’ collaboration.
- The Scrum Team may also invite other people to attend Sprint Planning to provide advice.
- The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.
Sprint Planning rule
- It should be conducted at the beginning of each Sprint.
Sprint Planning practice
- Sprint Planning serves to inspect the work from the Product Backlog that is most valuable to be done next, and to design this work into the Sprint Backlog.
- In the Sprint Planning, usually, enough tasks are defined for the early days of the Sprint, and other tasks emerge during the Sprint when the Developers learn more about the work, new tasks are added during the Daily Scrum.
- Creating the Sprint Backlog is a collaborative work that is done by the Developers during the Sprint Planning not before or after it.
- During Sprint Planning, the Sprint Backlog should be groomed / defined enough so the Developers can create its best forecast of what it can do and start the first several days of the Sprint.
- Sprint Planning answers what three questions?
- Sprint Planning addresses the following topics:
- Topic One: Why is this Sprint valuable?
- The Product Owner proposes how the Product could increase its value and utility in the current Sprint.
- The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to Stakeholders.
- Topic One: Why is this Sprint valuable?
- The Sprint Goal must be finalized prior to the end of Sprint Planning.
- Topic Two: What can be Done this Sprint?
- Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.
- The Scrum Team may refine these items during this process, which increases understanding and confidence.
- Selecting how much can be completed within a Sprint may be challenging.
- However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done (DoD), the more confident they will be in their Sprint forecasts.
- Topic Three: How will the chosen work get done?
- For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done (DoD).
- This is often done by decomposing Product Backlog items into smaller work items of one day or less, the tasks for the Developers.
- How this is done is at the sole discretion of the Developers.
- No one else tells them how to turn Product Backlog items into Increments of value.
- The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
- For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done (DoD).
- Topic Two: What can be Done this Sprint?
More informations for the Scrum PSD certification here.
Updated : 15/10/2021
