PSM I Scrum Events: The Sprint, Planning, Daily Scrum, Review and Retrospective

The Sprint is a fixed-length event of one month or less that contains every other Scrum event: Sprint Planning, the Daily Scrums, the Sprint Review and the Sprint Retrospective all happen inside it. The Scrum Guide 2020 calls the Sprint the heartbeat of Scrum, the cycle in which ideas are turned into value.

Three properties define it:

• Fixed length. A team picks a Sprint length and keeps it, because the regular rhythm is what creates consistency. Choosing a new length each Sprint to fit the selected work defeats that purpose: the timebox exists so the work is shaped to the Sprint, not the Sprint to the work.
• Back to back. A new Sprint starts immediately after the previous one ends. There is no gap for planning workshops, hardening, testing or "release Sprints". All the work necessary to achieve the Product Goal, including Sprint Planning, the Daily Scrums, the Sprint Review and the Sprint Retrospective, happens within Sprints, and so do the design, building, testing and refinement in between.
• A container. All work and all other events fall inside a Sprint. Nothing in Scrum happens "between Sprints", because there is no between.

The Guide also describes each Sprint as a short project: a bounded bet with a clear goal, after which the team inspects the result and decides what to do next.

A Sprint also does not end early when the work runs out. If the Developers finish everything they selected and the Sprint Goal is met before the timebox ends, the Sprint keeps going: they work with the Product Owner to take on more Product Backlog items, which is the same scope negotiation described in the next section.

During a Sprint the Sprint Goal stays protected while the detail of the work is allowed to change. The Scrum Guide 2020 lists four rules:

1. No changes are made that would endanger the Sprint Goal. The goal is the Developers' commitment for the Sprint.
2. Quality does not decrease. The Definition of Done is never relaxed to squeeze in more work. Skipping required tests to fit an urgent item is a quality cut, not a scope decision.
3. The Product Backlog is refined as needed. Refinement is an ongoing activity inside the Sprint, not a phase before it.
4. Scope may be clarified and renegotiated with the Product Owner as more is learned. The selected items are a forecast, not a frozen contract.

Put together, these rules tell a team what to do when reality diverges from the plan. If the Developers find they cannot finish every selected item but the Sprint Goal is still reachable, they adapt their plan toward the goal and renegotiate the scope with the Product Owner. They do not extend the Sprint, count unfinished work as Done, or cancel and start again. If the Product Owner wants an urgent item added mid-Sprint, the trade-off is made in scope (dropping a lower-value item, for example), never in quality.

Shorter Sprints give a team more learning cycles and limit the cost and effort at risk to a smaller time frame; longer Sprints delay that feedback. The Scrum Guide 2020 states the downside of a long horizon directly: when a Sprint is too long, the Sprint Goal may become invalid, complexity may rise and risk may increase.

Sprint length is therefore a risk lever. Stale goals and too much at stake per Sprint are both symptoms of a long feedback loop, and the Sprint length is what sets that loop: it governs how often a goal is chosen and how often the outcome is inspected with stakeholders. Practices that leave the Sprint length alone treat the symptom rather than the loop, and the Sprint Goal stays protected within a Sprint of any length.

Shorter Sprints do not mean fewer events or bigger Increments; every Sprint, however short, still contains all four inner events. The Guide also notes that forecasting practices such as burn-downs, burn-ups or cumulative flows can be useful, but they do not replace empiricism: what has happened is the only reliable basis for deciding what to do next.

A Sprint can be cancelled only by the Product Owner, and only when its Sprint Goal has become obsolete. That is the whole rule in the Scrum Guide 2020, and both halves matter.

• The condition is an obsolete Sprint Goal. A market change, a competitor's launch or a strategy shift that makes the goal pointless can justify cancelling. Running behind on the forecast, losing a Developer or receiving a new requirement does not; those are handled by re-planning and scope negotiation inside the Sprint.
• The authority belongs to the Product Owner alone. Not the Scrum Master, not the Developers, not stakeholders or executives. Anyone else who believes the goal no longer makes sense raises it with the Product Owner, who makes the call. The Developers' wish to finish items they have started is not a veto, and sunk effort is not a reason to continue a Sprint whose goal no longer matters.

Cancellation should be rare: the Guide sets a narrow condition, and with short Sprints and a well-chosen goal it should seldom be met.

Scrum prescribes its events to create regular, formal opportunities to inspect and adapt the Scrum artifacts. Each event is designed to provide the transparency that inspection and adaptation need; failing to hold an event as intended means losing one of those opportunities. Events are not progress reports for management or approval points between project phases, and inspection and adaptation are not restricted to them.

The events also create regularity, which reduces the need for meetings Scrum does not define. Extra recurring meetings added on top of the events usually mean the events and artifacts are not yet providing the transparency they should. The Scrum answer is to make the events do their job, so the additional meetings stop being needed; dropping or combining Scrum events removes inspection opportunities instead. The Guide also recommends holding the events at the same time and place to reduce complexity.

These timeboxes are maximums, not required durations. Planning, Review and Retrospective are sized for a one-month Sprint and are usually shorter for shorter Sprints; a team on one-week Sprints that books the full eight, four and three hours has misread them. An event can end as soon as its purpose is achieved: a Sprint Planning that has produced a Sprint Goal and a starting plan after three hours ends there and the work begins. It cannot run past its timebox, though. The Daily Scrum is 15 minutes for the Developers as a group, not 15 minutes per person.

Sprint Planning initiates the Sprint by laying out the work to be performed, and the whole Scrum Team creates the plan collaboratively. The Product Owner makes sure attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The team may invite other people to provide advice, such as an expert on a payment provider's interface, but invited advisers inform the decisions; they do not make them. Planning is not postponed until an expert is free.

Topic one: why is this Sprint valuable?

The Product Owner proposes how the product could increase its value and utility in this Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that tells stakeholders why the Sprint is valuable. The goal must be finalised before Sprint Planning ends. The goal is a required output of the event and a whole-team decision. The detailed plan for the Sprint may be incomplete when Planning ends; the Sprint Goal may not.

Topic two: what can be Done this Sprint?

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine those items during the process, which increases understanding and confidence. Selecting how much is hard; the Guide says the more the Developers know about three things, the more confident their forecast will be:

• their past performance,
• their upcoming capacity, and
• their Definition of Done.

These are the only inputs the Guide names, and all three describe the Developers themselves. Numbers that come from outside the team, or describe what someone would like to be finished, say nothing about what these Developers can actually make Done. A team without history still has two of the three to work from.

Topic three: how will the chosen work get done?

For each selected item, the Developers plan the work needed to create an Increment that meets the Definition of Done. This is often done by decomposing items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers: nobody else tells them how to turn items into a Done Increment. Whoever decides technical approaches, hands out tasks to individuals or dictates how the work is broken down from outside the Developers is overstepping, whatever their role. The Product Owner owns what is valuable; the Developers, as a self-managing group, own how it is built.

The Sprint Goal, the selected items and the Developers' plan together form the Sprint Backlog. The plan does not need to be complete for the whole Sprint before work starts; enough is planned to begin, and the rest emerges as the Developers learn.

The Daily Scrum is a 15-minute event for the Developers whose purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. It is held at the same time and place every working day of the Sprint to reduce complexity.

• Who it is for. The Developers. If the Product Owner or Scrum Master is actively working on items in the Sprint Backlog, they take part as Developers, not as observers or facilitators. Stakeholders and line managers are not its audience, and it is not a status report to the Scrum Master or Product Owner.
• The Scrum Master's part. The Scrum Master is accountable for making sure all Scrum events take place and are positive, productive and kept within the timebox. For the Daily Scrum, that means ensuring it happens; the Developers conduct it. A Scrum Master who is not working on Sprint Backlog items does not run it or record updates.
• Structure. The Developers choose whatever structure and techniques they want, as long as the event focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. The three questions (yesterday, today, impediments) were an optional format in the 2017 Scrum Guide and are no longer in the 2020 Guide; they are not required.
• Benefits. Daily Scrums improve communication, identify impediments, promote quick decision-making and so remove the need for other meetings.

The test of a good Daily Scrum is the outcome, not the duration. A meeting that ends within 15 minutes but in which Developers only report yesterday's work and nobody adapts the plan, even though the Sprint Goal is at risk, has missed its purpose.

The Daily Scrum is also not the only time the Developers may adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work, and they do not need anyone's approval to do so.

The Sprint Review exists to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of its work to key stakeholders and progress toward the Product Goal is discussed. During the event the Scrum Team and stakeholders review what was accomplished and what has changed in their environment, and based on that they collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

The Guide is explicit that the Sprint Review is a working session and the team should avoid limiting it to a presentation. It is not a demo followed by formal sign-off. When what stakeholders bring to the Review changes what is valuable, the Product Backlog is adjusted in the session, with them.

The Review is not a release gate

An Increment may be delivered to stakeholders before the end of the Sprint, as soon as it meets the Definition of Done, and a Sprint can produce several Increments. The Scrum Guide 2020 says the Sprint Review should never be considered a gate to releasing value. If a Done Increment is ready on day four and users need it, it can be released on day four. At the Review, the team inspects the sum of all the Sprint's Increments, including those already released.

Frequent releases do not make the Review redundant either. Its job is not to ship work but to inspect the outcome with stakeholders and decide what comes next, which usage data alone or a release-approval meeting cannot replace.

The Sprint Review is the second-to-last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint.

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. It is the team inspecting itself, not the product: the Increment and the Product Backlog belong to the Sprint Review, and progress toward the Sprint Goal belongs to the Daily Scrum.

The Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. It discusses what went well, what problems it met and how those problems were (or were not) solved. Assumptions that led the team astray are identified and their origins explored, including assumptions about things outside the team's control, because how the team planned around them is within it. Individual performance ratings are not part of it.

The team then identifies the changes that would most help its effectiveness. The most impactful improvements are addressed as soon as possible, and they may even be added to the Sprint Backlog for the next Sprint. The 2017 Guide required at least one improvement in the next Sprint Backlog; the 2020 Guide dropped that requirement. They do not have to wait to be ordered alongside features on the Product Backlog, or for the next Retrospective.

The Sprint Retrospective concludes the Sprint and is timeboxed to a maximum of three hours for a one-month Sprint.

The events run in a fixed order: Sprint Planning initiates the Sprint, Daily Scrums happen every working day, the Sprint Review is the second-to-last event, and the Sprint Retrospective concludes the Sprint. The next Sprint, and with it the next Sprint Planning, begins immediately after the Retrospective. So the next Sprint's Planning never comes before the current Sprint's Retrospective, and the Retrospective never comes before the Review.

Many questions on this topic use rules from older Scrum Guides or common folk practice as distractors. The 2020 Guide is the reference:

Accountabilities beyond event participation are covered in the lesson on the Scrum Team; the Sprint Goal, Sprint Backlog and Increment as artifacts, and the Definition of Done itself, are covered in the lesson on artifacts and commitments.