- Confirm what can be delivered in the upcoming sprint
- Identify the work needed to deliver the increment
Who: Entire Scrum Team: Dev-Team, Product Owner, Scrum Master
When: Immediately prior to start of next sprint. Requires approx. 2 hours for a 2-week sprint.
A Ceremony In Two Parts
Sprint Planning Part One: What Can Be Delivered?
- Product Owner discusses the goal for the sprint, and the Product Backlog items needed to achieve it
- Team assesses their projected capacity for the upcoming sprint, selects a number of backlog items consistent with their historic velocity and projected capacity
Sprint Planning Part Two: How will the chosen work get done?
- Each Product Backlog item targeted for the sprint is broken into required development tasks and estimated
- Estimates for each backlog item may be based on either relative sizing (story points)* or task effort
- If necessary, revise the sprint backlog based on the task estimates and available capacity
- Close out prior sprint
- Product Owner decides sprint goal, and reviews with team.
- PO selects stories required to meet sprint goal.
- Confirm candidate stories meet definition of ready.
- Determine team capacity available for upcoming sprint (factor in holidays and PTO).
- Decompose each story into implementation tasks
- Estimate tasks to nearest half day
- Keep running estimate of total required effort vs. available capacity. Adjust sprint backlog if necessary to ensure team not overloaded.
- Both prior 2 steps can be omitted when team achieves a stable velocity.
- Team commits to sprint
- Update team scrum board.
- Objectives and scope of the next sprint determined by PO and team
- Work needed to accomplish the sprint objectives and scope identified.
- Team ready to begin executing
The ‘what’ of Sprint Planning is not answered in a vacuum, but rather in the context of the overall objectives of the Program Increment (PI). Each team on an Agile Release Train (ART) will leave a PI Planning event with a set of PI Objectives and feature deliverables for the upcoming PI, and these should act as overarching guidance for teams when setting sprint goals throughout the PI. I always strongly encourage teams to maintain physical scrum boards and burn-down charts in their spaces used for stand-ups. For teams that are part of SAFe Release Trains, having physical copies of the program wall-boards (feature delivery time-lines) and PI Objectives on display in the same space as their scrum artifacts is invaluable for guidance with planning at all levels, and for keeping teams synchronized on goals and progress.