2.1 Empiricism & Three Pillars
Key Takeaways
- The 2020 Scrum Guide states Scrum is founded on empiricism and lean thinking; empiricism asserts that knowledge comes from experience and that decisions are based on what is observed.
- Scrum employs an iterative, incremental approach to optimize predictability and control risk — not a detailed multi-month plan locked before delivery.
- Empiricism is upheld by three pillars: Transparency, Inspection, and Adaptation; Transparency enables Inspection, and Inspection enables Adaptation.
- Artifacts with low transparency lead to decisions that diminish value and increase risk — a direct Product Owner concern because important decisions rest on the perceived state of the three formal artifacts.
- The Product Owner must keep the Product Backlog transparent, visible, and understood; the inspectable Increment and adapted ordering are how value decisions stay empirical.
Product Owners are hired to maximize product value. The 2020 Scrum Guide tells you how that maximization is supposed to work: not by predicting the perfect backlog months ahead, but by running an empirical process. This section is the theoretical foundation for almost every PSPO I scenario that contrasts “plan harder” with “inspect and adapt.”
Scrum Theory in One Sentence
The Guide opens Scrum Theory with a sentence the exam often tests nearly 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 chapter section focuses on empiricism and the three pillars that implement it. Lean thinking and complex work are covered in the next section; values come after that.
Break empiricism into its two halves:
- Knowledge comes from experience — the most reliable evidence about product value is a real Increment in use (or at least inspectable by stakeholders), not a slide deck or a Gantt chart.
- Decisions based on what is observed — ordering the Product Backlog, proposing Sprint value, and adjusting after a Sprint Review should rest on observed outcomes, market signals, and honest artifact state — not on hope or political pressure alone.
The Guide continues: Scrum employs an iterative, incremental approach to optimize predictability and control risk. Iterative means short repeated cycles; incremental means each cycle produces a usable piece of value. Together they let the Product Owner and Scrum Team learn early instead of betting the budget on one big release.
Empirical Process Control vs. Defined Process Control
Empiricism is the control model for complex work, where both the problem and the solution emerge. Contrast that with defined (predictive) control, which fits repeatable, well-understood work.
| Dimension | Empirical / adaptive (Scrum) | Defined / predictive |
|---|---|---|
| Best for | Complex product work, uncertain requirements | Stable, well-understood processes |
| Planning | Continuous, just enough, just in time | Detailed and largely up front |
| Feedback | Frequent short cycles (at least every Sprint) | Often only at the end |
| Change | Expected; Product Backlog emerges | Treated as a deviation to suppress |
| Risk | Capped roughly to one Sprint of cost | Concentrated near a big delivery date |
| Product Owner stance | Hypothesize, release small, inspect outcomes | Specify everything before build |
A classic wrong instinct on the exam is: “We will get more predictability if we lock scope for nine months.” In Scrum, predictability comes from frequent inspection of real results and adapting the backlog — not from freezing a plan. Forecasts (release plans, burn charts) can help, but the Guide is explicit that in complex environments only what has already happened may be used for forward-looking decision making. Practices like burn-downs do not replace empiricism.
The Three Pillars
Scrum’s empirical control is enabled by three pillars: Transparency, Inspection, and Adaptation. The four formal events inside the Sprint (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) exist because they implement these pillars. The Sprint is the containing event.
| Pillar | 2020 Guide meaning (paraphrased tightly) | Product Owner implication |
|---|---|---|
| Transparency | Emergent process and work must be visible to those doing the work and those receiving it; important decisions are based on the perceived state of the three formal artifacts | Keep Product Backlog content and order honest; never “greenwash” status; ensure stakeholders can see true progress via a usable Increment |
| Inspection | Artifacts and progress toward agreed goals must be inspected frequently and diligently to detect undesirable variances | Use Sprint Review (and ongoing learning) to inspect value vs. Product Goal; inspect backlog readiness, not only feature counts |
| Adaptation | If process or product is unacceptable, adjust as soon as possible | Re-order the Product Backlog when evidence changes; renegotiate Sprint scope with Developers without endangering the Sprint Goal when learning appears |
The Guide’s causal chain is testable:
- Transparency enables inspection. Inspection without transparency is misleading and wasteful.
- Inspection enables adaptation. Inspection without adaptation is pointless. Scrum events are designed to provoke change.
Transparency — and why low transparency destroys value decisions
The Guide is blunt: artifacts that have low transparency can lead to decisions that diminish value and increase risk. That sentence is written for Product Owners as much as anyone. If the Product Backlog hides incomplete items as “almost done,” if “Done” means something different to every stakeholder, or if the Increment at Sprint Review is a partial demo that cannot actually be used, then every ordering decision the Product Owner makes is based on fiction.
Concrete Product Owner duties that create transparency (Guide language you should recognize):
- Ensuring the Product Backlog is transparent, visible, and understood
- Developing and explicitly communicating the Product Goal
- Creating and clearly communicating Product Backlog items and their order
- Relying on an Increment that meets the Definition of Done so what is inspected is real
The organization must respect Product Owner decisions; those decisions are made visible in backlog content and ordering and through the inspectable Increment at the Sprint Review. Visibility without honesty is not transparency — it is theater.
Inspection — what a Product Owner inspects
Inspection is frequent and diligent, not annual. For Product Owners, the highest-stakes inspection moments include:
- Sprint Review — inspect the outcome of the Sprint, progress toward the Product Goal, and environmental changes with stakeholders; the Product Backlog may be adjusted
- Ongoing Product Backlog refinement — inspect item clarity, order, and readiness so Sprint Planning is not a guessing game
- Evidence of value — usage metrics, customer outcomes, support load, revenue, risk reduction — whatever the product domain uses to observe reality
Inspection without a real Increment is weak inspection. Presenting unfinished work as if it were Done undermines the pillar and misleads adaptation.
Adaptation — the Product Owner’s primary lever
When inspection shows the product or process is off course, adapt as soon as possible. For the Product Owner, adaptation shows up as:
- Reordering the Product Backlog when stakeholder needs or market evidence change
- Proposing different Sprint value in the next Sprint Planning (“Why is this Sprint valuable?”)
- Collaborating with Developers to clarify or renegotiate Sprint Backlog scope when work turns out different than expected, without endangering the Sprint Goal
- Cancelling a Sprint only if the Sprint Goal becomes obsolete (Product Owner authority alone)
Adaptation is harder when people are not empowered or self-managing. A Product Owner who dictates task-level “how” or ignores Developer capacity destroys the conditions for timely adaptation.
Putting the Pillars Together for PSPO I
Memorize the operational formula:
Short cycles + honest artifacts + willingness to change = empirical product ownership.
If a scenario delays the first usable Increment for months, hides bad news in the backlog, or treats Sprint Review as a slide presentation with no backlog change, the process has left empiricism even if it still uses Scrum vocabulary. Your job on the exam is to name the broken pillar and restore transparency, inspection, or adaptation — usually by making work visible, inspecting a Done Increment, and adapting order or goals based on what was observed.
According to the 2020 Scrum Guide, which statement best defines empiricism?
A Product Owner keeps unfinished items marked as “on track,” demos partial work that does not meet the Definition of Done, and stakeholders then fund the next quarter based on that picture. Which Scrum pillar is most directly violated, and what does the Guide say can result?
How does the 2020 Scrum Guide relate Transparency, Inspection, and Adaptation?