Empirical Process Control: Steer by Observing, Not by Plan

THE MENTAL MODEL: Empiricism is the idea that knowledge comes from experience. In product development, this means you can't know everything upfront. Empirical process control is a strategy for navigating complexity by making decisions based on what you observe from doing the work, rather than following a detailed, predictive plan. It's an iterative, incremental approach designed to optimize predictability and control risk by learning as you go.

HOW IT WORKS: This model is built on three pillars. First, TRANSPARENCY: the process, the work, and any problems must be visible to everyone. Key artifacts like the Product Backlog must be an accurate, shared source of truth. Low transparency leads to decisions that diminish value. Second, INSPECTION: the team must frequently check the artifacts and their progress toward goals to spot undesirable variances. Scrum provides a cadence for this with its formal events. Third, ADAPTATION: if inspection reveals that the process or product is off-track, the team must adjust. Inspection without adaptation is considered pointless.

WHEN TO USE IT: Empirical process control is the foundation of Scrum and is designed for complex problem domains where more is unknown than known. Use it when requirements are likely to change, when technical challenges are unpredictable, or when you need to generate value through adaptive solutions. Scrum's events—like the Daily Scrum for inspecting Sprint progress and the Sprint Review for inspecting the product Increment—are all formal opportunities to apply this model.

WHEN NOT TO USE IT: This approach is inefficient for simple, well-understood problems where the process and outcomes are predictable. If you are following a known procedure with no new variables, a more defined, predictive process is more efficient. Using an empirical process here would introduce unnecessary overhead for inspection and adaptation when none is needed.

ONE CANONICAL EXAMPLE: A Scrum Team finishes a Sprint. At the Sprint Review, stakeholders see the working Increment and realize a key feature, while built to spec, doesn't solve their actual problem. Because the process is transparent (they see the real product) and enables inspection (the review itself), the team can adapt. The Product Owner re-orders the Product Backlog for the next Sprint based on this new knowledge. Without this empirical loop, the team might have continued building the wrong thing based on the original, flawed plan.