Sprint Planning is an event in which the entire Scrum Team collectively determines what work can be delivered in the next sprint, and how that work will be completed. There are several steps in Sprint Planning:

First, close up the last sprint. If the team hasn’t done so already, update and close last sprint’s board. Any remaining work should be carried over to the next sprint unless the product owner feels that it is no longer valuable, otherwise the team should assume that some work in process on these tasks will have been wasted. This is because it takes more effort to regroup and pick up where the team left off when they stop working on a task for a sprint or more.

Second, determine your story point budget for the next sprint based on your historical performance and capacity and next sprints capacity. There are few of techniques for calculating your budget—the most common are a rolling historical average and “yesterday’s weather”—but describing them here would take too long. What really matters is to stress how important it is that the team treat this empirically: if the data tells a team that they consistently complete about 20 points a sprint, they should not attempt to complete 25 points the following sprint out of wishful thinking. Better to sign up for 20 and pick up the 5-points mid-sprint when all other work has been accepted. I find adherence to this evidence-based limit to be a powerful predictor of the team’s overall capacity for empirical process control, and thus their overall success with Agile.

Third, although it’s good practice to start Sprint Planning with 1-½ to 2 sprints of stories that meet the Definition of Ready, product owners and teams often find that they will want to introduce a new, unrefined story for consideration in the next sprint. For instance, many teams find that they almost always have an improvement item from their Retrospective, or a customer may have requested a small but important change at the Sprint Review. This step looks just like Backlog Refinement: discuss, refine, split, and estimate backlog items.

Fourth, load stories into the sprint backlog, respecting the sprint’s story point budget. Based on a good-faith estimate of the complexity, uncertainty, and effort required for new and old backlog items, their historical performance, and the calculated budget for next sprint, the team publicly forecasts that they will complete these backlog items by the end of the next iteration. Especially for new teams, it can be useful to use the “fist of five” voting technique to gauge the team’s confidence in their forecast.

Fifth, the team should discuss and commit to a Sprint Goal. The sprint goal guides the team as to the purpose of the work they will be doing over the next iteration. For instance, a sprint goal might be “Launch the new analytics beta to 10% of our customers.” It should be possible to meet the sprint goal without completing the entire sprint backlog. For instance, most of the sprint backlog might be a “must have” for launching the beta, while a couple of the backlog items might be “should haves.” The beta can be launched—and thus the sprint goal can be met—without these items being completed.

Sixth, the team should discuss how it will complete the items in the backlog. This typically take about half of the time allotted for Sprint Planning, so be sure to allow enough time for it. Starting at the top of your sprint backlog, the Development Team will discuss each item and decide how it will deliver this functionality in the sprint. As you do so, create a sub-task on your board. For instance, suppose the team wants to add a new validation error to the page. There may be a task to write the tests, another to change the logic, another to update the CSS, and another to kick off automated testing and deployment. Some teams, especially newer ones, will also estimate the number of hours each task will take to complete so they can watch these burning down along with story points over the course of the sprint.

Following Sprint Planning, any member of the Development Team should be able to articulate what the sprint goal is, what the team expects to complete, and—at least at a high level—how the team will complete that work.

One of my favorite tricks as a product owner was to ask the team to spend the 24 hours following Sprint Planning validating their plan for the iteration, especially if the last step of planning how the work will be completed is cut short due to the time-box. When that grace period ends, I would send an email to all of my stakeholders reporting on what we completed last sprint, what we forecast we will complete this sprint, and the sprint goal that we’ve committed to. This is a nice follow-up from the Sprint Review because it gives stakeholders a preview of our next iteration.

One of the biggest mistakes I’ve seen teams make is not allowing enough time for sprint planning or doing enough backlog refinement in advance. Sprint Planning should take 1-2 hours per week planned, so a 2-week sprint should take 2-4 hours to plan. If you are finding that it is difficult to complete sprint planning in this time-box—including determining how the team will do the work—you may need to do more backlog refinement or evaluate how this event is facilitated.