Empiricism and the three pillars

Why the framework is empirical at all

Scrum is built for work where the decisive unknowns cannot be settled on paper before it starts: what a customer will actually use, how the technology behaves under real load, what the regulator decides in March. On that kind of problem a detailed up-front plan is not merely optimistic, it is a claim to knowledge nobody has yet, and it holds right up to the moment the first real evidence arrives.

The alternative is stated in one sentence in the Scrum Guide: "Empiricism asserts that knowledge comes from experience and making decisions based on what is observed." Note what it does not say. It does not say stop planning — Scrum plans at every Sprint Planning and again every day at the Daily Scrum. It changes what the plan is made of. A forecast you expect the next fortnight to correct is empiricism; a commitment you expect the next fortnight to conform to is not.

Alongside empiricism sits lean thinking, which is the instruction to strip out what is not essential. It is why the framework is as small as it is, and it is quietly useful in the exam room: an answer that solves a described problem by adding a meeting, a role, a report or an approval step is usually the wrong one on this paper.

Transparency first, and why the order cannot be shuffled

The three pillars are usually recited as a list and they are not a list, they are a chain. Transparency means the Product Backlog, the Sprint Backlog and the Increment describe what is really there, in terms everyone reading them understands the same way. Inspection is looking at them frequently and diligently. Adaptation is changing something because of what was seen.

Each one is worth nothing without the one before it, and the Guide is unusually blunt about both failures: inspection without transparency is misleading and wasteful, and "Inspection without adaptation is considered pointless." That gives the exam two ready-made scenarios and they are the two it uses. Items marked Done on the board that never met the Definition of Done is the first — the Sprint Review then inspects a picture that is false, and decisions taken confidently from a false picture are worse than no decision. The same impediment named in six consecutive Retrospectives is the second: the team sees the problem perfectly well, and nothing downstream of seeing it ever happens.

Read a scenario for which link broke. If nobody could see it, that is transparency. If they could see it and never looked, that is inspection. If they looked and nothing changed, that is adaptation — and adding a seventh inspection to a team that acted on none of the previous six is the answer that sounds diligent and changes nothing.

Adaptation does not wait for an event

Scrum gives inspection a cadence — five events, four of them held inside the fifth — but the cadence is a floor, not a queue. When the Developers learn mid-Sprint that a third-party dependency will not behave as assumed, the adjustment is made as soon as possible so that the deviation stops compounding, and the Sprint Backlog changes that day. Parking it until the Retrospective is a week of building on something known to be wrong, and the Retrospective is the wrong event for it anyway.

The three inspection events adapt three different things, and almost every question of the form "which event" resolves by asking which one is being changed. The Daily Scrum adapts the Sprint Backlog, which is today's plan. The Sprint Review adapts the Product Backlog, which is what the product should do next. The Sprint Retrospective adapts the Scrum Team itself, which is how the work gets done.

One further line from the theory earns its place in the exam room: adaptation becomes harder when the people involved are not empowered or self-managing. That is why self-management is a structural requirement in Scrum rather than a cultural preference. A team that has to ask permission cannot change its plan at the speed inspection reveals the need to, so the pillar quietly stops working.