The Sprint Planning Meeting addresses three questions. Why the sprint is worth doing, what will be accomplished during the Sprints, and how the work will get done. Let's look at each of these questions, starting with why. It's important that everyone on the Scrum team understand why the sprint is to be undertaken. Most organizations have plenty of competing priorities, so why do this particular work? This does not have to a grand justification of the product. It can be as simple as their product owner describing users' most pressing needs and perhaps how those were determined. Starting the planning meeting with why the work is important ensures that everyone understands the value of the works they'll perform during the sprint. Ideally, the reason why their work will be performed can be expressed in a sprint goal. The sprint goals is usually a one or two sentence summary of what the developers will try to accomplish during this sprint allow users to check out and pay for the items in their cart, improve the accuracy of the search results, improved the usability of account maintenance screen, released a first version of Data Explorer with at least 10 visualization types. A sprint goal is not necessarily a product backlog item itself. Instead, we mean goals based on completing a set of related product-backlog items. And at this early point in the sprint planning meeting, the Sprint Goal is only a draft. As the meeting progresses, that draft Sprints Goals can be refined, especially if it turns out to be too ambitious. After the product owner addresses why the work is important, the developers focus on determining what will be accomplished and how they will get it done. These topics are intertwined because it's challenging for a team to know what they're going to develop without having discussed how to do it. To determine what will be delivered in the Sprint, the developers select items from the Product Backlog that align with the Draft Sprints goal. Because the product backlog is prioritized, developers work down the project backlog, selecting as many items as they think will fit within the sprint. As they workdown the backlog developers can ask questions of the products owner to clarify their understanding of what each item means. Most high-priority product backlog items should be aligned with achieving the spring goal. But it's quite often the case that some high priority items are unrelated to the goal, and that's OK. At some point, developers discuss how the items they've selected will be developed. Basically, they discuss the steps or tasks necessary to deliver each item. Some teams determine who will perform each task during sprint planning. Other teams let those decisions be made as the sprint progresses. Similarly, some teams roughly estimate the effort to complete each tasks because this helps them select the right amount of work for the Sprint. Some teams have these discussions as each new item is selected for inclusion in the sprint. Other teams wait until they have a hunch the Sprint is close to full and then discuss all items. Either approach works. The key is to remember that things can and will change during the sprint. team members should not be expected to create a perfect sprint plan. Instead, they should do just enough to confirm they have selected the right set of product backlog items, not too many and not to few, and have a rough idea of how they'll get their work done. The official time box for a four-week sprint is eight hours. It's progressively shorter for teams doing shorter sprints, down to two hours for team doing one-week sprits. I think these are reasonable time boxes or limits for the team that is new to Scrum. For experienced teams, I recommend targeting 45 minutes per week of sprint duration. That means 90 minutes to plan a two- week sprint and three hours to plant a 4-Week sprint. After the developers have selected the work they can do in a sprint, the entire Scrum team should revisit the draft sprint goal. They may choose to reword it, perhaps making it smaller or larger, based on the results of the sprint planning meeting.