Fix the time and fix the team, and the only thing left to vary is how much gets done. That is the sprint's bargain. At the start the team and the product owner agree a goal, a single sentence about why this sprint matters, and select the backlog items they believe will achieve it. During the sprint the goal does not change; the items may be renegotiated with the owner as understanding grows, but not the goal. At the end, on the day, whatever is done is shown to stakeholders in the review, the team examines its own working in the retrospective, and the next sprint starts. There is no gap between sprints, no hardening sprint, no sprint zero; those are containers invented to avoid the discipline of the fixed one.
Why a month or less
Long enough to build something a stakeholder can react to; short enough that a wrong direction costs at most a month. Two weeks is the common choice because it lets a team show something every fortnight without spending half its time in the events. Shorter sprints suit teams with fast feedback and small items; longer ones suit work with real lead times. Whatever is chosen stays chosen, because the team's sense of what fits in a sprint is learned by repetition, and a moving length never lets it form.
- Planning: what can be done this sprint, why it matters, and how the team will do it. Bounded to a few hours for a two-week sprint.
- The daily scrum: fifteen minutes in which the people doing the work replan the day toward the goal. Not a report.
- The review: the increment shown working to the people who asked for it, and the backlog adjusted by what they say. Not a demonstration of slides.
- The retrospective: how the team worked, what to change, one improvement into the next sprint.
- Cancellation: the owner may cancel a sprint whose goal has become obsolete. Rare, allowed, and better than pretending.