Agile Backlog

In this blog post I want to share some guidelines around creating sound Product Backlogs for your agile teams. While this is certainly the realm of Product Managers or Product Owners, it often falls to the BA to assist or ‘own’ the Backlog details within agile teams.

In general, I find that teams spend too little time grooming. This leads to problems like –

  • Painfully long sprint planning meetings
  • Little thought being placed into designs
  • Poor planning and execution
  • Lack of creativity when solving business problems
  • Poor forecasting

Think of backlog grooming as something beyond simple requirement definition. It’s inclusive of project planning, design & architecture, and strategy development. So spending some time here is a great investment — both in the short term sprint execution and in longer term release strategy development.

Product Backlog & Grooming ‘Quality’ Checklist

1. The Scrum Master facilitates the grooming meeting; not the Product Owner, driving everything. Core Scrum roles come nicely into play…

  • Scrum Master as facilitator; process guide; coach
  • Product Owner as business needs and value driver; defining the what and NOT the how (design) or how long (time)
  • Team participates as a partner with the Product Owner in the real-time evolution of the Product Backlog

2. Backlog Length – the backlog should contain sufficient detailed items to entertain your team for a release; using team velocity and your release tempo as a multiplier. And sufficient epic items to accommodate 2 releases (however you define ‘release’ in your organizational context).

  • Another rule-of-thumb, is to target / limit the Backlog to somewhere between 50 – 100 User Stories
  • Every backlog item should have a distinct, thoughtful priority – order

3. Grooming – run grooming meetings 2x a week. Remember the 10% investment guidance provided by Schwaber – so 4 hours per team member (individually and in meetings) per sprint week

  • Another guideline is to have every User Story iteratively explored with the teams a minimum of 4x before sprint execution.
    • As a high level epic; at least a release before execution
    • As a story or set of stories 3-4 sprints away from execution
    • As a story 1-2 sprints away from execution
    • As a story right before execution