Empirical Process Control in Scrum, Explained

Why is software development an empirical process—not a defined one? In this Scrum Foundations lesson, Mike Cohn breaks down the essential difference between defined processes (like cooking burgers on a conveyor belt) and empirical processes (like navigating a flight through unpredictable weather). If you're leading teams, building products, or stepping into an Agile role, understanding this distinction is foundational. Defined processes work when every step is predictable. But product development isn’t assembly-line work—it's complex, changing, and impossible to script upfront. In this lesson, you’ll learn: What makes a process “defined”—and why it works in simple, repeatable environments Why product development requires empirical thinking The three pillars of empirical process control: • Transparency • Inspection • Adaptation How Scrum creates structure around complexity so teams can make better decisions, deliver value, and improve continuously Scrum isn’t about following a rigid plan—it’s about making work visible, inspecting reality, and adapting based on what you learn. If your team treats software development like a defined process, this lesson will shift your thinking—and strengthen your foundation for agility. If you want to go deeper on Scrum theory and practical skills, you’ll find more lessons like this in the Agile Skills Video Library. 👉 https://www.mountaingoatsoftware.com/training/courses/agile-skills-video-library?utm_source=YouTube Chapters 00:00 Two Types of Processes 01:27 Defined Process 01:48 Empirical Process 02:59 Better Type of Process for Software or Product Development 04:14 The Third Pillar of Empirical Process