Managing Scope Changes

Scope changes are inevitable. Good scope management handles changes transparently with clear trade-offs. Bad scope management means either rigid "no" or chaotic "yes to everything." This guide covers professional scope change handling.

Scope Change Types

Change Assessment

Evaluating Requests

SCOPE CHANGE ASSESSMENT
═══════════════════════

INITIAL QUESTIONS:
─────────────────────────────────────
├── What is being requested?
├── Why is it needed now?
├── Who is impacted if not done?
├── What's the business value?
├── What's the cost of delay?
└── Understand the request

URGENCY MATRIX:
─────────────────────────────────────
HIGH URGENCY:
├── Production is down
├── Major customer blocked
├── Security vulnerability
├── Revenue impact now
├── Legal/compliance deadline
└── Must address immediately

MEDIUM URGENCY:
├── Important but not critical
├── Stakeholder pressure
├── Nice to have soon
├── Can wait days
└── Discuss and decide

LOW URGENCY:
├── Enhancement
├── "While you're at it..."
├── Can wait for next sprint
├── No immediate impact
└── Backlog candidate

IMPACT ASSESSMENT:
─────────────────────────────────────
├── Size of change (hours/days)
├── What gets displaced?
├── Team capacity impact
├── Sprint goal affected?
├── Dependencies impacted?
└── True cost

Handling Changes

The Process

SCOPE CHANGE PROCESS
════════════════════

STEP 1: ACKNOWLEDGE
─────────────────────────────────────
"I understand you need X.
Let me assess the impact."

├── Don't react immediately
├── Show you're listening
├── Buy time to think
└── Professional response

STEP 2: ASSESS
─────────────────────────────────────
Determine:
├── Urgency level
├── Size estimate
├── Current sprint impact
├── What would be displaced
├── Team input if needed
└── Informed analysis

STEP 3: PRESENT OPTIONS
─────────────────────────────────────
Option A: Add now
├── Replaces: [stories]
├── Sprint goal impacted: [yes/no]
├── Delay to original work: [X days]
└── Cost visible

Option B: Add next sprint
├── First priority next sprint
├── Current work continues
├── Delivery date: [X]
└── Deferred option

Option C: Quick workaround
├── Partial solution now
├── Full solution later
├── Addresses immediate need
└── Compromise option

STEP 4: DECIDE TOGETHER
─────────────────────────────────────
├── PO makes call
├── Decision documented
├── Team informed
├── Stakeholder understands trade-off
└── Shared decision

STEP 5: EXECUTE
─────────────────────────────────────
├── Update sprint backlog
├── Communicate changes
├── Adjust expectations
├── Track in GitScrum
└── Clean execution

Preventing Scope Creep

Proactive Measures

PREVENTING SCOPE CREEP
══════════════════════

CLEAR ACCEPTANCE CRITERIA:
─────────────────────────────────────
Before sprint:
├── Detailed acceptance criteria
├── "Done when" explicit
├── Edge cases discussed
├── Agreed with stakeholder
├── No ambiguity
└── Baseline established

CHANGE REQUEST PROCESS:
─────────────────────────────────────
All changes go through:
├── Request documented
├── Impact assessed
├── Trade-offs presented
├── Decision recorded
├── Not casual requests
└── Visible process

PRODUCT OWNER GATEKEEPING:
─────────────────────────────────────
├── PO owns scope decisions
├── Team doesn't accept directly
├── Single point of prioritization
├── Buffer for team
└── Protected focus

SPRINT COMMITMENTS:
─────────────────────────────────────
Sprint is protected:
├── Goal agreed at planning
├── Changes are exceptions
├── Not a free-for-all
├── Team controls pace
└── Commitment respected

VISIBLE COST:
─────────────────────────────────────
Make trade-offs visible:
├── "We can add X, but Y moves out"
├── "This delays Z by 3 days"
├── Show the cost
├── Informed decisions
└── Not invisible impact

Communication

Stakeholder Conversations

STAKEHOLDER COMMUNICATION
═════════════════════════

NEVER JUST SAY NO:
─────────────────────────────────────
❌ "We can't do that"
❌ "It's not in scope"
❌ "That's scope creep"

✅ "Here's what it would take"
✅ "Here are our options"
✅ "What trade-off works for you?"

FRAMING:
─────────────────────────────────────
"We can absolutely add that feature.
If we add it now, we'd need to move
[story X] to next sprint.
Alternatively, we could do it
first thing next sprint with no
impact to current commitments.
Which option works better?"

DOCUMENTATION:
─────────────────────────────────────
Record decisions:
├── What was requested
├── What was decided
├── What was displaced
├── Who decided
├── When
└── Paper trail

SETTING EXPECTATIONS:
─────────────────────────────────────
├── Educate on process
├── Explain sprint concept
├── Build understanding
├── Repeat consistently
├── Stakeholders learn
└── Long-term investment

GitScrum Support

Tracking Changes

GITSCRUM FOR SCOPE CHANGES
══════════════════════════

CHANGE TRACKING:
─────────────────────────────────────
├── Label: scope-change
├── Note: original vs changed
├── Link related items
├── Document decision
└── Visible history

SPRINT ADJUSTMENTS:
─────────────────────────────────────
When scope changes:
├── Remove displaced item
├── Move to backlog or next sprint
├── Add new item
├── Update sprint notes
└── Clean record

RETROSPECTIVE:
─────────────────────────────────────
Discuss in retro:
├── How many scope changes?
├── Were they avoidable?
├── Process working?
├── Improve for next time
└── Continuous improvement

Best Practices

For Scope Changes

1. Assess before responding — Understand impact
2. Present options — Trade-offs visible
3. PO decides — Single priority owner
4. Document — Record decisions
5. Protect sprint — Changes are exceptions

Anti-Patterns

SCOPE CHANGE MISTAKES:
✗ Always saying no
✗ Always saying yes
✗ Hiding from stakeholders
✗ Taking changes directly
✗ No trade-off discussion
✗ Undocumented changes
✗ Uncontrolled creep
✗ Blame game

Related Solutions

• Managing stakeholder expectations
• Sprint planning strategies
• Prioritizing backlog items effectively