Sprint Backlog Creation | Right Work, Right Size
Build sprint backlogs with properly refined, estimated, and prioritized work. GitScrum helps teams commit to realistic goals using velocity data and capacity.
7 min read
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
| Problem | Impact | Solution |
|---|---|---|
| Over-commitment | Missed sprint, demoralization | Use velocity data |
| Unclear work | Mid-sprint confusion | Proper refinement |
| Too large items | Never finish | Break down tasks |
| Hidden dependencies | Blocked work | Dependency mapping |
| No priorities | Wrong work first | Clear ordering |
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
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