The right number is your team's average velocity from the last 3-5 sprints, adjusted for any changes in capacity this sprint. If your team has averaged 32 points over the last four sprints, committing to 32 points (with the same team composition and no holidays) is appropriate. Committing to 48 to "stretch" the team will produce incomplete sprints, which is worse than completing 32 points well. Velocity should be measured, not aspirational.

A sprint goal is the outcome the team is working toward · a single, meaningful statement of what the sprint will achieve for users or the business. The sprint backlog is the list of tasks selected to achieve that goal. Teams often confuse the two, or skip the goal entirely and only select tasks. A sprint without a clear goal has no coherence · team members cannot make good decisions about what to do when something unexpected happens. The goal is the compass; the backlog is the map.

In Scrum, the Product Owner orders the backlog and brings the highest-priority items to sprint planning. The Developers select how much they can take on based on capacity and complexity, in discussion with the Product Owner. In practice, many teams operate more collaboratively, with the whole team involved in prioritization. The key principle is that the team doing the work commits to the work · not the manager, not the stakeholder.

First, communicate early · as soon as it becomes clear that the sprint goal is at risk, raise it. Mid-sprint adjustments are acceptable: items can be descoped with the Product Owner's agreement if the sprint goal can still be achieved. At the end of the sprint, incomplete items return to the backlog rather than automatically rolling over. Rolling incomplete items over without re-estimating them hides the team's actual velocity and makes future planning unreliable.

The Scrum Guide caps sprint planning at eight hours for a one-month sprint, and shorter sprints usually need less. A common rule of thumb scales the cap with sprint length, so a two-week sprint plans in four hours or less. The meeting answers three questions: why this sprint is valuable, what can be done in it, and how the chosen work will get done. When planning runs long, the cause usually sits upstream: backlog items arrive too large or too vague to estimate. Refine the top of the backlog before the meeting, and planning becomes a matter of choosing and committing. Source: Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020).