Managing Large Complex Backlogs

Topics

  • how to properly create user stories for complex systems
  • how to derive user stories from traditional customer or product requirements documents
  • how to ensure traceability between derived user stories and their parent requirements
  • how to measure progress in delivering the customer-facing product functionality

If our project is small enough we may start by creating a backlog populated with user stories. User stories are units of customer facing functionality that can be delivered within a single iteration. The scrum literature is full of examples like:

  • As a new user I can self-register
  • As a member I can login using the credentials supplied at registration
  • As a system administrator I can browse the list of registered users
  • As a system administrator I can search for registered users
  • As a system administrator I can disable a user’s account

A small release may have up to a few hundred of these types of user stories. The release backlog may be processed by one or more scrum teams who will implement the entire backlog over the course of several sprints.

At the next level of complexity the initial set of release requirements may not be defined with sufficient granularity that they can be individually implementable in a single iteration. Scrum refers to these requirements as ‘epics’. Epics are backlog items that must be broken down further before they can be delivered in a single iteration. If the epic list is larger than a few dozen items, this epic list could easily expand into several hundred items at the user story level. Hence it’s going to be important to impose some structure, otherwise we run the risk of losing sight of the forest in a vast expanse of trees.

Feature Categories

Grouping epics by feature category is one simple way of organizing a long list. Let’s say our product is a network router, typical feature categories might be:

  • Routing Protocols
  • QoS
  • Security
  • Management Features

All of the features (epics) to be delivered in the release fit within these categories. Each feature/epic is then decomposed further into units of functionality (user stories) that can be delivered in a single iteration:

A Structured Backlog

Note that this schema: Feature Category > Feature (Epic) > User Story is completely arbitrary. Furthermore, depending on the application, you may need more than 3 levels of granularity to specify and organize the customer’s requirements, and to get down to a level that can be delivered in a single iteration. There is no universal or standard way of doing this, and scrum does not prescribe how this should be done. Each organization or development team will need to develop the approach that best meets their needs. Let’s not forget the INVEST criteria for a good user story to help us determine if we have drilled down to the appropriate level of detail:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable
Letter Meaning Description
I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
V Valuable A user story must deliver value to the end user.
E Estimable You must always be able to estimate the size of a user story.
S Sized appropriately or Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. A user story must be sized such that it can be fully delievered (to the definition of DONE) in a single iteration.
T Testable The user story or its related description must provide the necessary information to make test development possible.

 

 

 

Print Friendly

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>