Project Time Estimation | Velocity & Effort Points

Estimate projects accurately with effort points, team velocity, and time tracking. GitScrum provides burndown charts and historical data for forecasting.

9 min read

Accurate time estimation separates successful projects from failed ones. By combining effort points for complexity, historical velocity for capacity, and time tracking for validation, development teams can move from guesswork to data-driven project planning that stakeholders can trust.

Estimation Components

The Estimation Process

PROJECT ESTIMATION WORKFLOW
═══════════════════════════

PHASE 1: REQUIREMENTS BREAKDOWN
─────────────────────────────────────
Epic → User Stories → Tasks

Project: "User Authentication System"
│
├── Epic: Authentication
│   ├── Story: Login flow
│   │   ├── Task: Login UI
│   │   ├── Task: API endpoint
│   │   └── Task: Session management
│   ├── Story: Registration
│   │   ├── Task: Registration form
│   │   ├── Task: Email verification
│   │   └── Task: User storage
│   └── Story: Password reset
│       ├── Task: Reset request UI
│       ├── Task: Email service
│       └── Task: Token handling
│
└── Total: 3 stories, 9 tasks

PHASE 2: EFFORT ESTIMATION
─────────────────────────────────────
Assign effort points to each task:

┌────────────────────────────────────────┐
│ Task                    │ Effort       │
├─────────────────────────┼──────────────┤
│ Login UI                │ M (3 pts)    │
│ Login API endpoint      │ M (3 pts)    │
│ Session management      │ L (5 pts)    │
│ Registration form       │ M (3 pts)    │
│ Email verification      │ L (5 pts)    │
│ User storage            │ S (2 pts)    │
│ Reset request UI        │ S (2 pts)    │
│ Email service           │ M (3 pts)    │
│ Token handling          │ M (3 pts)    │
├─────────────────────────┼──────────────┤
│ TOTAL                   │ 29 points    │
└─────────────────────────┴──────────────┘

PHASE 3: VELOCITY CALCULATION
─────────────────────────────────────
Team velocity: 35 pts/sprint (2 weeks)

Project points: 29 pts
Sprints needed: 29 ÷ 35 = 0.83 sprints

With buffer (20%): ~1 sprint
Estimated duration: 2 weeks

Velocity-Based Forecasting

USING VELOCITY FOR ESTIMATES
════════════════════════════

CALCULATING VELOCITY:
─────────────────────────────────────
Average points completed per sprint

Sprint History:
├── Sprint 1: 32 pts completed
├── Sprint 2: 36 pts completed
├── Sprint 3: 35 pts completed
├── Sprint 4: 38 pts completed
└── Sprint 5: 34 pts completed

Average velocity: 35 pts/sprint
Range: 32-38 pts (for confidence intervals)

PROJECT FORECAST:
─────────────────────────────────────
Total backlog: 180 points

Optimistic (38 pts/sprint):
180 ÷ 38 = 4.7 sprints = 5 sprints = 10 weeks

Expected (35 pts/sprint):
180 ÷ 35 = 5.1 sprints = 6 sprints = 12 weeks

Conservative (32 pts/sprint):
180 ÷ 32 = 5.6 sprints = 6 sprints = 12 weeks

PRESENT AS RANGE:
─────────────────────────────────────
"The project will take 10-12 weeks,
with 12 weeks being more likely."

This is more honest than a single date.

Time Tracking Integration

VALIDATING ESTIMATES WITH TIME DATA
═══════════════════════════════════

TRACKING ACTUAL TIME:
─────────────────────────────────────
For each task, track:
├── Estimated effort (points)
├── Estimated hours (optional guide)
├── Actual hours (time tracking)
└── Variance (estimated vs actual)

Example:
┌────────────────────────────────────────────────────┐
│ Task              │ Effort │ Est Hrs │ Act Hrs    │
├───────────────────┼────────┼─────────┼────────────┤
│ Login UI          │ M (3)  │ 4-8     │ 6          │
│ Login API         │ M (3)  │ 4-8     │ 5          │
│ Session mgmt      │ L (5)  │ 8-16    │ 14         │
│ Registration form │ M (3)  │ 4-8     │ 7          │
│ Email verify      │ L (5)  │ 8-16    │ 18 ⚠️      │
└───────────────────┴────────┴─────────┴────────────┘

⚠️ Email verification took longer than expected
   → Record why for future estimates

CALIBRATION:
─────────────────────────────────────
After several sprints, patterns emerge:
├── "L tasks average 12 hours"
├── "Integration tasks take +30%"
├── "New technology adds +50%"
└── "Complex UI needs +20%"

Use these insights to improve estimates.

Estimation Techniques

METHODS FOR ACCURATE ESTIMATES
══════════════════════════════

TECHNIQUE 1: REFERENCE COMPARISON
─────────────────────────────────────
Compare new work to completed work

Reference library:
├── XS: "Config change" (1-2 hrs)
├── S:  "Add validation" (2-4 hrs)
├── M:  "New API endpoint" (4-8 hrs)
├── L:  "Dashboard widget" (1-2 days)
└── XL: "Integration" (2-5 days)

New task: "Create user list API"
→ Similar to "New API endpoint" = M (3 pts)

TECHNIQUE 2: THREE-POINT ESTIMATION
─────────────────────────────────────
Best case + Most likely + Worst case

Task: "Implement OAuth login"

Optimistic (O):  8 hours (everything smooth)
Most likely (M): 16 hours (normal issues)
Pessimistic (P): 32 hours (major problems)

PERT estimate: (O + 4M + P) ÷ 6
= (8 + 64 + 32) ÷ 6 = 17.3 hours

TECHNIQUE 3: DECOMPOSITION
─────────────────────────────────────
Break large items into smaller pieces

"Build reporting dashboard" (too big)
    │
    ├── Design report layout (S)
    ├── Create data queries (M)
    ├── Build chart components (L)
    ├── Add export function (M)
    └── Implement filters (M)

Total: 2+3+5+3+3 = 16 points
Much more accurate than guessing "XL"

Buffer Management

PLANNING FOR UNCERTAINTY
════════════════════════

WHY BUFFERS ARE ESSENTIAL:
─────────────────────────────────────
├── Unknown requirements emerge
├── Technical challenges appear
├── Dependencies cause delays
├── Team capacity varies
├── Bugs need fixing
└── Scope changes happen

BUFFER CALCULATION:
─────────────────────────────────────
Base estimate: 100 points
Risk level: Medium

Buffer percentages:
├── Low risk (known tech, clear reqs): 10%
├── Medium risk (some unknowns): 20%
├── High risk (new tech, unclear reqs): 30-50%

For medium risk:
100 pts × 1.20 = 120 points to plan

APPLYING BUFFERS:
─────────────────────────────────────
Method 1: Add to total
├── Estimate: 100 pts
├── Buffer: 20 pts
└── Plan for: 120 pts

Method 2: Reduce velocity assumption
├── Velocity: 35 pts/sprint
├── Plan with: 28 pts/sprint (80%)
└── Same effect, cleaner tracking

Method 3: Add buffer sprint
├── 3 sprints of work
├── 1 buffer sprint
└── Promise 4 sprints

Communicating Estimates

PRESENTING TO STAKEHOLDERS
══════════════════════════

DO: USE RANGES
─────────────────────────────────────
"The project will take 8-10 weeks"
"We estimate 10 weeks with 80% confidence"
"Best case: 8 weeks, likely: 10 weeks"

DON'T: SINGLE DATES
─────────────────────────────────────
"It will be done May 15th"
→ Creates false precision
→ Ignores uncertainty
→ Sets up for failure

CONFIDENCE LEVELS:
─────────────────────────────────────
┌─────────────────────────────────────┐
│ Estimate   │ Confidence │ Use Case  │
├────────────┼────────────┼───────────┤
│ 8 weeks    │ 50%        │ Target    │
│ 10 weeks   │ 80%        │ Promise   │
│ 12 weeks   │ 95%        │ Deadline  │
└────────────┴────────────┴───────────┘

Promise at 80%, deadline at 95%.

UPDATING ESTIMATES:
─────────────────────────────────────
As project progresses:
├── Sprint 1 complete: Estimate unchanged
├── Sprint 2: Velocity lower → Update estimate
├── Sprint 3: Scope added → Update estimate
├── Sprint 4: On track → Confirm estimate

Communicate changes early.
"Based on new data, we need 2 more weeks."

GitScrum Implementation

SETTING UP ESTIMATION IN GITSCRUM
═════════════════════════════════

STEP 1: ENABLE TIME TRACKING
─────────────────────────────────────
Project Settings → Time Tracking → Enable
├── Timer for real-time tracking
├── Manual entries allowed
└── Reports accessible

STEP 2: CREATE TASK STRUCTURE
─────────────────────────────────────
Projects → Tasks
├── Create tasks with clear scope
├── Assign effort points (XS-XL)
├── Group into sprints
└── Set due dates

STEP 3: TRACK VELOCITY
─────────────────────────────────────
After each sprint:
├── Workspace → Reports → Sprint KPIs
├── Review points completed
├── Compare to commitment
└── Calculate average velocity

STEP 4: RUN FORECASTS
─────────────────────────────────────
Backlog points: 180
Team velocity: 35 pts/sprint

180 ÷ 35 = 5.1 sprints
Round up: 6 sprints = 12 weeks

With buffer: 6 × 1.2 = 7.2 → 8 sprints
Conservative estimate: 16 weeks

Common Estimation Mistakes

ANTI-PATTERNS TO AVOID
══════════════════════

MISTAKE 1: OPTIMISM BIAS
─────────────────────────────────────
❌ "If everything goes perfectly..."
❌ Best case as the estimate
❌ Ignoring past project delays

✓ Use historical velocity
✓ Include buffer for unknowns
✓ Plan for realistic scenarios

MISTAKE 2: HOUR-BASED ESTIMATES
─────────────────────────────────────
❌ "This will take 40 hours"
❌ Precise hours for uncertain work
❌ Treating all developers equally

✓ Use relative sizing (points)
✓ Let velocity normalize time
✓ Focus on complexity, not duration

MISTAKE 3: NO SCOPE MANAGEMENT
─────────────────────────────────────
❌ Accepting all changes
❌ Not tracking additions
❌ Same deadline despite growth

✓ Track scope changes
✓ Re-estimate when scope grows
✓ Communicate impact of changes

MISTAKE 4: IGNORING HISTORY
─────────────────────────────────────
❌ "This project is different"
❌ Not using past data
❌ Repeating estimation errors

✓ Track actual vs estimated
✓ Learn from past projects
✓ Calibrate estimates over time

Best Practices

Estimation Checklist

BEFORE COMMITTING TO A TIMELINE
═══════════════════════════════

REQUIREMENTS:
□ All features documented
□ Stories broken into tasks
□ Acceptance criteria defined
□ Dependencies identified

ESTIMATION:
□ Effort points assigned
□ Team reviewed estimates
□ Historical velocity used
□ Buffer included

COMMUNICATION:
□ Range provided (not single date)
□ Assumptions documented
□ Risks identified
□ Update schedule agreed

Related Solutions

• Sprint Planning and Execution
• Story Points vs Effort Points
• Agile Metrics and KPIs
• Time Tracking Best Practices