Empiricism is why Scrum favors short iterations with working software over big-design-up-front: the team cannot reliably predict a complex product, so they generate evidence and adapt. Every Scrum event and artifact exists to feed this empirical loop.

Transparency makes the work visible to everyone responsible. Inspection means frequently checking progress toward the Sprint Goal. Adaptation means adjusting the product or the process as soon as evidence demands it. Remove any one pillar and the empirical loop breaks.

The 2020 Scrum Guide renamed these from ‘roles’ to ‘accountabilities’ to emphasize that each name corresponds to who is answerable for an outcome, not to a job title or org-chart position.

Each artifact has a corresponding commitment that makes it transparent: the Product Backlog → the Product Goal; the Sprint Backlog → the Sprint Goal; the Increment → the Definition of Done. Without the commitment, the artifact is just a list.

Values and pillars are deliberately separated. The three pillars (Transparency, Inspection, Adaptation) structure the empirical process. The five values guide team behavior — how members commit to the goal, focus on the work, stay open with each other, treat each other with respect, and find the courage to surface hard truths.

Notice the partition: what, how, and process. The three accountabilities are intentionally non-overlapping — that’s why the Guide does not let the Scrum Master also order the backlog, or the Product Owner also decide implementation details.

If a Scrum Master starts assigning work or running status reports for upper management, they have collapsed the team’s self-management. The team — not the Scrum Master — owns how the Sprint Goal is delivered. The Scrum Master’s job is to protect the conditions that make that ownership possible.

Cross-functionality fights handoff delay (waiting on another team to finish their part). Self-management fights direction delay (waiting on a manager to assign work). Together they shorten the feedback loop empiricism depends on. A team that needs an external ‘DB team’ to ship a feature, or an external manager to schedule the work, is not yet a Scrum Team.

Without a Definition of Done, ‘done’ becomes negotiable and Increments quietly accumulate hidden work. The Definition of Done protects the Sprint Review by ensuring the team is showing work that has actually met its agreed quality bar.

Calling the Sprint an event (not a phase or stage) is deliberate: it has a fixed duration, a defined start and end, and contains the other four events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). Stretching a Sprint to fit unfinished work breaks the empirical cadence and removes the team’s incentive to honestly inspect what went wrong.

‘Mostly done’ is not done in Scrum. Counting partial work as Increment hides risk and destroys the Sprint Review’s ability to give honest feedback on a working product. The correct response is either to finish the load test inside the Sprint or to surface the gap at the Review and roll the item back into the Product Backlog.

Transparency is the precondition for the other two pillars — you cannot meaningfully inspect what you cannot see, and you cannot adapt to what you do not know about. The shared board is the most common physical embodiment of transparency, but transparency is the principle; the board is one possible artifact.

Inspection is the act of examining progress against the Sprint Goal. The Daily Scrum is one ritualized form of inspection (and also includes the adaptation step that immediately follows), but inspection itself is the underlying principle. Inspection without adaptation is theater; adaptation without inspection is thrashing.

Adaptation is not scope creep. It is a deliberate course correction driven by evidence. Inspection (the team examined the data) and Transparency (the data was visible) were preconditions; adaptation is the pillar that turns the visibility and observation into actual change.

Status reporting can happen as a side effect of transparency (a visible board, a shared Sprint Backlog) but it is not the event’s purpose. The Daily Scrum is a 15-minute planning event for the people doing the work, not a ceremony for managers.

The two events answer different questions. Review asks ‘are we building the right thing?’ (a product question, with stakeholders in the room). Retrospective asks ‘are we building it the right way?’ (a process question, behind closed doors). Conflating them tends to crowd out the harder process conversation, because product feedback is more concrete and easier to discuss.

The argument against combining them is practitioner consensus, not Guide canon. The two accountabilities encode the real tension between what to build and how to build it sustainably; merging them removes the friction that protects long-term capacity.

The ‘failed Sprint’ label is common informal usage but it is not Scrum vocabulary. Scrum’s response to missing the Sprint Goal is empirical: inspect what happened, adapt the process, and protect the cadence by starting the next Sprint on schedule. Naming Sprints ‘successful’ or ‘failed’ tends to push teams toward gaming the Definition of Done.

SAFe’s Program Increment planning, fixed cadences, and Agile Release Train ceremonies do produce alignment across many teams, but they compress local decision-making in ways Scrum’s self-management principle protects. Whether the trade is worth it depends on how tightly coupled the teams actually are — for a small number of loosely coupled teams, the autonomy cost has no offsetting benefit.

Specific items vary by context (regulated software, embedded, internal tools, research code), but most defensible DoDs span these three categories. The key heuristic: every item should map to a specific risk the team will not ship past. Aspirational items (‘code is high quality’) cannot be inspected, so cannot be enforced.