The Science of WBS: Why Humans Can’t Estimate Large Tasks
PM: “How long will it take to develop this feature?”
Developer: “Um… maybe 2 weeks?”
(4 weeks later, still developing)
Why do we get it wrong every time?
This problem is the same everywhere. Even excellent developers and experienced PMs fail at estimation.
This isn’t a personal problem. It’s a structural limitation of the human brain.
The Human Brain’s Estimation Bug
Planning Fallacy
Do you know the research by psychologist Daniel Kahneman, who won the Nobel Prize in Economics?
He proved that humans underestimate task duration by an average of 2.5 times.
# Industry data (analysis of 1000 tasks)
estimation_accuracy = {
"1-hour task": {
"estimated": 1,
"actual": 1.2,
"error": "20%" # Acceptable range
},
"8-hour task": {
"estimated": 8,
"actual": 12,
"error": "50%" # A bit concerning
},
"40-hour task": {
"estimated": 40,
"actual": 100,
"error": "150%" # 😱 Serious
},
"200-hour project": {
"estimated": 200,
"actual": 500,
"error": "250%" # 🔥 Disaster
}
}# Pattern: Error increases exponentially as task size increasesWhy Are Large Tasks Hard to Predict?
Do you remember psychologist George Miller’s famous paper “The Magical Number Seven, Plus or Minus Two”?
Human short-term memory can only process 7±2 items simultaneously. Beyond this limit, the brain can’t process information properly.
// Human cognitive limits
const cognitive_limits = {
working_memory: '7±2 items', // Miller's Law// 8-hour task = manageable
small_task: {
components: 5,
interactions: 10,
complexity: 'linear',
}, // 200-hour task = cognitive overload
large_task: {
components: 50,
interactions: 1225, // 50 * 49 / 2
complexity: 'exponential',
hidden_work: '40% of total', // Invisible work
},
};
The Nature of Hidden Work
What Developers Forget
What’s the biggest cause of project delays?
According to PMI (Project Management Institute) research:
“Because we didn’t plan for invisible work” (78%)
“I said feature implementation would take 20 hours, but why did it actually take 50 hours?”
Most answers are similar. “I only thought about coding time. I forgot about testing, debugging, and documentation.”
# Developer's mind (wrong estimate)
developer_estimate = {
"coding": 20, # hours
"done": "Complete!" # ← Delusion!
}# Actually needed work (industry research data)
real_work = {
"coding": 20,
"debugging": 8, # Always happens
"edge cases": 5, # More than you think
"refactoring": 4, # Initial code always needs improvement
"code review": 3, # Depends on team culture
"review fixes": 3, # Pass on first try? Impossible
"test writing": 5, # If not TDD, done later
"documentation": 2, # README, API docs
"deployment prep": 2, # Environment setup, build
"monitoring setup": 1, # Logging, alerts
"rollback plan": 1 # Worst case preparation
}
# Actual: 54 hours (2.7x!)Industry research shows that “invisible work” accounts for 70% of the total.
The Iceberg Model
Above water (visible work) 30%
├── Core feature implementation
├── Basic testing
└── DeploymentBelow water (hidden work) 70%
├── Exception handling
├── Edge cases
├── Performance optimization
├── Security handling
├── Error handling
├── Logging
├── Monitoring
├── Documentation
├── Compatibility testing
├── Load testing
├── Recovery scenarios
└── Operations preparationParkinson’s Law and Student Syndrome
Parkinson’s Law
This is a principle discovered by British historian Cyril Parkinson.
“Work expands to fill the time available”
I experimented with this during consulting. What happens when you give different deadlines for the same task?
// Experiment results (actual A/B test performed)
const experiment = {
group_A: {
deadline: '3 days',
actual_work: '8 hours', // Actual work time
total_time: '3 days', // But filled all 3 days
quality: 7, // Quality score
notes: 'Relaxed at first, then rushed at the end',
},group_B: {
deadline: '1 day',
actual_work: '8 hours', // Same task
total_time: '1 day', // Focused and completed
quality: 8, // Quality actually improved!
notes: 'Maximized focus, removed unnecessary work',
},
};// My conclusion: Smaller units are more efficient and higher quality
This is one of the most important insights I gained from project management. Long deadlines are actually poison.
Student Syndrome
Think back to your student days. If an assignment is due in a month, when do you actually start?
Get 전규현 (Raymond)’s stories in your inbox
Join Medium for free to get updates from this writer.
This isn’t just a student problem. Developers, PMs, even executives are the same. It’s human nature.
def work_intensity(days_until_deadline):
"""Work intensity curve (psychology research data)"""
if days_until_deadline > 7:
return "5%" # "Still plenty of time" → Just drinking coffee
elif days_until_deadline > 3:
return "20%" # "Should start soon" → Just reading docs
elif days_until_deadline > 1:
return "50%" # "Really need to do this now" → Finally start coding
else:
return "200%" # "Overtime + weekend work" → Hell# WBS solution: Break into multiple small deadlines
# Monday: Complete Task 1 (8h)
# Tuesday: Complete Task 2 (8h)
# Wednesday: Complete Task 3 (8h)
# = Maintain consistent work intensity daily, zero overtimeIndustry research shows that teams applying this method reduced overtime from 3 times/week to once/month.
The Mathematics of Uncertainty
Estimation Through Probability Distribution
import numpy as npdef task_completion_probability(estimated_hours):
"""Task completion probability distribution""" if estimated_hours <= 8:
# Small task: Normal distribution (predictable)
mean = estimated_hours
std = estimated_hours * 0.2 else:
# Large task: Log-normal distribution (Long tail)
mean = estimated_hours * 2.5 # Average 2.5x
std = estimated_hours * 1.5 return {
"50%_probability": mean,
"90%_probability": mean + 2*std,
"worst_case": mean + 3*std
}# Example
small_task = task_completion_probability(8)
# {'50%_probability': 8, '90%_probability': 11.2, 'worst_case': 12.8}large_task = task_completion_probability(80)
# {'50%_probability': 200, '90%_probability': 440, 'worst_case': 560}
# Can increase up to 7x!
Anchoring Effect and Confirmation Bias
Anchoring
The phenomenon of over-relying on the first estimate
// Experiment: When PM suggests estimate first
const anchoring_effect = {
// PM: "This should take about a week, right?"
scenario_1: {
pm_suggestion: '1 week',
developer_estimate: '1.5 weeks', // Drawn to PM's opinion
actual_time: '3 weeks', // Failure!
}, // PM: Just asks for estimate
scenario_2: {
pm_suggestion: null,
developer_estimate: '2.5 weeks', // More accurate
actual_time: '3 weeks', // Close!
},
};Confirmation Bias
The tendency to justify one’s own estimate
# Developer's mind
initial_estimate = "2 weeks"# Uncomfortable truths (ignored)
ignored_facts = [
"Similar task last time took 4 weeks",
"Need to learn new tech stack",
"One team member on vacation",
"Integration test complexity is high"
]# Selective attention
selective_attention = [
"Some code can be reused",
"Can speed up with AI tools"
]# Result: Still insists on "2 weeks" → Failure
How WBS Breaks Psychological Traps
Chunking Strategy
def break_cognitive_load(big_task):
"""Reduce cognitive load to manageable level"""# Before: 200-hour monster task
# Human brain: "Um... well... maybe a month?" # After: 25 tasks x 8 hours
chunks = []
for i in range(25):
chunk = {
"id": f"Task {i+1}",
"hours": 8,
"complexity": "manageable",
"accuracy": "±20%"
}
chunks.append(chunk) # Each accurately estimated → Whole is accurate too
return chunks
Forcing External Perspective
// Internal perspective (biased)
const internal_view = 'We're special. We can do it fast.';// External perspective (WBS forces)
const external_view = {
historical_data: 'Average of 10 similar projects: 3 months',
industry_benchmark: 'Industry standard: 2.5 months',
wbs_calculation: '325 hours of work = 2.7 months', final_estimate: '3 months', // Realistic!
};
Practical Psychological Tricks
5 Ways to Improve Estimation Accuracy
techniques = {
"1. Three-point estimation": {
"optimistic": 10, # Best case
"realistic": 15, # Realistic
"pessimistic": 25, # Worst case
"final": (10 + 4*15 + 25) / 6 # 15.8 hours
},"2. Reference class forecasting":
"Use average of 10 similar past tasks", "3. Pre-mortem":
"Assume failure and analyze causes", "4. Delphi technique":
"Team members estimate independently, then agree", "5. Timeboxing":
"Set time first, then adjust scope"
}
Conclusion: Humble Estimation
This was the part I struggled with most while writing my book 『Everything About Software Development』.
“How can developers make accurate estimates?”
The answer is clear.
The human brain isn’t optimized for project estimation. We are structurally bad at estimating. This isn’t shameful. It’s just a fact we need to accept.
The Solution is Simple
- Don’t estimate large
- Break it down small
- Estimate one by one
WBS is a tool that acknowledges our cognitive limitations and overcomes them.
Research shows that teams that properly apply WBS achieve 85% project success rate. In contrast, teams that estimate “roughly by feel” have only 15% success rate.
The difference is just one thing. Whether you follow the principle of “the accurate sum of small pieces” or not.
Start Today
Theory is enough. Only practice remains.
- Choose one large task you’re working on now
- Break it down into small tasks of 8 hours or less
- Estimate each task independently
- Sum them up
You’ll probably be surprised. It’ll be 2–3 times your initial estimate. But that’s the truth.
Research shows that schedules estimated this way are 90% accurate. In contrast, schedules estimated in large chunks are less than 10% accurate.
Need psychology-based scientific project management? Check out Plexo, a WBS tool that considers human cognitive limitations.
#EstimationPsychology #WBS #ProjectManagement #CognitiveScience #SoftwareEngineering
