The Scrum Training Series is provided free of charge and used by thousands of Agile practitioners, coaches, and trainers around the world.
Contact Michael James via Twitter.
Script without illustrations.
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to negotiate which Product Backlog Items they will attempt to convert to working product during the Sprint. The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement without accruing technical debt [high cost of future change --mj]. The team “pulls” work from the Product Backlog to the Sprint Backlog.
When teams are given complex work that has inherent uncertainty, they must work together to intuitively gauge their capacity to commit to items, while learning from previous Sprints. Planning their hourly capacity and comparing their estimates to actuals makes the team pretend to be precise and reduces ownership of their commitments. Unless the work is truly predictable, they should discard such practices within the first few Sprints or avoid them altogether.
Until a team has learned how to complete a potentially-shippable product increment each Sprint, it should reduce the amount of functionality it commits to. Failure to change old habits leads to technical debt and eventual design death, as shown in Figure 15.
If the top of the Product Backlog has not been refined, a major portion of the planning meeting should be spent doing this, as described in the Backlog Refinement Meeting section.
Toward the end of the Sprint Planning Meeting, the team breaks the selected items into an initial list of Sprint Tasks, and makes a final commitment to attempt the work.
The maximum allotted time (a.k.a. timebox) for planning a 30-day Sprint is eight hours, reduced proportionally for a shorter Sprint. [Note that shorter Sprints, e.g. 2-weeks, are generally recommended nowadays. --mj]
Meetings can initially be facilitated by the Scrum Master, who has no decision-making authority at these meetings.
If you are taking the Professional Scrum Master (PSM) exam, be advised "commit" has been replaced with "forecast" regarding PBIs, though there's still a sense of committing to the Sprint Goal. In that world the Product Backlog is "ordered" rather than "prioritized."
If you are taking the Certified Scrum Master (CSM) or PSM exams, you should be aware that some new descriptions of Scrum no longer require the use of Sprint Tasks, accepting that teams should have freedom to execute Sprints their own way. For example, a team following eXtreme Programming (XP) practices may break their PBIs into such small User Stories that Sprint Tasks (and PBI estimation) would be redundant. I still recommend teams start out using Sprint Tasks, then use the Sprint Retrospective Meeting to inspect and adapt whether to continue using them.
If you spot any other discrepancies, please let me know and I'll list them here.
--mj (Michael)