Most candidates preparing for the PSM I can name them without hesitation: transparency, inspection, adaptation. What trips people up on the exam is not the vocabulary — it’s the precise relationships between these pillars, how they’re expressed in every Scrum event and artifact, and the exact language the 2020 Scrum Guide uses when it matters. This article breaks down empiricism the way the exam tests it, with direct quotes from the Scrum Guide so you know exactly what you’re working with.
What Empiricism Actually Means in Scrum
The 2020 Scrum Guide opens its theory section with a precise statement: “Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.”
That last word — observed — is worth noting. The 2017 Scrum Guide said “based on what is known.” The 2020 update to “based on what is observed” narrows the claim: you don’t just need to know something, you need to have observable evidence. This distinction has shown up in practice exam questions that ask candidates to spot the difference between these two versions.
Lean thinking is the other half of Scrum’s foundation, and candidates often ignore it. The Scrum Guide defines it simply: lean thinking “reduces waste and focuses on the essentials.” It explains why Scrum resists over-engineering, overly detailed upfront plans, and processes that produce no inspectable output.
Together, empiricism and lean thinking explain why Scrum works the way it does — short Sprints, transparent artifacts, frequent inspection opportunities, and the expectation that the plan will change as you learn more. Exam questions that ask “why does Scrum use Sprints instead of longer planning horizons?” or “why should the Product Backlog be continuously updated?” are ultimately empiricism questions.
The Three Pillars: Sequence and Dependencies
The Scrum Guide describes the pillars in a specific order — and that order is intentional. Understanding the chain of dependencies is exactly what separates candidates who merely memorize the terms from those who answer scenario questions correctly.
Transparency
The Scrum Guide states: “The emergent process and work must be visible to those performing the work as well as those receiving the work.” Notice the two audiences: the people doing the work and the people receiving it. Both need visibility. A Sprint Backlog that only the Developers understand, or a Product Backlog that stakeholders can’t access, fails this requirement.
The Guide adds the stakes: “Artifacts that have low transparency can lead to decisions that diminish value and increase risk.” Transparency is not a nice-to-have — it is a precondition for every good decision made in Scrum.
Then comes the dependency that the exam loves to test: “Transparency enables inspection. Inspection without transparency is misleading and wasteful.”
If the Sprint Backlog doesn’t accurately reflect the real state of the work, what happens at the Daily Scrum? The Developers are inspecting a fiction. They’ll adapt to something that isn’t real. This is the cascading failure that low transparency creates — and why the Scrum Guide treats transparency not as a principle but as a hard prerequisite for everything else.
Inspection
The Scrum Guide says: “The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events.”
Two things to hold onto here. First, the word “diligently” — inspection isn’t a checkbox. It requires genuine attention from skilled people who can recognize when something is off. Second, the Guide notes that Scrum provides cadence through its five events specifically to support inspection. This means the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective each serve the empirical cycle — not just as process milestones, but as structured opportunities to catch problems early.
The Guide then states the dependency going the other direction: “Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.”
That phrase “designed to provoke change” is powerful. Sprint Reviews are not demos. Retrospectives are not venting sessions. Every event in Scrum is, by design, an invitation to change something. If your team runs the events but nothing ever changes, the events aren’t working as intended.
Adaptation
The Scrum Guide is precise about when adaptation must happen: “If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.”
The phrase “as soon as possible” is exam-critical. A common wrong-answer trap presents a scenario where a team discovers a problem during a Sprint and waits until the next Sprint Planning to address it. The Scrum Guide explicitly contradicts that: “A Scrum Team is expected to adapt the moment it learns anything new through inspection.” There is no prescribed waiting period. If the Daily Scrum reveals that the current approach won’t reach the Sprint Goal, the plan changes that day — not next Sprint.
The Guide also introduces an organizational constraint: “Adaptation becomes more difficult when the people involved are not empowered or self-managing.” This ties the empirical pillars directly to the Scrum Team’s self-managing nature. A team that needs managerial approval before changing its approach cannot adapt quickly enough to benefit from empiricism. This is one of the reasons Scrum Teams are explicitly self-managing.
How Every Scrum Event Expresses the Pillars
The Scrum Guide states: “Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt.”
That last sentence is a common exam answer. When a question asks “what is the consequence of skipping the Sprint Review?” or “what happens if the Daily Scrum is cancelled?”, the correct frame is always: you lose a structured opportunity to inspect and adapt. The events aren’t bureaucratic overhead — they are the mechanism through which empiricism actually happens.
Here is how each event maps to the empirical cycle:
- Sprint Planning: The team inspects the Product Backlog and their own capacity/velocity, then adapts — selecting what to build and how to build it based on what they actually know right now, not on predictions made months ago.
- Daily Scrum: The Scrum Guide says its purpose is “to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.” It is a 24-hour inspect-and-adapt cycle on the execution of the current Sprint.
- Sprint Review: “The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.” It is product-level feedback — the Increment is presented to stakeholders, the environment is discussed, and the Product Backlog may be adapted to reflect new information.
- Sprint Retrospective: “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.” The Scrum Team inspects itself — its interactions, processes, tools, and Definition of Done — and adapts how it works, not just what it builds.
- The Sprint itself: Sprints create the outer rhythm. The Scrum Guide notes that they “enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.” Longer Sprints undermine this cadence, which is why the Guide also says: “When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase.”
How Artifacts Are Built Around Transparency
The Scrum Guide is explicit: “Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.”
That last phrase connects all three pillars in a single sentence. The artifacts exist to create shared transparency, which enables accurate inspection, which gives the team a common basis for adaptation. Remove transparency from any artifact, and both downstream pillars collapse.
Each artifact has a commitment attached to it — and this is a 2020 Scrum Guide addition that the exam tests directly:
- The Product Backlog has the Product Goal as its commitment.
- The Sprint Backlog has the Sprint Goal as its commitment.
- The Increment has the Definition of Done as its commitment.
The Guide explains why: “These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.” Without commitments, the artifacts are just lists. With commitments, they become transparent signals of intent and progress — something that can actually be inspected and adapted against.
A practical example: if the Definition of Done is vague, then the Increment at Sprint Review is opaque. Stakeholders can’t make meaningful decisions about what to adapt next because they don’t know what “done” means. The Definition of Done exists precisely to make the Increment inspectable.
The Scrum Values Complete the Picture
Candidates sometimes treat the five Scrum values (Commitment, Focus, Openness, Respect, Courage) as a separate topic from empiricism. The Scrum Guide explicitly links them: “When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.”
Without the values, empiricism breaks down in practice:
- Openness is what makes transparency real. A team that hides problems from the Product Owner is violating openness — and producing low-transparency artifacts as a result.
- Courage is what makes inspection honest. It takes courage to surface a Sprint that’s off-track at the Daily Scrum rather than saying “things are fine.”
- Commitment and Focus create the conditions for timely adaptation — a team committed to the Sprint Goal will adapt its approach rather than abandon the goal at the first sign of difficulty.
- Respect makes adaptation feel safe. If team members fear blame for course corrections, adaptation gets delayed until the problem is unavoidable.
The Scrum Guide notes: “The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts.” The values are not abstract ideals — they are learned through participation in the empirical cycle itself.
Four Exam Traps You Should Know About
Understanding the pillars conceptually is necessary but not sufficient. Here are the specific misapplications that exam scenarios are designed to expose:
1. “We’ll wait until the next Sprint to adapt.”
Wrong. The Scrum Guide says adaptation must happen “as soon as possible.” A team that discovers on Day 8 that their technical approach is failing does not wait until Sprint Planning to change course.
2. “We’ll skip the Sprint Review since the increment isn’t complete.”
Wrong on two counts. First, skipping any event loses a formal inspect-and-adapt opportunity. Second, the Sprint Review’s purpose includes inspecting what was accomplished and adapting the Product Backlog in response — even a partial outcome is valuable information.
3. “Transparency means sharing information with the Scrum Team only.”
The Scrum Guide specifically says the emergent process and work must be visible “to those performing the work as well as those receiving the work.” Stakeholders need visibility too, especially at the Sprint Review.
4. “Burndown charts replace empiricism.”
The Scrum Guide explicitly addresses this: “Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.” Forecasting tools inform empiricism; they don’t substitute for it.
How This Shows Up on the PSPO I as Well
If you’re preparing for the PSPO I, empiricism is equally central. The Product Owner’s accountability for the Product Backlog is fundamentally an empiricism responsibility: keeping the backlog transparent, ordered, and understood so that the Scrum Team and stakeholders can inspect and adapt effectively. The Scrum Guide states that the Product Owner is accountable for “ensuring that the Product Backlog is transparent, visible and understood” — transparency, in the service of inspection and adaptation, is the Product Owner’s daily work.
PSPO I scenarios frequently test whether a candidate understands that the Product Owner’s decisions (content and ordering of the Product Backlog, the inspectable Increment at Sprint Review) are the primary vehicle through which product empiricism happens. A Product Owner who updates the backlog once a quarter is breaking the inspect-and-adapt cycle just as surely as a team that skips its Daily Scrum.
Practice with the Concepts, Not Just the Definitions
The most effective way to prepare for empiricism questions is to encounter them in scenario form — where you’re asked to identify what’s wrong with a team’s behavior, or choose the best response to a situation, rather than simply recall definitions. The PSM I exam is not a vocabulary test. It presents realistic team scenarios and expects you to reason from Scrum principles.
The PSM I Exam Simulator includes questions specifically designed around the three pillars — asking you to diagnose anti-patterns, select correct responses to inspection findings, and identify which events are being violated and why. If you want to test where your understanding of empiricism stands before the exam, the free 20-question PSM I practice test is a good starting point.
For PSPO I candidates, the same empirical reasoning applies to product decisions. The PSPO I Exam Simulator tests whether you can apply transparency, inspection, and adaptation from the Product Owner’s perspective — including Product Backlog management, stakeholder engagement, and value delivery.
The three pillars are simple to name and genuinely hard to apply correctly under exam pressure. Knowing the Scrum Guide’s exact language — and the reasoning behind it — is the difference between recognizing a correct answer and being certain about it.