During the sprint planning meeting, the developers will create a sprint backlog. A sprint back log comprises three elements. The sprint goal, a subset of product backlog items selected to be worked on during the Sprint, and a plan for how the team will complete that work. Let's look at each of these three items. First is the spring goal which is a team's single objective for the sprints. The sprint goal should serve as a focal point for the work of a sprint. The goal can also be used for assessing the success of the sprint If the goal was met, the Sprint was a success. A well-formed sprint goal will not define specifically how the developers will achieve the goal. For example, I worked with a team developing data visualization tools. They had a sprint go to triple the number of charts that could be rendered per minute on a given hardware configuration. The team was given a clear goal, but they had many ways they could achieve that goal The second element of a sprint backlog is the subset of product backlog items that developers plan to work on and try to finish during the sprint. During sprint planning, the developers work their way down the prioritized product back log, selecting as many of the most valuable items as possible. As developers are doing this, they are creating the third element, a plan for how they will deliver that work and achieve the Sprint goal. The plan doesn't need to be detailed, thorough, or complete, but the developers should leave sprint planning with a set of product backlog items they plan to deliver within the sprint, and at least a rough plan of how they'll work together to do it. This means that most teams augment the set of product backlog items for this sprint with a short, rough list of tasks for each item. This helps a team assess whether they are committing to too much work, too little, or just the right amount in the coming sprint. No one should expect the team to leave a sprint planning meeting having thought of everything. The sprint backlog will emerge throughout the sprint. A good team will think of most things during sprint planing. But I think it's impossible on a complex project to think all tasks up front. And even if a team does, it is impossible for team members to know who might be out sick or fall behind during the Sprint. So at the end of the sprint planning meeting, the team leaves with a rough plan for how they'll coordinate and work together during the Sprint. But things change. and team members will discover a few new tasks that need to be done as they begin work on each product backlog item. Adding these newly discovered tasks to a sprint backlog should not be confused with adding new product-backlog items within a Sprint. Once a sprints has been planned, the product owner should endeavor to resist the temptation to request new functionality from the team within the Sprints. But that's different from a team adding into its own sprint backlog a task or step they did not identify during the planning meeting.