DEV Community

전규현 (Jeon gyuhyeon)
전규현 (Jeon gyuhyeon)

Posted on

Why Burndown Charts Lie: The War Against Scope Creep

Does a burndown chart like this mean things are really going well?

Remaining Work
100 |\
 80 | \
 60 |  \
 40 |   \
 20 |    \
  0 |_____\
    Day 1 2 3 4 5
Enter fullscreen mode Exit fullscreen mode

Looks perfect? But reality is...

Remaining Work
100 |\___
 80 |     \____
 60 |           ↗️ (Suddenly increasing?!)
 40 |         \___💥
 20 |              \____???
  0 |_____________________
    Day 1 2 3 4 5 6 7 8 9 10...
Enter fullscreen mode Exit fullscreen mode

It's not burning down. It's actually burning up.

Scope Creep: The Silent Killer of Projects

Scope Creep is the phenomenon where requirements gradually add up during project progress.

Like someone keeps adding weights while you're on a scale.

Actual Conversation Log

Day 1 (Kickoff Meeting)

PM: "Just need login, signup, and profile pages."
Dev Team: "2 weeks is enough!"
Enter fullscreen mode Exit fullscreen mode

Day 3

PM: "Oh, add social login too. It's simple, right?"
Dev Team: "Um... okay..."
(Inner thought: Google, Facebook, Kakao, Apple... simple?)
Enter fullscreen mode Exit fullscreen mode

Day 5

CEO: "Competitors have dark mode, let's add it."
Dev Team: "..."
(Inner thought: Have to rewrite all CSS...)
Enter fullscreen mode Exit fullscreen mode

Day 7

Marketing: "Email verification would be good too!"
Dev Team: "Sigh..."
(Inner thought: Mail server, templates, verification logic...)
Enter fullscreen mode Exit fullscreen mode

Day 10

PM: "Why isn't it done yet? You said 2 weeks?"
Dev Team: "???"
(Inner thought: Work doubled, though?)
Enter fullscreen mode Exit fullscreen mode

Analysis by Scope Creep Type

1. Innocent Creep

"This is simple too, so add it please~"

# PM's thinking
additional_work = {
    "dark_mode": "A few CSS lines",  # Reality: Modify 200 components
    "notification": "One DB field",  # Reality: Push, email, in-app, settings...
    "i18n": "Text replacement"  # Reality: Build i18n system
}
Enter fullscreen mode Exit fullscreen mode

2. Political Creep

"CEO wants it..."

const political_additions = {
  source: 'C-Level',
  negotiable: false,
  priority: 'URGENT',
  impact: '30% delay in entire schedule',
  developer_morale: -50,
};
Enter fullscreen mode Exit fullscreen mode

3. Perfectionist Creep

"Since we're doing it, let's do it right..."

Original: Basic search
├── "Might as well add autocomplete"
├── "Search history would be nice"
├── "Let's add filtering too"
├── "How about AI recommendations?"
└── Result: Elasticsearch + ML model = 3-month project
Enter fullscreen mode Exit fullscreen mode

4. Competitor Creep

"Competitors launched this feature!"

If competitor features are added daily, when will our product be complete?

The Truth of Burndown Charts

Ideal Burndown 

Workload
100 |*
 75 |  *
 50 |    *
 25 |      *
  0 |________*
    1  2  3  4  5 (Sprint)
Enter fullscreen mode Exit fullscreen mode

Actual Burndown (With Scope Creep) 

Workload
100 |*
 75 |  *___
 50 |      *___*  ← Additional requirements
 25 |           *___*  ← Added again
  0 |________________???
    1  2  3  4  5  6  7  8... (When will it end?)
Enter fullscreen mode Exit fullscreen mode

Honest Burndown (With Burn-up Chart) 

Workload
150 |          ___Total Work (Keeps Increasing)
100 |*    ____/
 50 |  *_/  Completed Work
  0 |________________
    1  2  3  4  5  6

Gap = The Reality of Scope Creep
Enter fullscreen mode Exit fullscreen mode

Scope Creep Defense Strategies

1. Mandatory Change Request Form 

## Change Request Form Template

### Request

- What:
- Why:

### Impact Analysis

- Additional Time: [ ] hours
- Affected Features:
- Risks:

### Priority

- [ ] Must Have (This Release)
- [ ] Important (Next Release)
- [ ] Nice to Have (Backlog)

### Approval

- PM: [ ]
- Dev Lead: [ ]
- Stakeholders: [ ]
Enter fullscreen mode Exit fullscreen mode

2. Trade-off Principle

"To add one, remove one"

def handle_new_request(new_feature, current_sprint):
    """Handle new feature request"""

    if new_feature.is_critical():
        # If important, exchange with another
        removed = current_sprint.remove_lowest_priority()
        current_sprint.add(new_feature)
        return f"Added: {new_feature}, Removed: {removed}"
    else:
        # If not important, to backlog
        backlog.add(new_feature)
        return "Review in next sprint"
Enter fullscreen mode Exit fullscreen mode

3. Secure Scope Buffer 

const sprint_planning = {
  committed_work: 70, // Only commit 70%
  buffer: 20, // 20% buffer
  innovation: 10, // 10% experimentation
};

// Scope creep absorbed by buffer
Enter fullscreen mode Exit fullscreen mode

4. Daily Delta Tracking 

# Track changes daily
daily_delta = {
    "Day1": {
        "added": [],
        "removed": [],
        "modified": ["Login UI"],
        "delta": 0
    },
    "Day2": {
        "added": ["Social Login"],  # +8 hours
        "removed": [],
        "modified": [],
        "delta": +8
    }
}

# Alert if delta is positive!
if sum(daily_delta.values()) > 0:
    alert("Scope creep detected!")
Enter fullscreen mode Exit fullscreen mode

Real Case: 2-Week Project Became 3 Months

Week 1-2: Smooth Start

  • Plan: Basic CRUD
  • Progress: 50% complete

Week 3: First Creep

  • Added: "Real-time notifications would be nice"
  • Impact: Need to build WebSocket server

Week 4: Second Creep

  • Added: "Make mobile app too"
  • Impact: Additional React Native development

Week 6: Third Creep

  • Added: "AI recommendation feature too..."
  • Impact: Build ML pipeline

Week 12: Project End(?)

  • Original plan: 2 weeks
  • Actual: 12 weeks
  • Cost: 6x
  • Team morale: Bottom

Scope Creep Checklist

Check if project has fallen into scope creep:

  • [ ] Burndown chart is flat or rising
  • [ ] Frequently hear "simple addition"
  • [ ] Don't know where original requirements doc went
  • [ ] New feature requests every week
  • [ ] Team members often ask "What was this again?"
  • [ ] Completion criteria keep changing

3 or more? Scope creep in progress!

Coexisting with Scope Creep

Can't completely prevent it. Business changes.

Healthy Change Management 

class ChangeManagement:
    def __init__(self):
        self.change_budget = 20  # Allow up to 20% change
        self.used_budget = 0

    def request_change(self, change):
        if self.used_budget + change.size <= self.change_budget:
            self.approve(change)
            self.used_budget += change.size
        else:
            self.defer_to_next_sprint(change)
Enter fullscreen mode Exit fullscreen mode

Transparent Communication 

## Weekly Scope Report

### This Week's Changes

- Added: Dark Mode (8 hours)
- Removed: Profile Edit (6 hours)
- Net Increase: 2 hours

### Overall Impact

- Original Completion: 3/15
- New Completion: 3/17
- Delay: 2 days

### Risks

- If more changes, cannot complete within March
Enter fullscreen mode Exit fullscreen mode

Burndown Chart Improvements

1. Add Scope Line 

Workload
150 |      _____ Scope Line (Track Changes)
100 |*    /
 50 |  *_/  Burndown Line
  0 |________________
    1  2  3  4  5  6
Enter fullscreen mode Exit fullscreen mode

2. Show Confidence Interval 

Workload
100 |*
 75 |  *±10  ← Show Uncertainty
 50 |    *±15
 25 |      *±20
  0 |________?
Enter fullscreen mode Exit fullscreen mode

3. Parallel Burn-up Chart

Showing completed work vs total work simultaneously makes scope creep clearly visible.

Conclusion: Defending Scope is Also Courage

Saying "No" is difficult.

But accepting every request:

  • Project never ends
  • Team gets exhausted
  • Product gets complex
  • No one is satisfied

Qualities of a Good PM:

  1. Clear scope definition
  2. Impact analysis on changes
  3. Trade-off negotiation
  4. Transparent progress sharing

To prevent burndown charts from lying, we must be honest first.

"If we add this feature, it will be 2 weeks late. Still want to do it?"

This question saves the project.

Need scope management and accurate burndown tracking? Check out Plexo.

Top comments (0)