Netspective Logo
Agile Development

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

CriterionDescription
IndependentCan be developed separately
NegotiableDetails can be discussed
ValuableDelivers value to stakeholders
EstimableCan be sized by the team
SmallFits within an iteration
TestableHas 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 changed

Definition 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

CategoryDescription
Must HaveCritical for this release
Should HaveImportant but not critical
Could HaveDesirable if time permits
Won't HaveExplicitly excluded

Value vs Effort Matrix

Value vs Effort Matrix

Weighted Shortest Job First (WSJF)

WSJF = (Business Value + Time Criticality + Risk Reduction) / Job Size

Higher 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 login

CRUD 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 dashboard

Backlog 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:

PointsDescription
1Trivial - well understood, minimal effort
2Small - straightforward, limited scope
3Medium - moderate complexity
5Large - significant work, some uncertainty
8Very Large - complex, consider splitting
13+Epic - must be split before commitment

Planning Poker

Team consensus estimation:

  1. Story is read and discussed
  2. Each member privately selects estimate
  3. Estimates revealed simultaneously
  4. Outliers explain their reasoning
  5. Repeat until consensus

Managing External Feedback

Capturing Feedback

  • Customer support tickets
  • User research findings
  • Stakeholder requests
  • Analytics insights

Processing Feedback

  1. Capture: Record all feedback
  2. Classify: Bug, feature, improvement
  3. Prioritize: Against existing backlog
  4. 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

Kanban Board

Backlog Health Metrics

MetricTarget
Items ready for next sprint2x sprint capacity
Average item age< 3 months
Items with acceptance criteria100% of ready items
Estimated items100% 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

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).

View full compliance matrix

How is this guide?

Last updated on

On this page