DEV Community

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

Posted on

Why Large Tasks Fail: The 2-Hour Rule Secret

"4 weeks should be enough for backend development, right?"

Hearing this sends chills down my spine.

What exactly is "backend development"?

I discovered this while reviewing a startup's WBS:

Project Schedule (3 months)
├── Planning (2 weeks)
├── Design (2 weeks)
├── Backend Development (4 weeks) ← ???
├── Frontend Development (4 weeks) ← ???
└── Testing and Deployment (2 weeks)
Enter fullscreen mode Exit fullscreen mode

I asked each person what "backend development" means:

  • PM: "Just making a few APIs, right?"
  • Developer A: "Everything from DB design to API, authentication, payments"
  • Developer B: "We'll decide as we go"
  • CTO: "Cloud infrastructure setup is included, right?"

4 people had 4 different thoughts.

God Object WBS: The Anti-Pattern of Project Management

In software development, there's an anti-pattern called God Object. One class does too many things.

Project management has the exact same problem: God Task.

Characteristics of God Task 

❌ God Task Examples:
- "Backend Development" (160 hours)
- "Frontend Implementation" (120 hours)
- "System Integration" (80 hours)
- "Bug Fixes" (?? hours)
Enter fullscreen mode Exit fullscreen mode

Common characteristics of these tasks:

  1. Ambiguous about what exactly to do
  2. Impossible to measure progress
  3. Unclear completion criteria
  4. Different people understand differently

The 2-Hour Rule: The Magic Number

After analyzing numerous projects, I discovered one pattern.

Average task size of successful projects: 1-2 hours

Why 2 hours?

Psychological Reason 

# Human concentration limits
focus_duration = {
    "Deep focus": 90,  # minutes - ultradian rhythm
    "Normal focus": 45,  # minutes - 2 pomodoro sessions
    "Rest needed": 15  # minutes
}

# Ideal work unit
ideal_task = focus_duration["Deep focus"] + focus_duration["Rest needed"]
# = 105 minutes ≈ 2 hours
Enter fullscreen mode Exit fullscreen mode

Practical Reasons

  1. Morning/Afternoon Units: Good for dividing a day into 4 blocks
  2. Progress Perception: Completing 2-3 tasks daily → sense of achievement
  3. Reviewable: 2-hour tasks can be reviewed in 30 minutes
  4. Easy to Fix: If wrong, only 2 hours wasted

Real Case: Payment System Implementation

Before: God Task Approach 

Payment System Implementation (40 hours)
└── (What should I do...?)
Enter fullscreen mode Exit fullscreen mode

Result:

  • After 2 weeks: "50% progress" (really?)
  • After 3 weeks: "Almost done" (how much?)
  • After 4 weeks: "Just a bit more..." (until when?)
  • After 6 weeks: Complete (2 weeks late)

After: Applying 2-Hour Rule 

Payment System Implementation (40 hours)
├── 1. Payment Process Design (4 hours)
│   ├── 1.1 Payment Flow Diagram (2 hours)
│   └── 1.2 Exception Scenarios Definition (2 hours)
├── 2. Stripe Integration (8 hours)
│   ├── 2.1 Stripe Account Setup (1 hour)
│   ├── 2.2 Customer Creation API (2 hours)
│   ├── 2.3 Payment Intent API (2 hours)
│   ├── 2.4 Webhook Processing (2 hours)
│   └── 2.5 Error Handling (1 hour)
├── 3. Database (6 hours)
│   ├── 3.1 Payment Table Design (2 hours)
│   ├── 3.2 Migration Writing (2 hours)
│   └── 3.3 Transaction Processing (2 hours)
├── 4. Business Logic (10 hours)
│   ├── 4.1 Payment Validation Logic (2 hours)
│   ├── 4.2 Retry Logic (2 hours)
│   ├── 4.3 Refund Processing (2 hours)
│   ├── 4.4 Subscription Management (2 hours)
│   └── 4.5 Notification Sending (2 hours)
├── 5. Frontend (8 hours)
│   ├── 5.1 Payment Form UI (2 hours)
│   ├── 5.2 Card Info Validation (2 hours)
│   ├── 5.3 3D Secure Processing (2 hours)
│   └── 5.4 Payment Status Display (2 hours)
└── 6. Testing (4 hours)
    ├── 6.1 Unit Tests (2 hours)
    └── 6.2 E2E Tests (2 hours)
Enter fullscreen mode Exit fullscreen mode

Result:

  • Daily: "Completed 2.1, 2.2 today" (clear)
  • After 1 week: "10 of 20 completed" (accurate 50%)
  • After 2 weeks: "18 completed, 2 remaining" (almost done)
  • After 2.5 weeks: Complete (ahead of schedule!)

Failure Probability by Task Size

Actual data analysis results:

Task Size vs Delay Probability:
1 hour: 5% delay
2 hours: 8% delay
4 hours: 25% delay
8 hours: 45% delay
16 hours: 70% delay
40+ hours: 95% delay
Enter fullscreen mode Exit fullscreen mode

Over 8 hours, more than half get delayed.

Techniques for Breaking Down Large Tasks

1. Start with Verbs 

❌ "User Management"
✅ "Implement User Creation API"
✅ "Implement User Query API"
✅ "Implement User Update API"
Enter fullscreen mode Exit fullscreen mode

2. Divide by CRUD 

"Product Management Feature" →
- Create: Product Registration (2 hours)
- Read: Product Query (1 hour)
- Update: Product Update (2 hours)
- Delete: Product Deletion (1 hour)
Enter fullscreen mode Exit fullscreen mode

3. Divide by Layer 

"Login Feature" →
- DB: Create User Table (1 hour)
- Model: Define User Model (1 hour)
- Service: Implement Auth Logic (2 hours)
- Controller: API Endpoint (1 hour)
- View: Login Form UI (2 hours)
Enter fullscreen mode Exit fullscreen mode

4. Divide by Scenario 

"Payment Processing" →
- Happy Path: Normal Payment (2 hours)
- Insufficient Funds Handling (1 hour)
- Card Decline Handling (1 hour)
- Network Error Handling (2 hours)
Enter fullscreen mode Exit fullscreen mode

2-Hour Rule Checklist

Check when creating tasks:

  • [ ] Can it be finished within 2 hours?
  • [ ] Does it have a specific deliverable?
  • [ ] Is the completion criteria clear?
  • [ ] Can one person do it?
  • [ ] Is it testable?

If any answer is "no", break it down further.

Practical Application: Daily Planning

Morning (4 hours) 

09:00-11:00: Task 1 (2 hours)
11:00-11:15: Break
11:15-13:00: Task 2 (1 hour 45 minutes)
Enter fullscreen mode Exit fullscreen mode

Afternoon (4 hours) 

14:00-16:00: Task 3 (2 hours)
16:00-16:15: Break
16:15-18:00: Task 4 (1 hour 45 minutes)
Enter fullscreen mode Exit fullscreen mode

4 tasks per day = clear progress

Team Application Cases

Case 1: Startup A Team

Before:

  • Average task size: 16 hours
  • Project delay rate: 80%
  • Team satisfaction: Low

After (Applying 2-Hour Rule):

  • Average task size: 2.5 hours
  • Project delay rate: 15%
  • Team satisfaction: High

Case 2: Enterprise B Team

Change Process:

  1. Week 1: "Isn't this too broken down?"
  2. Week 2: "It's clearer than I thought"
  3. Week 3: "I can see the progress!"
  4. Week 4: "Why didn't we do this earlier?"

Tools and Automation

WBS Auto-Split Script 

def split_large_task(task, max_hours=2):
    """Automatically split large tasks"""

    if task.estimated_hours <= max_hours:
        return [task]

    # Split by CRUD pattern
    subtasks = []
    operations = ['Create', 'Read', 'Update', 'Delete']

    for op in operations:
        subtask = Task(
            name=f"{op} {task.name}",
            hours=task.estimated_hours / len(operations)
        )
        if subtask.hours <= max_hours:
            subtasks.append(subtask)
        else:
            # Split smaller
            subtasks.extend(split_by_components(subtask))

    return subtasks
Enter fullscreen mode Exit fullscreen mode

Common Objections and Responses

"Management Overhead is Too High"

Answer: It feels that way at first, but the benefits of clear progress and predictability are much greater.

"Creative Work Can't Be Time-Estimated"

Answer: Creative work can also be divided into "Ideation 2 hours", "Prototype 2 hours", etc.

"Urgent Tasks Come Frequently"

Answer: Working in 2-hour units allows quick response to urgent tasks too.

Conclusion: Small Divisions Lead to Big Wins

"Divide and Conquer" isn't just for algorithms.

Dividing tasks into 2 hours:

  • Progress becomes clear
  • Schedule prediction becomes accurate
  • Team members become happy
  • Projects succeed

Try it in your next project.

Instead of "Backend development 4 weeks", use "20 APIs × 2 hours".

You'll experience amazing changes.

Need systematic WBS management with the 2-hour rule? Check out Plexo.

Top comments (0)