Creating Effective Sprint Backlogs

A sprint backlog that's too ambitious leads to failure and demoralization. One that's too light wastes capacity. Creating effective sprint backlogs means selecting the right amount of the right work, properly prepared and understood by the team.

Sprint Backlog Problems

Backlog Readiness

Definition of Ready

DEFINITION OF READY (DoR)
═════════════════════════

A task is READY for sprint when:

CLARITY:
- [ ] Description is clear and complete
- [ ] Acceptance criteria defined
- [ ] "Why" is understood (context/value)
- [ ] Questions have been answered

SIZE:
- [ ] Estimated by the team
- [ ] Can complete within sprint
- [ ] Ideally 1-3 days of work
- [ ] Larger items are broken down

DEPENDENCIES:
- [ ] No blocking dependencies
- [ ] External dependencies identified
- [ ] Prerequisites complete or scheduled

RESOURCES:
- [ ] Design/mockups available (if needed)
- [ ] API specs available (if needed)
- [ ] Test data/environments ready
- [ ] Skills exist on team

Ready vs Not Ready

READY VS NOT READY
══════════════════

✓ READY:
"Implement password reset flow"
- API endpoint documented
- Email template approved  
- Acceptance criteria: 5 specific items
- Estimate: 5 points
- No blockers

✗ NOT READY:
"Build user authentication"
- Too vague - which auth method?
- No API specs
- No acceptance criteria
- No estimate
- Depends on unfinished work

Sprint Planning Process

Capacity Calculation

CAPACITY CALCULATION
════════════════════

STEP 1: Calculate Available Days
─────────────────────────────────────
Sprint length:        10 days (2 weeks)
Team members:         5 developers
Total person-days:    50 days

STEP 2: Subtract Unavailability
─────────────────────────────────────
PTO:                  -3 days (@sarah, @mike)
Holidays:             -0 days
Training:             -2 days (@lisa)
────────────────────────────
Available:            45 person-days

STEP 3: Account for Non-Coding
─────────────────────────────────────
Meetings (~15%):      -6.75 days
Support/bugs (~10%):  -4.5 days
────────────────────────────
Capacity:             33.75 days

STEP 4: Convert to Story Points
─────────────────────────────────────
If 1 point ≈ 0.5 day ideal work
Capacity ≈ 67 story points

STEP 5: Apply Historical Factor
─────────────────────────────────────
Average velocity:     52 points
Last 3 sprints:       48, 55, 53

→ Target this sprint: 50-55 points
  (conservative given PTO)

Sprint Planning Meeting

SPRINT PLANNING STRUCTURE
═════════════════════════

DURATION: 2-4 hours (for 2-week sprint)

PART 1: WHAT (60 min)
─────────────────────────────────────
Product owner presents:
├── Sprint goal
├── Top priorities from backlog
└── Business context

Team confirms:
├── Understanding of work
├── Questions answered
└── Work is "ready"

PART 2: HOW MUCH (45 min)
─────────────────────────────────────
Calculate capacity:
├── Team availability
├── Known commitments
└── Buffer for unknowns

Pull from backlog:
├── Highest priority first
├── Until capacity reached
└── Leave 10-15% buffer

PART 3: HOW (45+ min)
─────────────────────────────────────
For each item:
├── Break into subtasks
├── Identify dependencies
├── Assign initial owners
└── Note risks/concerns

OUTPUT:
├── Committed sprint backlog
├── Clear sprint goal
├── Initial task assignments
└── Documented risks

Backlog Structure in GitScrum

Sprint Backlog View

SPRINT BACKLOG VIEW
═══════════════════

┌─────────────────────────────────────────────────────────┐
│  Sprint 23: User Authentication                        │
│  Mar 18-29 | Goal: Complete auth flow for mobile      │
├─────────────────────────────────────────────────────────┤
│  Capacity: 52 pts | Committed: 48 pts | Buffer: 8%    │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  TODO (32 pts)        IN PROGRESS      DONE            │
│  ────────────         ───────────      ────            │
│                                                         │
│  ┌────────────────┐   ┌──────────┐                     │
│  │ Login API      │   │ Password │                     │
│  │ 8 pts @mike    │   │ reset    │                     │
│  │ Ready ✓        │   │ 5 pts    │                     │
│  └────────────────┘   │ @sarah   │                     │
│                       └──────────┘                     │
│  ┌────────────────┐                                    │
│  │ OAuth setup    │                                    │
│  │ 5 pts @lisa    │                                    │
│  │ Ready ✓        │                                    │
│  └────────────────┘                                    │
│                                                         │
│  ┌────────────────┐                                    │
│  │ Mobile login UI│                                    │
│  │ 8 pts @tom     │                                    │
│  │ Blocked: API   │                                    │
│  └────────────────┘                                    │
│                                                         │
│  ... more items ...                                    │
│                                                         │
└─────────────────────────────────────────────────────────┘

Task Breakdown

TASK BREAKDOWN EXAMPLE
══════════════════════

STORY: Login API Implementation (8 pts)

SUBTASKS:
├── Create login endpoint (2 pts)
│   └── @mike, Day 1-2
├── Implement JWT generation (2 pts)
│   └── @mike, Day 2-3
├── Add rate limiting (1 pt)
│   └── @mike, Day 3
├── Write unit tests (2 pts)
│   └── @mike, Day 4
└── Update API documentation (1 pt)
    └── @mike, Day 4-5

DEPENDENCIES:
├── Needs: User model (complete ✓)
├── Needs: JWT library (complete ✓)
└── Blocks: Mobile login UI

ACCEPTANCE CRITERIA:
├── POST /api/login accepts email/password
├── Returns JWT on success
├── Returns 401 on invalid credentials
├── Rate limited to 5 attempts/minute
├── Logged in audit trail
└── Tests cover all scenarios

Managing the Sprint Backlog

During the Sprint

SPRINT BACKLOG MANAGEMENT
═════════════════════════

DAILY CHECKS:
├── Any blocked items?
├── Items taking longer than expected?
├── Any scope creep happening?
├── Still on track for sprint goal?

MID-SPRINT ADJUSTMENTS:
├── Can we swarm on blockers?
├── Need to cut scope?
├── Can add work if ahead?
└── Communicate changes

SCOPE CHANGES:
If new urgent work appears:
1. Assess urgency vs. current work
2. If truly urgent, what gets removed?
3. Discuss with product owner
4. Document the change
5. Communicate to stakeholders

NEVER:
├── Silently add work
├── Let scope creep happen
├── Miss sprint goal without raising early
└── Blame team for external factors

Burndown Tracking

SPRINT BURNDOWN
═══════════════

Points remaining by day:

48 │●
   │  ●
40 │    ●  ● (delay)
   │         ●
32 │           ●
   │             ●
24 │               ●
   │                 ●
16 │                   ●
   │                     ●
 8 │                       ●
   │                         ●
 0 │──────────────────────────●
   D1  D2  D3  D4  D5  D6  D7  D8  D9  D10

Legend:
─── Ideal burndown
●   Actual progress

Status: On track after day 4 adjustment
Forecast: Complete with 2 pts buffer

Best Practices

For Sprint Backlogs

1. Use velocity data — Don't guess capacity
2. Leave buffer — 10-15% for unknowns
3. Prioritize ruthlessly — Top items done first
4. Ready means ready — Enforce Definition of Ready
5. Protect the commitment — Push back on additions

Anti-Patterns

SPRINT BACKLOG MISTAKES:
✗ Committing to more than velocity
✗ Starting sprint with unclear work
✗ Tasks too large to finish
✗ No consideration of dependencies
✗ Adding work mid-sprint without removing
✗ No sprint goal
✗ Different priorities than what's in backlog
✗ Not tracking progress

Related Solutions

• Breaking down epics into manageable tasks
• Improving estimation accuracy
• Running effective sprint retrospectives