Sprint Planning opens each sprint. The Product Owner discusses the sprint goal with the team and the Scrum Master. They then collaborate to reach a mutual understanding of the sprint goal and the work needed to achieve it.
The Team then estimates any Product Backlog Items that haven’t been already, or that emerged during the discussion of the Sprint Goal. (The Team may need to break large PBIs down into smaller, more manageable, pieces of work.) The Team then pulls from the top of the now ready Product Backlog the amount of work they forecast can be completed in the Sprint. The best practice here is to use the Yesterday’s Weather pattern. Simply put, only pull the amount of work the Team completed in the previous Sprint. Team capacity, which almost always varies week-to-week, also needs to be taken into account. The Team’s forecast now becomes the Sprint Backlog. (Jeff explains this process in the video below.)
It is important for the Team decide how much work can be done in the next Sprint and not be pressured by anyone outside the Team to do more. One of the core ideas in Scrum is only the people who actually do the work know how much effort it will take.
Like all Scrum ceremonies, the Sprint Planning meeting is time-boxed. It should take no longer than two hours per week of Sprint length. Regular and effective Backlog Refinement will dramatically reduce the time spent in Sprint Planning.
Next Suggested Topic: Sprint Backlog
Back to the Framework