2.2 Empiricism and Empirical Process Control

The Theoretical Foundation

The 2020 Scrum Guide opens its theory section with a sentence the PSM I exam tests almost verbatim: "Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials." This section unpacks empiricism; the next two cover the three pillars and lean thinking.

Break empiricism into its two halves and you have the whole idea:

• Knowledge comes from experience — you discover the right product and the right way to build it by doing the work and inspecting real results, not by perfecting a plan in advance. The most reliable data is a working Increment in the hands of stakeholders.
• Decisions based on what is observed — when you decide what to build next or how to improve, you act on evidence (a real Increment, real stakeholder feedback, actual progress against a goal), not on assumptions or status reports.

Empiricism is the antidote to the planning fallacy that dominates predictive projects: the belief that with enough analysis you can foresee the right product and the exact path to it. In complex work that belief is false, so Scrum substitutes learning loops for forecasting accuracy. You do not eliminate uncertainty by planning harder; you reduce it by shipping something small, observing how it lands, and adjusting. This is why the exam treats 'we just need a more detailed plan' as the wrong instinct for complex work.

The Guide continues: "Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation." The Guide also frames the cadence: "Scrum employs an iterative, incremental approach to optimize predictability and to control risk." Iterative means you repeat short cycles; incremental means each cycle adds a usable piece of value. Together they let the team learn early and often instead of betting everything on one big delivery.

Empirical vs. Defined Process Control

This contrast is a classic PSM I question pattern, and it traces back to complexity theory: empirical process control is appropriate when the work is too complex to specify reliably up front. Empirical process control (also called adaptive control) inspects real outputs frequently and adapts based on what it sees. Defined process control (also called predictive control) assumes the work is well understood, so it can be planned fully in advance and executed with little change.

Most product development is complex: requirements are uncertain, technology shifts, and what users actually need is discovered through use. That is why Scrum chooses empiricism. The exam wants you to recognize that prescribing a full multi-month plan, locking scope, and forbidding change is the opposite of empiricism — it is defined/predictive control. A common distractor claims 'predictability is achieved by locking scope before the first Sprint'; in Scrum, predictability comes from frequent inspection of real results, not from freezing the plan.

How Scrum Operationalizes Empiricism

Empiricism is not abstract philosophy — Scrum's events and artifacts are the machinery that delivers it. Each event is a formal opportunity to inspect something real and adapt:

• The Sprint is a short, fixed-length container (one month or less) that bounds risk to a single Sprint's cost and creates a regular cadence of learning. If a Sprint runs long, the cost and risk of being wrong grow with it.
• Sprint Planning inspects the Product Backlog and capacity to produce a Sprint Goal and plan.
• The Daily Scrum inspects progress toward the Sprint Goal and adapts the Sprint Backlog as needed.
• The Sprint Review inspects the Increment and progress toward the Product Goal, adapting the Product Backlog with stakeholders.
• The Sprint Retrospective inspects how the last Sprint went and adapts how the team works.
• Artifacts — Product Backlog, Sprint Backlog, Increment — make work and progress transparent so that inspection is meaningful rather than guesswork.

A useful exam heuristic: every time the Guide describes an event, ask 'what is being inspected, and what gets adapted?' If a team plans for six months and never inspects a real Increment until the end, it has abandoned empiricism even if it holds ceremonies on a calendar. The formula to memorize: short cycles + honest inspection + willingness to change = empirical control; long cycles + rigid plans + change resistance = predictive control wearing Scrum vocabulary. The presence of a Daily Scrum on the calendar does not make a process empirical if nothing real is inspected and nothing is allowed to change.

A final connection the exam rewards: empiricism is why short Sprints exist. A one-month-or-less Sprint caps the cost of being wrong to roughly one Sprint of effort, and it forces a working Increment into the light at a predictable cadence. Lengthen the Sprint and you increase the gap between decision and feedback, which is exactly the risk empiricism is designed to control. So when a scenario stretches Sprints to 'fit more work' or delays the first real Increment, recognize it as moving away from empirical control toward the predictive model Scrum rejects.