When to use
Hold sprint planning on the morning of day 1 of every sprint, once the top of the backlog has been refined.
Roles
- Product Owner: brings the ordered backlog and proposes the sprint goal.
- Scrum Master: facilitates and keeps the session to its timebox.
- Developers: decide how much work fits, plan how to do it and commit to the sprint backlog.
- Project Manager (on strategic projects): joins the first half hour to confirm how the sprint goal moves the next milestone, and to flag dependency dates.
Before you start
- Make sure about two sprints of ready items sit at the top of the backlog.
- Work out the team's capacity for this sprint. Account for leave, holidays and on-call duty. Take the team's average velocity over the last three sprints as a guide.
- Check the milestone plan, so you know what this sprint must contribute.
Steps
- Set the context. In 5 minutes, the Product Owner restates the next milestone and says what was learned at the last sprint review.
- Propose a sprint goal. The Product Owner proposes one goal for the sprint, in a single sentence that states an outcome, such as "Agents can see a quote's status without calling us".
- Choose the items. Take ready items from the top of the backlog that serve the goal, until the team's capacity is reached. Leave about 10% free for refinement and surprises.
- Plan the work. Developers break each item into tasks of a day or less. If an item turns out larger than it looked, say so now and drop or split it.
- Check dependencies. Confirm that every dependency this sprint relies on is agreed. The Project Manager follows up on any that aren't.
- Agree the goal. Re-read the sprint goal against the chosen items. Adjust the wording until the whole team agrees it is achievable.
- Commit and publish. Publish the sprint goal and the sprint backlog where stakeholders can see them, such as the team board or channel.
Outputs
- A sprint goal everyone can say in one sentence.
- A sprint backlog sized to the team's real capacity, with tasks for the first few days.
Pitfalls
- Planning to 100% capacity. That leaves no room for Run work, incidents or anything learned during the sprint.
- A goal that is just a list of items. "Finish items 101 to 108" isn't a goal. Say what will be different for a user or the business.
- Pulling in unready items. If an item doesn't meet the Definition of Ready, it goes back to refinement, not into the sprint.