Realistic Project Deadlines | Velocity-Based Forecasting
Set achievable deadlines using bottom-up estimation and velocity data. GitScrum tracks dependencies, applies buffers, and forecasts with 80% confidence.
14 min read
Unrealistic deadlines set projects up for failure from day one. Teams burn out rushing to meet impossible targets, quality suffers, and trust erodes when dates slip. GitScrum provides the data-driven tools to create realistic timelines based on actual team capacity, historical performance, and honest risk assessment.
The Deadline Problem
Why deadlines fail and consequences:
| Root Cause | Result |
|---|---|
| Top-down date setting | Deadline exists before scope understood |
| Ignoring team capacity | More work than hours available |
| No historical data | Estimates based on hope, not reality |
| Hidden dependencies | Work blocked by others not accounted for |
| No buffers | Single delay cascades to final date |
| Scope assumed fixed | New requirements not factored |
Bottom-Up Estimation
Story Point Estimation
ESTIMATION PROCESS:
┌─────────────────────────────────────────────────────────────┐
│ STEP 1: BREAK DOWN EPICS INTO STORIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ Epic: User Authentication System │
│ ├── Story: Login form UI (3 pts) │
│ ├── Story: Password validation (2 pts) │
│ ├── Story: JWT token generation (5 pts) │
│ ├── Story: Session management (5 pts) │
│ ├── Story: Password reset flow (5 pts) │
│ ├── Story: OAuth integration (8 pts) │
│ ├── Story: MFA setup (8 pts) │
│ └── Story: Account lockout (3 pts) │
│ TOTAL: 39 points │
│ │
└─────────────────────────────────────────────────────────────┘
STEP 2: TEAM ESTIMATION SESSION:
┌─────────────────────────────────────────────────────────────┐
│ PLANNING POKER RESULTS │
├─────────────────────────────────────────────────────────────┤
│ │
│ Story: OAuth integration │
│ │
│ Developer votes: │
│ @Alex: 8 @Kim: 5 @Sam: 8 @Pat: 13 @Jordan: 8 │
│ │
│ Discussion: @Pat explains 13 due to LinkedIn API quirks │
│ Team agrees to add LinkedIn research task │
│ │
│ Revised estimate: 8 points + 2 point spike for LinkedIn │
│ │
│ Final: 10 points total │
│ │
└─────────────────────────────────────────────────────────────┘
Velocity-Based Forecasting
VELOCITY CALCULATION:
┌─────────────────────────────────────────────────────────────┐
│ TEAM VELOCITY (Last 6 Sprints) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Sprint │ Committed │ Completed │ Velocity │
│ ──────────┼───────────┼───────────┼────────── │
│ Sprint 19 │ 45 │ 38 │ 38 │
│ Sprint 20 │ 40 │ 42 │ 42 │
│ Sprint 21 │ 42 │ 40 │ 40 │
│ Sprint 22 │ 45 │ 44 │ 44 │
│ Sprint 23 │ 42 │ 41 │ 41 │
│ Sprint 24 │ 44 │ 43 │ 43 (in progress) │
│ ──────────┴───────────┴───────────┴────────── │
│ │
│ AVERAGE VELOCITY: 41 points/sprint │
│ RANGE: 38-44 points/sprint │
│ STANDARD DEVIATION: 2.1 points │
│ │
│ RECOMMENDATION: │
│ ├── Optimistic planning: 44 pts/sprint │
│ ├── Realistic planning: 41 pts/sprint ← USE THIS │
│ └── Conservative planning: 38 pts/sprint │
│ │
└─────────────────────────────────────────────────────────────┘
PROJECT TIMELINE CALCULATION:
┌─────────────────────────────────────────────────────────────┐
│ PROJECT: Customer Portal v2 │
├─────────────────────────────────────────────────────────────┤
│ │
│ TOTAL ESTIMATED WORK: 245 story points │
│ TEAM VELOCITY: 41 points/sprint (2-week sprints) │
│ │
│ CALCULATION: │
│ 245 points ÷ 41 points/sprint = 5.97 sprints │
│ │
│ SCENARIOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Optimistic (44 pts): 245 ÷ 44 = 5.6 sprints = 11 weeks ││
│ │ Realistic (41 pts): 245 ÷ 41 = 6.0 sprints = 12 weeks ││
│ │ Conservative (38 pts): 245 ÷ 38 = 6.4 sprints = 13 wks ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RECOMMENDATION: 12-13 weeks (6-6.5 sprints) │
│ BUFFER ADDED: +2 weeks (15% contingency) │
│ PROPOSED DEADLINE: 14-15 weeks from start │
│ │
└─────────────────────────────────────────────────────────────┘
Buffer Management
Types of Buffers
BUFFER STRATEGY:
┌─────────────────────────────────────────────────────────────┐
│ BUFFER TYPES AND ALLOCATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. ESTIMATION UNCERTAINTY BUFFER (10-20%) │
│ For: Unknown complexity, new technology, learning curve │
│ Rule: Higher for novel work, lower for familiar work │
│ │
│ Example: 245 pts × 15% = ~37 additional points │
│ Time: +1.5 weeks │
│ │
│ 2. SCOPE CHANGE BUFFER (10-15%) │
│ For: Inevitable changes, clarifications, additions │
│ Rule: Higher for external clients, lower for internal │
│ │
│ Example: 245 pts × 10% = ~25 additional points │
│ Time: +1 week │
│ │
│ 3. RISK BUFFER (5-15%) │
│ For: Known risks that might materialize │
│ Rule: Based on risk register assessment │
│ │
│ Example: 2 high risks identified = 10% buffer │
│ Time: +1 week │
│ │
│ 4. INTEGRATION/DEPLOYMENT BUFFER (1-2 weeks) │
│ For: Final testing, deployment prep, documentation │
│ Rule: Fixed time, not percentage │
│ │
│ Time: +1.5 weeks │
│ │
│ TOTAL PROJECT TIMELINE: │
│ ├── Core work: 12 weeks │
│ ├── Estimation buffer: +1.5 weeks │
│ ├── Scope buffer: +1 week │
│ ├── Risk buffer: +1 week │
│ └── Integration: +1.5 weeks │
│ ════════════════════════════ │
│ TOTAL: 17 weeks │
│ │
└─────────────────────────────────────────────────────────────┘
Confidence Levels
DEADLINE CONFIDENCE FRAMEWORK:
┌─────────────────────────────────────────────────────────────┐
│ CONFIDENCE-BASED COMMUNICATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ Instead of: "It will be done April 15" │
│ Say: "We're 80% confident we'll deliver by April 15" │
│ │
│ CONFIDENCE LEVELS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 50% Confidence: April 1 (optimistic, no buffers) ││
│ │ 70% Confidence: April 8 (realistic, minimal buffer) ││
│ │ 80% Confidence: April 15 (recommended commitment) ││
│ │ 90% Confidence: April 22 (conservative, most buffers) ││
│ │ 95% Confidence: April 29 (very safe, max buffers) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ STAKEHOLDER COMMUNICATION: │
│ │
│ "Based on our team's velocity and the scope we've defined, │
│ we're 80% confident we can deliver by April 15. │
│ │
│ This assumes: │
│ - No major scope additions (minor changes factored in) │
│ - Team stability (no departures) │
│ - Dependencies delivered on time │
│ │
│ If you need higher certainty, April 22 gives us 90% │
│ confidence with additional buffer for unknowns." │
│ │
└─────────────────────────────────────────────────────────────┘
Dependency Management
Dependency Mapping
DEPENDENCY VISUALIZATION:
┌─────────────────────────────────────────────────────────────┐
│ PROJECT DEPENDENCY MAP │
├─────────────────────────────────────────────────────────────┤
│ │
│ Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 │
│ ────────────────────────────────────────────────────────── │
│ │
│ [Auth System]────────┐ │
│ │ │
│ [Database Design]────┼────►[API Development]────────────┐ │
│ │ │ │
│ [UI Components]──────┼────►[Dashboard UI] │ │
│ │ │ │ │
│ │ ▼ ▼ │
│ └────►[Integration]────────►[Testing] │
│ │
│ CRITICAL PATH: Database → API → Integration → Testing │
│ Duration: 5 weeks (minimum with perfect execution) │
│ │
│ PARALLEL WORK POSSIBLE: │
│ ├── Auth System (parallel with Database) │
│ ├── UI Components (parallel with Database/API) │
│ └── Dashboard UI (after API contracts defined) │
│ │
│ DEPENDENCIES ADDING RISK: │
│ ├── External: Payment API sandbox access (Week 2) │
│ ├── Internal: DevOps infrastructure ready (Week 1) │
│ └── Client: Content/copy approval (Week 4) │
│ │
└─────────────────────────────────────────────────────────────┘
External Dependency Tracking
EXTERNAL DEPENDENCIES IN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ DEPENDENCY TASK │
├─────────────────────────────────────────────────────────────┤
│ │
│ ⏳ DEPENDENCY: Payment API Sandbox Access │
│ Type: External | Status: Pending | Priority: Blocking │
├─────────────────────────────────────────────────────────────┤
│ │
│ OWNER: @Pat (internal) + Vendor contact: john@payco.com │
│ │
│ NEEDED BY: February 15 (Sprint 25 start) │
│ BUFFER BUILT IN: 1 week (Feb 22 is hard deadline) │
│ │
│ BLOCKS: │
│ ├── Payment integration development │
│ ├── Checkout flow testing │
│ └── End-to-end transaction tests │
│ │
│ CURRENT STATUS: │
│ ├── Request submitted: Jan 25 ✓ │
│ ├── Vendor acknowledged: Jan 28 ✓ │
│ ├── Onboarding call scheduled: Feb 5 │
│ └── Credentials expected: Feb 10 │
│ │
│ ESCALATION PATH: │
│ If not received by Feb 12: │
│ 1. Escalate to vendor account manager │
│ 2. Notify client of potential delay │
│ 3. Activate contingency: Use mock API for Sprint 25 │
│ │
│ HISTORY: │
│ Feb 1: Followed up via email, awaiting response │
│ Jan 28: Vendor confirmed timeline │
│ Jan 25: Initial request submitted via vendor portal │
│ │
└─────────────────────────────────────────────────────────────┘
Stakeholder Alignment
Deadline Communication Template
DEADLINE PROPOSAL DOCUMENT:
┌─────────────────────────────────────────────────────────────┐
│ PROJECT: Customer Portal v2 │
│ DEADLINE PROPOSAL │
├─────────────────────────────────────────────────────────────┤
│ │
│ EXECUTIVE SUMMARY │
│ We propose a launch date of April 22, 2024, with 80% │
│ confidence. This allows for realistic development pace, │
│ proper testing, and reasonable contingency for unknowns. │
│ │
│ SCOPE SUMMARY │
│ ├── 12 epics, 67 user stories │
│ ├── 245 estimated story points │
│ ├── Key features: Auth, Dashboard, Reporting, Payments │
│ └── Not included: Mobile app, Advanced analytics │
│ │
│ TIMELINE BREAKDOWN │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Phase │ Duration │ Deliverables ││
│ ├─────────────┼──────────┼────────────────────────────────┤│
│ │ Sprint 25 │ 2 weeks │ Auth system, DB schema ││
│ │ Sprint 26 │ 2 weeks │ Core APIs, UI foundation ││
│ │ Sprint 27 │ 2 weeks │ Dashboard, Reporting ││
│ │ Sprint 28 │ 2 weeks │ Payments, Integration ││
│ │ Sprint 29 │ 2 weeks │ Polish, Bug fixes ││
│ │ Sprint 30 │ 2 weeks │ UAT, Deployment prep ││
│ │ Buffer │ 2 weeks │ Contingency ││
│ └─────────────┴──────────┴────────────────────────────────┘│
│ │
│ KEY ASSUMPTIONS │
│ 1. Team of 5 developers remains stable │
│ 2. Scope changes limited to 10% or less │
│ 3. External dependencies delivered on time │
│ 4. Client feedback turnaround within 3 business days │
│ │
│ RISKS AND MITIGATION │
│ ├── Risk: Payment API delayed → Mock API fallback │
│ ├── Risk: Scope creep → Change request process active │
│ └── Risk: Key dev unavailable → Cross-training completed │
│ │
│ ALTERNATIVE SCENARIOS │
│ ├── Faster (Apr 8): Remove reporting module │
│ ├── Slower (May 6): Add mobile-responsive PWA │
│ └── Same timeline: Keep scope as proposed │
│ │
│ APPROVAL │
│ ☐ Approved as proposed │
│ ☐ Approved with modifications: _______________ │
│ ☐ Need more information: _______________ │
│ │
└─────────────────────────────────────────────────────────────┘
Deadline Negotiation
NEGOTIATION SCENARIOS:
┌─────────────────────────────────────────────────────────────┐
│ SCENARIO: STAKEHOLDER WANTS EARLIER DEADLINE │
├─────────────────────────────────────────────────────────────┤
│ │
│ Stakeholder: "We need this by March 15, not April 22." │
│ │
│ RESPONSE FRAMEWORK: │
│ │
│ 1. ACKNOWLEDGE THE NEED │
│ "I understand March 15 is important for the sales │
│ conference. Let's see what's possible." │
│ │
│ 2. PRESENT TRADE-OFFS │
│ "To hit March 15, we'd need to adjust scope. │
│ Here are three options:" │
│ │
│ Option A: Reduce scope │
│ ├── Remove: Reporting module, OAuth │
│ ├── Keep: Core auth, Dashboard, Payments │
│ ├── Effort: -60 points │
│ └── Timeline: 10 weeks → March 15 achievable │
│ │
│ Option B: Increase team │
│ ├── Add: 2 contractors for 8 weeks │
│ ├── Cost: +$40,000 │
│ ├── Risk: Onboarding overhead, coordination │
│ └── Timeline: Maybe March 22 (1-week improvement) │
│ │
│ Option C: Phased release │
│ ├── March 15: MVP (Auth, Dashboard basic) │
│ ├── April 22: Full release (Reporting, Payments) │
│ └── Conference: Demo MVP, promise full in April │
│ │
│ 3. LET STAKEHOLDER DECIDE │
│ "Which option best fits your business needs?" │
│ │
│ NEVER: │
│ ✗ "Sure, we'll make it work" (without adjustments) │
│ ✗ "That's impossible" (without alternatives) │
│ ✗ Commit to unrealistic deadline then miss it │
│ │
└─────────────────────────────────────────────────────────────┘
Progress Tracking
Burndown and Forecasting
SPRINT BURNDOWN WITH FORECAST:
┌─────────────────────────────────────────────────────────────┐
│ SPRINT 25 BURNDOWN │
│ Day 5 of 10 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Points │ │
│ 45 ┤ ● │
│ 40 ┤ ╲ ● │
│ 35 ┤ ╲ ● │
│ 30 ┤ ╲ ● │
│ 25 ┤ ╲ ● ← Current (27 pts remaining) │
│ 20 ┤ ╲ │
│ 15 ┤ ╲ Ideal line │
│ 10 ┤ ╲ │
│ 5 ┤ ╲ │
│ 0 ┼──────────────────────────● │
│ │ 1 2 3 4 5 6 7 8 9 10 Days │
│ │
│ STATUS: │
│ ├── Committed: 42 points │
│ ├── Completed: 15 points │
│ ├── Remaining: 27 points │
│ ├── Rate needed: 5.4 pts/day │
│ ├── Current rate: 3.0 pts/day │
│ └── Forecast: 15 points short if rate continues │
│ │
│ ACTIONS: │
│ ⚠️ Team meeting to identify blockers │
│ ⚠️ Consider scope adjustment mid-sprint │
│ │
└─────────────────────────────────────────────────────────────┘
PROJECT BURNUP (All Sprints):
┌─────────────────────────────────────────────────────────────┐
│ PROJECT BURNUP - Customer Portal v2 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Points │ SCOPE LINE│
│ 280 ┤ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ═══════════ │
│ 260 ┤ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ═════════ │
│ 245 ┤ ════════════════════════ (scope) │
│ 220 ┤ ◆ │
│ 200 ┤ ◆ │
│ 180 ┤ ◆ │
│ 160 ┤ ◆ DONE LINE │
│ 140 ┤ ◆ │
│ 120 ┤ ◆ │
│ 100 ┤ ◆ │
│ 80 ┤ ◆ │
│ │ S25 S26 S27 S28 S29 S30 S31 Sprints │
│ │
│ LEGEND: │
│ ════ = Total scope (grew from 245 to 265 pts) │
│ ◆◆◆◆ = Work completed │
│ │
│ FORECAST: │
│ ├── Current trajectory: Completes Sprint 31 │
│ ├── Original target: Sprint 30 │
│ ├── Variance: +1 sprint (2 weeks delay) │
│ └── Cause: 20-point scope addition in Sprint 27 │
│ │
│ OPTIONS: │
│ A) Accept delay (complete Sprint 31) │
│ B) Add resources (close gap) │
│ C) Reduce scope (cut 20 points) │
│ │
└─────────────────────────────────────────────────────────────┘
Best Practices
Estimation Accuracy Tips
IMPROVING ESTIMATION OVER TIME:
1. TRACK ACTUAL VS ESTIMATED
├── After each sprint, compare estimates to actuals
├── Identify patterns (which work is under/over-estimated)
├── Adjust future estimates based on learnings
└── Build team-specific calibration factors
2. USE REFERENCE STORIES
├── Keep examples of 1, 3, 5, 8, 13 point stories
├── Compare new work to completed work
├── "This is similar to the login feature (5 pts)"
└── Reduces estimate variance
3. INCLUDE WHOLE TEAM
├── Developers, QA, design all estimate together
├── Catches hidden work (testing, documentation)
├── Shared understanding of complexity
└── More accurate total effort
4. ACCOUNT FOR OVERHEAD
├── Meetings, code reviews, admin: ~20% of time
├── Sprint velocity reflects true capacity
├── Don't plan 40 hours of coding per week
└── Leave slack for interruptions
Deadline Anti-Patterns
WHAT NOT TO DO:
✗ WISHFUL THINKING DEADLINES
"We'll work harder" / "We'll figure it out"
Reality: Teams can't sustain crunch
✗ DEADLINE FIRST, SCOPE SECOND
"Launch is June 1, make it happen"
Reality: Either scope or quality will suffer
✗ IGNORING VELOCITY DATA
"This team should do 60 points, not 41"
Reality: Historical data is the best predictor
✗ NO BUFFERS
"Every day is accounted for perfectly"
Reality: Something always goes wrong
✗ HIDDEN DEADLINES
"Tell them April but we really need March"
Reality: Trust destruction when discovered
✗ DEATH MARCH ACCEPTANCE
"The deadline is aggressive but we committed"
Reality: Burnout, turnover, poor quality