Handle Scope Creep | Change Control Process

Scope creep derails sprints when changes aren't controlled. GitScrum documents original scope, tracks additions with labels, and protects sprint commitments effectively.

4 min read

How to handle scope creep in development projects?

Handle scope creep by documenting original scope in task descriptions, creating new tasks for additional requests (don't expand existing tasks), using labels to identify scope additions, requiring change discussion before commitment, and protecting sprint commitments. Track scope changes in NoteVault to identify patterns and address root causes.

Scope creep labels

Label	Purpose
scope:original	Original scope
scope:addition	Added after commitment
scope:negotiable	Can be traded
scope:required	Must have
change-request	New scope request
out-of-scope	Explicitly excluded

Task with clear scope

## Feature: User Export

### In Scope (Original)
- [ ] Export users to CSV
- [ ] Export users to JSON
- [ ] Date range filter
- [ ] Email notification on completion

### Out of Scope
- PDF export (separate task)
- Real-time progress bar (nice-to-have)
- Export scheduling (future enhancement)
- Export to third-party services

### Acceptance Criteria
1. User clicks Export button
2. Selects format and date range
3. Download starts within 5 seconds
4. Email sent when complete

### Change Log
- [Date]: Original scope documented
- [Date]: Added email notification (traded for PDF)

Scope change workflow:

Request received - New requirement surfaces

Document as new task - Don't modify original

Label appropriately - change-request label

Assess impact - Time, dependencies, risk

Discuss trade-offs - What gets dropped?

Decision - Add, defer, or decline

Update scope - Document in original task

Communicate - Stakeholders informed

Scope negotiation template

## Change Request: Add PDF Export

### Request
Add PDF export option to user export feature.

### Impact Assessment
- Additional effort: +3 points
- Dependencies: PDF library integration
- Risk: Formatting complexity

### Options
1. Add to current sprint (drop something else)
2. Add to next sprint
3. Create separate feature

### Trade-off Proposal
Add PDF export, drop email notification from current sprint.

### Decision
[Pending/Approved/Declined]
Decided by: @product-owner
Date: [Date]

Preventing scope creep

Prevention	How
Clear requirements	Detailed acceptance criteria
Bounded tasks	In scope / out of scope sections
Change process	Formal request workflow
Impact analysis	Estimate before committing
Trade, don't add	Something out for something in
Sprint protection	No mid-sprint additions

NoteVault scope tracking

# Scope Change Log - Q1 2025

## Sprint 1
| Request | Decision | Impact |
|---------|----------|--------|
| PDF export | Deferred | +3 pts |
| Dark mode | Declined | +8 pts |

## Sprint 2
| Request | Decision | Impact |
|---------|----------|--------|
| Bulk actions | Added (traded) | +5 pts |
| API v2 | Added (traded) | +8 pts |

## Patterns Observed
- 40% of additions from stakeholder A
- Most additions are "nice-to-have" not requirements
- Average addition: +4 points

## Process Improvements
- Stakeholder A included in planning
- Requirements review added to sprint start