Empirical vs. Defined Process Control in Scrum: A Complete Guide

Empirical Process Control vs. Defined Process Control

Empirical process control expects the unexpected, while defined process control assumes every task can be fully understood in advance.

Process Control

What is Defined Process Control?

Defined process control is a process with clearly defined steps. When we operate in a relatively stable and predictable environment, a defined process should produce the same output every time, based on its repeatability and predictability, given the same input. A defined process has the following characteristics:

• Common and controlled
• Plan what you expect to happen
• Execute the plan, regardless of changing conditions
• Use change control because changes are costly

What is Empirical Process Control?

In empirical process control, you expect the unexpected. With defined process control, every task is fully understood in advance. In Scrum, an empirical process is implemented, where progress is based on observation and experimentation rather than detailed upfront planning and predefined processes. Empirical process control is based on facts, experience, and evidence—implemented through inspection and adaptation.

Empirical process control has the following characteristics:

• Learns from progress
• Expects and embraces change
• Uses short development cycles for inspection and adaptation
• Estimates are for reference only and may be inaccurate

Scrum Empirical Process Control

Empirical Process Control in Scrum

In Scrum, empirical process control is implemented through three core principles: transparency, inspection, and adaptation.

Transparency ensures that all aspects of the process that affect the outcome are visible to those responsible for managing the result. These aspects must not only be transparent but also understood by those observing them. In other words, when someone considers a task complete, it must align with their defined Definition of Done.

Aspects of the process must be inspected frequently to detect unacceptable variances. The frequency of inspection must consider that the act of inspection itself can alter the process. When the required inspection frequency exceeds the process tolerance, complications arise. Fortunately, software development appears to be less sensitive to this. Another factor is the skill and diligence of those inspecting the work.

If inspectors determine that one or more aspects of the process are outside acceptable limits and the resulting product would be unacceptable, they must adjust the process or the materials being processed. Adjustments must be made as soon as possible to minimize further deviations.

The Three Pillars in Scrum Events

Now let’s explore how Scrum embeds the three pillars as best practices into the framework through various events.

For example:

• The Daily Scrum is used to inspect progress toward the sprint goal and make adjustments for the next day’s work to maximize value.
• Additionally, Sprint Review and Sprint Planning are used to inspect progress toward the release goal and make adjustments to optimize value in the next Sprint.
• Finally, the Sprint Retrospective is used to reflect on the past Sprint and identify adaptations that will make the next Sprint more efficient, effective, and enjoyable.

This list summarizes the relationship between Scrum events and the three pillars as follows:

Transparency allows anyone to observe all aspects of any Scrum process. This promotes open and transparent information flow across the organization and fosters a culture of openness. In Scrum, transparency is demonstrated through:

• Artifacts
  • Project Vision Statement
  • Priority Product Backlog
  • Release Plan
• Meetings
  • Sprint Review Meeting
  • Daily Stand-up
• Information Radiators
  • Burndown Chart
  • Scrum Task Board

Inspection in Scrum is described through:

• Using common Scrum Task Boards and other information radiators
• Gathering feedback from customers and stakeholders during Epic development, creating a prioritized Product Backlog, and planning release behaviors
• Product Owner and customers inspecting and approving deliverables during Sprint demonstrations and validations

Adaptation is the core of Scrum, where the team and stakeholders learn from transparency and inspection, then adapt their work accordingly. The adaptability in Scrum is described as:

• Daily Stand-up Meetings
• Continuous Risk Identification
• Change Requests
• Scrum Guidance
• Retrospective Sprint Meetings