Backlog Management

A well-maintained backlog ensures the team always works on the highest-value features. YeboLearn's backlog balances new features, bug fixes, technical debt, and platform improvements.

Backlog Structure

Backlog Hierarchy

Product Backlog
├── Epics (Large initiatives, 3-6 months)
│   ├── AI Education Platform
│   ├── Payment & Monetization
│   └── Mobile Experience
├── Features (2-4 weeks of work)
│   ├── AI Essay Grading
│   ├── M-Pesa Integration
│   └── Offline Mode
├── Stories (Fits in one sprint)
│   ├── Essay submission interface
│   ├── AI feedback generation
│   └── Teacher review dashboard
└── Tasks (Hours to 2 days)
    ├── Create submission API endpoint
    ├── Integrate Gemini API
    └── Write unit tests

Backlog States

Icebox → Backlog → Ready → In Progress → Review → Done

Icebox: Ideas, future considerations (not prioritized)
Backlog: Prioritized, needs refinement
Ready: Defined, estimated, ready for sprint
In Progress: Currently being developed
Review: Code review or QA
Done: Deployed to production

Story Writing

User Story Format

Template:

As a [user type],
I want to [action],
So that [benefit/value].

Acceptance Criteria:
- [ ] Criteria 1
- [ ] Criteria 2
- [ ] Criteria 3

Technical Notes:
- Implementation considerations
- Dependencies
- Risks

Good Story Examples

Example 1: Student Feature

Title: AI-Generated Quiz from Course Content

As a student,
I want to generate practice quizzes from my course material,
So that I can test my understanding and prepare for exams efficiently.

Acceptance Criteria:
- [ ] Student can select course topic and difficulty level
- [ ] AI generates 10 relevant multiple-choice questions
- [ ] Questions cover key concepts from the material
- [ ] Student receives immediate feedback on answers
- [ ] Quiz results are saved to student progress
- [ ] Generation completes within 10 seconds

Technical Notes:
- Use Gemini API for question generation
- Rate limit: 5 quizzes per student per hour
- Store generated quizzes for future reuse
- Cache common topics to reduce API calls
- Handle API failures gracefully

Design: [Link to Figma]
API Spec: [Link to documentation]

Estimate: 8 story points
Priority: High
Sprint: 26

Example 2: Platform Improvement

Title: Reduce API Response Time for Student Dashboard

As a student,
I want the dashboard to load quickly,
So that I can access my courses without frustration.

Acceptance Criteria:
- [ ] Dashboard loads in <1 second (down from 3s)
- [ ] Initial content visible in <500ms
- [ ] All data loaded in <1.5s
- [ ] Performance improvement measured and verified
- [ ] No regression in functionality

Technical Notes:
- Implement database query caching (Redis)
- Add indexes on frequently queried columns
- Lazy load non-critical data
- Optimize GraphQL queries
- Measure with Lighthouse and real user metrics

Current Metrics:
- p50: 2.8s
- p95: 4.2s
- Database query time: 1.8s average

Target Metrics:
- p50: <1s
- p95: <1.5s
- Database query time: <200ms

Estimate: 5 story points
Priority: Medium
Sprint: 26

Example 3: Technical Debt

Title: Refactor Payment Processing to Use Idempotency Keys

As a developer,
I want payment operations to be idempotent,
So that we prevent duplicate charges and improve reliability.

Acceptance Criteria:
- [ ] All payment endpoints accept idempotency keys
- [ ] Duplicate requests return same result (no double charge)
- [ ] Idempotency keys stored and checked
- [ ] Keys expire after 24 hours
- [ ] Existing payments migrated without downtime
- [ ] Comprehensive tests for edge cases

Technical Notes:
- Add idempotency_key column to payments table
- Implement middleware for key validation
- Use UUIDs generated client-side
- Handle concurrent requests with same key
- Update M-Pesa webhook processing

References:
- Stripe idempotency docs: [link]
- Current payment flow: [diagram]

Estimate: 8 story points
Priority: High (prevents user complaints)
Sprint: 27

Story Writing Best Practices

INVEST Criteria:

• Independent: Can be developed separately
• Negotiable: Details can be discussed
• Valuable: Provides clear user value
• Estimatable: Team can estimate effort
• Small: Fits in one sprint
• Testable: Clear acceptance criteria

Clear Acceptance Criteria:

Good:
✓ Student can submit essay up to 10,000 words
✓ AI feedback appears within 30 seconds
✓ Feedback includes score (0-100) and 3-5 suggestions

Bad:
✗ Essay grading should work well
✗ Fast AI response
✗ Helpful feedback

Include Context:

• Why this feature matters
• User research or data supporting it
• Expected impact on metrics
• Related features or dependencies

Priority Levels

Priority Framework

P0: Critical (Do Immediately)

Criteria:
• Production is broken
• Users can't access core features
• Data loss or corruption risk
• Security vulnerability
• Payment processing down

Examples:
- API returning 500 errors
- Login system not working
- Payment gateway integration broken
- SQL injection vulnerability
- Data breach risk

Timeline: Fix within hours
Interrupt current work: Yes

P1: High (Next Sprint)

Criteria:
• High business value
• Competitive differentiation
• Significant user impact
• Blocks other important work
• Technical debt causing issues

Examples:
- AI essay grading feature
- M-Pesa payment integration
- Performance degradation (>3s load time)
- Refactor preventing new features

Timeline: 2-4 weeks
Interrupt current work: Rarely

P2: Medium (Next 1-2 Months)

Criteria:
• Moderate business value
• Nice to have features
• Quality of life improvements
• Planned technical debt
• Platform enhancements

Examples:
- UI polish and animations
- Additional analytics
- Code refactoring (non-blocking)
- Documentation improvements

Timeline: 1-2 months
Interrupt current work: No

P3: Low (Future Consideration)

Criteria:
• Low impact on users or business
• Experimental features
• Speculative improvements
• Wishlist items

Examples:
- Custom themes
- Advanced social features
- Nice-to-have integrations
- Edge case improvements

Timeline: 3+ months or never
Interrupt current work: No

Prioritization in Practice

Weekly Backlog Review:

# Backlog Review - November 22, 2025

## P0/P1 for Next Sprint (Sprint 26)
1. AI Essay Grading Launch (P1, 21 pts)
   → High business value, competitive differentiator

2. M-Pesa Integration Beta (P1, 13 pts)
   → Unlock Lesotho market, revenue driver

3. API Performance Optimization (P1, 8 pts)
   → User complaints about slow dashboard

4. Payment Idempotency Refactor (P1, 8 pts)
   → Technical debt causing support tickets

Total: 50 points available, 50 points prioritized
(Team velocity: 36 pts, plus stretch capacity)

## P2 Queued (Next 1-2 Months)
- Offline mode for rural students (13 pts)
- WhatsApp notification integration (8 pts)
- Student progress certificates (5 pts)
- Multi-language support (21 pts)

## P3 Icebox
- Custom theme engine
- Advanced gamification
- Social learning features

Re-prioritization Triggers:

When to Re-prioritize:
✓ User feedback indicates different needs
✓ Business priorities shift
✓ Competitor launches similar feature
✓ Technical dependencies change
✓ Resource availability changes
✓ Performance/reliability issues arise

Technical Debt Tracking

Technical Debt Backlog

Debt Categories:

1. Code Quality Debt

Problem: Legacy authentication code lacks tests
Impact: Hard to refactor, fear of breaking changes
Cost: Slows down auth-related features
Effort: 13 story points
Priority: P1 (blocking new features)
Plan: Refactor in Sprint 27

2. Performance Debt

Problem: N+1 query in student dashboard
Impact: Dashboard loads in 3+ seconds
Cost: User frustration, increased churn risk
Effort: 5 story points
Priority: P1 (user complaints)
Plan: Sprint 26

3. Infrastructure Debt

Problem: No database backup restore testing
Impact: Unknown if backups actually work
Cost: Risk of data loss in disaster
Effort: 3 story points
Priority: P2 (not blocking, but important)
Plan: Sprint 28

4. Documentation Debt

Problem: API endpoints not documented
Impact: External integrations difficult
Cost: Support overhead, slower partners
Effort: 5 story points
Priority: P2 (before partner launch)
Plan: Sprint 27

Debt Paydown Strategy

20% Sprint Capacity for Debt:

Sprint Allocation:
60% - New features
20% - Technical debt
10% - Bug fixes
10% - Performance & polish

Example Sprint 26:
36 points total capacity
├─ 22 points: AI essay grading + M-Pesa
├─ 7 points: Payment idempotency refactor (debt)
├─ 4 points: Bug fixes
└─ 3 points: Performance optimization

Debt Prioritization:

Pay Down First:
1. Debt blocking new features
2. Debt causing production issues
3. Debt increasing support load
4. Debt slowing development velocity

Pay Down Later:
5. Code style inconsistencies
6. Outdated dependencies (if working)
7. Nice-to-have refactoring
8. Experimental architecture ideas

Measuring Debt Impact:

Technical Debt Score:

const debtImpact = {
  frequencyOfChange: 0-10,    // How often we touch this code
  complexityToFix: 0-10,      // Effort to resolve
  riskOfFailure: 0-10,        // Production impact if breaks
  velocityImpact: 0-10,       // Slows down new features
};

Score = (frequencyOfChange × riskOfFailure + velocityImpact) × complexityToFix

High Score (>500): Address immediately
Medium Score (200-500): Plan for next 2 sprints
Low Score (<200): Backlog for future

Backlog Refinement

Weekly Refinement Session (Thursday 3 PM, 1 hour)

Participants: Engineering team + product owner

Agenda:

1. Review Upcoming Stories (30 min)

Goal: Get stories "Ready" for next sprint planning

For Each Story:
- Product owner explains user value
- Team asks clarifying questions
- Discuss technical approach
- Identify dependencies and risks
- Break down if too large (>8 points)
- Rough estimation (will refine in planning)

2. Backlog Cleanup (15 min)

Activities:
- Archive completed stories
- Remove outdated items
- Merge duplicate stories
- Update priorities based on feedback
- Add new items from stakeholder requests

3. Next Sprint Preview (15 min)

Look Ahead:
- Theme for next sprint
- Must-have features
- Dependencies to resolve
- Design work needed
- Technical spikes required

Story Refinement Checklist

Before a Story is "Ready":

• [ ] User value is clear and compelling
• [ ] Acceptance criteria are specific and testable
• [ ] Design mockups complete (if UI work)
• [ ] API contracts defined (if backend work)
• [ ] Technical approach discussed and agreed
• [ ] Dependencies identified and tracked
• [ ] Risks assessed and mitigated
• [ ] Rough estimate provided (will refine in planning)
• [ ] Priority assigned
• [ ] Links to relevant docs/designs/specs

If Missing Items:

• Move back to Backlog state
• Assign owner to complete missing info
• Re-review in next refinement

Backlog Anti-Patterns

Overstuffed Backlog

Problem: 200+ stories in backlog, overwhelming to review
Solution:
- Aggressive pruning (delete P3 items older than 6 months)
- Move experiments to separate icebox
- Keep backlog <50 items
- Focus on next 2-3 sprints only

Under-Defined Stories

Problem: "Improve performance" with no specifics
Solution:
- Define specific metrics (target <2s load time)
- Clear acceptance criteria
- Scope to one area (dashboard vs all pages)
- If can't define, create spike story first

Stale Priorities

Problem: Priorities set 6 months ago, no longer relevant
Solution:
- Review priorities weekly
- Re-prioritize based on current data
- Archive no-longer-needed items
- Align with current business goals

No Technical Debt Stories

Problem: 100% feature work, accumulating debt
Solution:
- Allocate 20% capacity to debt
- Make debt visible in backlog
- Prioritize debt that blocks features
- Track debt paydown over time

Backlog Metrics

Health Indicators

Backlog Size:

Total Stories: 42
├─ Ready: 12 (good, 3 sprints worth)
├─ Backlog: 24 (needs refinement)
└─ Icebox: 6 (future ideas)

Target: 10-15 Ready stories (3-4 sprints)

Age of Stories:

Average Age in Backlog: 18 days
Oldest Story: 94 days (probably should delete)

Target: <60 days in backlog, archive if older

Refinement Rate:

Stories Refined This Week: 8
Stories Added This Week: 6
Net: +2 Ready stories

Target: Refine 6-8 stories/week

Story Completion Rate:

Sprint 25:
Completed: 7/8 stories (88%)
Carried Over: 1 story (not completed)

Historical Average: 85% completion

Target: >80% stories completed in sprint

Story Types

Feature Stories

Title: [User-facing functionality]
Value: Clear user or business benefit
Size: 2-8 story points
Frequency: 60% of backlog
Example: "Student can generate AI quiz from notes"

Bug Fix Stories

Title: Fix [specific issue]
Value: Restore expected functionality
Size: 1-5 story points
Frequency: 10% of backlog
Example: "Fix quiz timer not pausing on blur"

Technical Debt Stories

Title: Refactor [component/module]
Value: Improve code quality, enable future features
Size: 3-13 story points
Frequency: 20% of backlog
Example: "Refactor auth module to support SSO"

Spike Stories (Research)

Title: Spike: [Investigation question]
Value: Reduce uncertainty for future work
Size: Time-boxed (1-3 days)
Frequency: 5% of backlog
Example: "Spike: Evaluate offline storage solutions"

Spike Output:
- Technical findings document
- Recommendation with pros/cons
- Estimated effort for implementation
- Risks and considerations

Performance Stories

Title: Improve [metric] for [feature]
Value: Better user experience
Size: 3-8 story points
Frequency: 5% of backlog
Example: "Reduce dashboard load time to <1s"

Backlog Tools

Linear (Primary):

• Story creation and management
• Sprint planning and tracking
• Backlog views and filtering
• Roadmap visualization
• Integration with GitHub

GitHub Projects (Engineering Focus):

• Technical tasks and PRs
• Code review tracking
• Release planning
• Bug triage

Notion (Documentation):

• Product requirements docs (PRDs)
• Technical design docs
• Meeting notes and decisions
• Research and spikes

Related Documentation

• Planning Overview - Planning process
• Sprint Structure - Sprint ceremonies
• Estimation Guide - Story point estimation
• Development Workflow - Execution