Backlog Management
Effective product backlog management, prioritization, and user story writing
The product backlog is the single source of truth for what needs to be built. Effective backlog management ensures the team always works on the most valuable items.
What is a Product Backlog?
A product backlog is an ordered list of everything that might be needed in the product:
- Features and functionality
- Bug fixes
- Technical work
- Knowledge acquisition
The backlog is the team's to-do list. Keep it accessible, prioritized, and refined.
Backlog Item Types
User Stories
Functionality from the user's perspective:
As a [type of user],
I want [some goal],
So that [some reason].Example:
As a registered user,
I want to reset my password via email,
So that I can regain access to my account if I forget my password.Technical Stories
Technical work that doesn't directly deliver user value:
- Infrastructure improvements
- Refactoring
- Performance optimization
- Security hardening
Bugs
Defects that need to be fixed:
- Include reproduction steps
- Note severity and impact
- Link to related functionality
Spikes
Time-boxed research or prototyping:
- Used to reduce uncertainty
- Fixed duration (e.g., 2 days)
- Output is knowledge, not code
Writing Effective User Stories
INVEST Criteria
| Criterion | Description |
|---|---|
| Independent | Can be developed separately |
| Negotiable | Details can be discussed |
| Valuable | Delivers value to stakeholders |
| Estimable | Can be sized by the team |
| Small | Fits within an iteration |
| Testable | Has clear acceptance criteria |
Acceptance Criteria
Every story needs clear acceptance criteria:
**Story**: User password reset
**Acceptance Criteria**:
- [ ] User can request password reset from login page
- [ ] System sends email within 5 minutes
- [ ] Reset link expires after 24 hours
- [ ] New password must meet security requirements
- [ ] User is notified when password is changedDefinition of Ready
A story is ready for development when:
- Acceptance criteria are defined
- Dependencies are identified
- Story is estimated
- Team understands the story
- No blocking questions remain
Prioritization Techniques
MoSCoW Method
| Category | Description |
|---|---|
| Must Have | Critical for this release |
| Should Have | Important but not critical |
| Could Have | Desirable if time permits |
| Won't Have | Explicitly excluded |
Value vs Effort Matrix
Weighted Shortest Job First (WSJF)
WSJF = (Business Value + Time Criticality + Risk Reduction) / Job SizeHigher WSJF items should be done first.
Minimal Slices
Break large features into minimal slices that:
- Deliver incremental value
- Can be completed in one iteration
- Are independently testable
- Enable early feedback
Slicing Techniques
Workflow Steps: Break by process steps
Full Feature: "User Registration"
Slice 1: Basic registration form
Slice 2: Email verification
Slice 3: Profile completion
Slice 4: Social loginCRUD Operations: Break by operation
Full Feature: "Manage Products"
Slice 1: View products (Read)
Slice 2: Add products (Create)
Slice 3: Edit products (Update)
Slice 4: Remove products (Delete)User Types: Break by persona
Full Feature: "Dashboard"
Slice 1: Basic user dashboard
Slice 2: Admin dashboard
Slice 3: Manager dashboardBacklog Refinement
What is Refinement?
Regular sessions (1-2 hours/week) where the team:
- Reviews upcoming stories
- Adds detail and acceptance criteria
- Estimates effort
- Identifies dependencies
- Splits large items
Refinement Best Practices
Before the Meeting:
- Product Owner prepares items
- Team reviews items ahead of time
- Questions are collected
During the Meeting:
- Focus on understanding, not solutioning
- Time-box discussions (5-10 min per item)
- Capture decisions and open items
After the Meeting:
- Update stories with new information
- Follow up on open questions
- Communicate changes
Estimation
Story Points
Relative sizing based on complexity, effort, and uncertainty:
| Points | Description |
|---|---|
| 1 | Trivial - well understood, minimal effort |
| 2 | Small - straightforward, limited scope |
| 3 | Medium - moderate complexity |
| 5 | Large - significant work, some uncertainty |
| 8 | Very Large - complex, consider splitting |
| 13+ | Epic - must be split before commitment |
Planning Poker
Team consensus estimation:
- Story is read and discussed
- Each member privately selects estimate
- Estimates revealed simultaneously
- Outliers explain their reasoning
- Repeat until consensus
Managing External Feedback
Capturing Feedback
- Customer support tickets
- User research findings
- Stakeholder requests
- Analytics insights
Processing Feedback
- Capture: Record all feedback
- Classify: Bug, feature, improvement
- Prioritize: Against existing backlog
- Communicate: Acknowledge and set expectations
Risk Management in Backlog
Identifying Risks
- Technical complexity
- External dependencies
- Unclear requirements
- Resource constraints
Risk-Based Prioritization
- Address high-risk items early
- Use spikes to reduce uncertainty
- Build risk mitigation into estimates
Tools and Visualization
Kanban Board
Backlog Health Metrics
| Metric | Target |
|---|---|
| Items ready for next sprint | 2x sprint capacity |
| Average item age | < 3 months |
| Items with acceptance criteria | 100% of ready items |
| Estimated items | 100% of ready items |
Best Practices
Do
- Keep backlog visible and accessible
- Refine regularly (weekly)
- Remove stale items
- Maintain single source of truth
Don't
- Let backlog grow unbounded
- Skip acceptance criteria
- Estimate in isolation
- Treat backlog as fixed contract
Related Resources
Compliance
This section fulfills ISO 13485 requirements for planning of product realization (7.1), design and development planning (7.3.1), and traceability (7.5.3), and ISO 27001 requirements for information security in project management (A.5.8) and change management (A.8.32).
How is this guide?
Last updated on