Scope Change Control

How It Works

Requirements change; unmanaged change creates rework and frustration. This recipe adds a

clear loop: define acceptance → implement → change request with impact → re-plan.

Triggers

• "Specs are vague and incomplete"
• Requirements change mid-sprint and invalidate work/tests
• PM/dev conflict over "unclear requirements"

Steps

1. Define acceptance criteria for each story (observable behavior, edge cases, constraints).
2. Require a "definition of done" checklist (tests, docs, rollout/flag plan).
3. When change occurs:

• log the change,
• estimate impact (time/risk),
• negotiate tradeoffs (scope/time).

1. Prevent silent churn: changes must be recorded where devs see them.
2. Retrospect: identify recurring ambiguity types and fix the template.

Expected Outcome

• Less wasted rework and fewer mid-implementation surprises.
• Better PM/dev alignment without requiring perfect upfront specs.

Example Inputs

• "Our PM specs are vague; devs keep chasing details."
• "Client changes requirements every week; we need a process."
• "Acceptance criteria are missing; QA can't validate."

Tips

• Change is normal; unmanaged change is the real problem.