Scrum guide · Scrum basics
Empiricism in Scrum: Inspect and Adapt Explained
Scrum is founded on empiricism: the idea that knowledge comes from experience and decisions should be based on what is observed. Rather than predicting everything up front, Scrum creates frequent opportunities to inspect real results and adapt.
Key takeaways
- Empiricism bases decisions on observation, not prediction.
- Every Scrum event is an opportunity to inspect and adapt.
- Without transparency, inspection is unreliable.
Why complex work needs empiricism
In simple work, cause and effect are known, so a detailed plan works. In complex work, such as new products, unknowns outweigh knowns, and plans quickly become outdated. Empiricism replaces prediction with short feedback loops, so mistakes are small and corrected quickly.
Lean thinking
The Scrum Guide notes that Scrum also employs Lean thinking: reducing waste and focusing on essentials. Together, empiricism and Lean thinking explain why Scrum keeps cycles short and work small.
Inspect-and-adapt events
| Event | What is inspected | What is adapted |
|---|---|---|
| Sprint Planning | Product Backlog, capacity, past performance | The Sprint Goal and Sprint Backlog |
| Daily Scrum | Progress towards the Sprint Goal | The plan for the next day |
| Sprint Review | The Increment and the market | The Product Backlog |
| Sprint Retrospective | People, processes, tools, Definition of Done | How the team works |
The Sprint itself contains all these events and provides the overall rhythm.
Pitfalls
- Inspecting without adapting: noting problems but changing nothing.
- Low transparency: if the Increment isn't really done, inspection is based on false information.
- Skipping events when busy, which removes feedback just when it matters most.
Frequently asked questions
What is empiricism?
An approach in which knowledge comes from experience and decisions are made based on what is observed.
How often does a Scrum Team apply empiricism?
It inspects and adapts daily at the Daily Scrum, and at least once per Sprint at Planning, Review and Retrospective.
What are the three pillars of empiricism?
Transparency, inspection and adaptation. Scrum's events and artifacts exist to make these three pillars work in practice.
Is empirical process control the same as empiricism?
Essentially, yes. Empirical process control applies empiricism to managing work: observing actual results and adjusting, rather than following a detailed plan made in advance. It suits complex work where outcomes cannot be reliably predicted.
Why is Scrum based on empiricism?
Because complex work has more unknowns than knowns, so long-range predictions soon become inaccurate. Short cycles of inspecting real results and adapting keep mistakes small and learning fast.
How does empiricism differ from a defined process?
A defined process follows a fixed set of steps that produce predictable results, which suits simple, repeatable work. An empirical process relies on frequent inspection and adaptation because outcomes vary, which suits complex work.
How does Lean thinking relate to empiricism in the Scrum Guide?
The 2020 Scrum Guide says Scrum is founded on empiricism and Lean thinking. Lean thinking means reducing waste and focusing on the essentials. See Scrum vs Lean.
Which Scrum event is not an opportunity for empiricism?
None. The Scrum Guide describes every event as a formal opportunity to inspect and adapt, with the Sprint acting as the container for the others.
How does the Definition of Done support empiricism?
It makes the state of the Increment transparent, so everyone knows exactly what done means. Without a clear Definition of Done, inspection at the Sprint Review can be based on false assumptions.
Can empiricism work with long Sprints?
It can, but longer Sprints mean slower feedback and more risk per cycle. If the Sprint horizon is too long, the Sprint Goal may become invalid and complexity may rise.
What is an example of empiricism in Scrum?
A team releases a new sign-up flow, sees at the Sprint Review that most users drop out on the second page, and the Product Owner re-orders the backlog to fix that page first. Observed data, not the original plan, drives the next decision.