Backlog Organization

Hero image for Backlog Organization

Standardizing the management of the backlog is essential for maintaining clear and highly actionable backlogs. It also allows any Product Manager on the team to understand any project’s backlog with little effort.

Without standardization, it becomes extremely difficult and time consuming for a Product Manager to understand how a backlog is organized, let alone how the product needs to be developed.

Depending on the project and the client requirements we might use different tools for backlog management. Regardless of the tool, the way we organize the backlog revolves around the same concepts. Only their representation varies to adapt to the capabilities of the tool used.


Module representation in a backlog

Modules represent the main components of an application. They are the smallest denominator to which an application can be reduced. Each module contains several features.

For example, most applications will need an “Authentication” module which will regroup all login and registration features.

In fact, there are several modules that are usually common to most applications: Application (the most generic module in an application), Authentication, and User Profile.

Naming & Slugs

Example Name Label
Authentication module Authentication #authentication
Customer Relationship Management module CRM #crm
Payment gateway module Payment #payment
Push notifications module Push Notifications #push-notifications

Module names should be as short and accurate as possible. There is no specific pattern for it and it is up to the Product Manager to identify names that fit this ideology best.

In addition to having a name, modules also need a slug for use in labels. The slug is a shorter, more condensed form of the name. Given how short module names are, the slug is typically a hyphenated version of the name.


Module representation in a backlog

Features are coherent and standalone groups of user stories that define functionality in the application. A feature must belong to one and only one module (there is a hierarchical relationship between the two).

└── Feature

The feature must detail the rationale behind it and provide clear context to the team. Read on how to write a proper “why” for a feature.

A feature must be the smallest standalone piece of software which brings business value.

For example, “User can login with email and password” is a feature belonging to the “Authentication” module. So is “User can login with Facebook” (for applications that support it).

As the examples above show, features are small and standalone. Others companies might encompass both login with email and login with Facebook as one feature. However, such an approach forces the Engineering team to deliver both for the feature to be complete.

In reality, if the “Login with email and password” feature is ready but “Login with Facebook” isn’t, the former can still be released as a working, standalone feature to a production environment. It is the reason why a feature must be the smallest standalone piece of software which brings business value.

Writing a Feature

There is always a reason behind each feature. It is crucial to provide enough information for developers to understand the idea. When a feature is well-understood, it will give developers an excellent platform to work their magic on the implementation with the correct goals.

Product Managers used to write a “why” in each user story. However, it led to more downsides than benefits:

  • The content was often the same between the different implementation areas (backend, frontend, integrate).
  • Because of the repetitive nature of the task, Product Managers did not always share enough context.
  • Important information about the “why” was sometimes too scattered across many small user stories.

To address those downsides, Product Managers now write the “why” at the feature level.

Providing Clear Context

Having the “why” at the feature level is an opportunity for Product Managers to put more thought into it while simultaneously spending less time working on it (by not having to write a “why” for every user story).

At the feature level, the “why” must be very clear and thoroughly detailed. It must outline:

  • The need for the feature (i.e., what problem it aims to solve).
  • How the feature aims to solve the problem (high-level only, details should live in the feature documentation).
  • Any relevant context that may help developers make the right decisions when implementing the feature (e.g., dependencies on other features or third-party systems).
  • Links to relevant resources and documentation.

Naming & Slugs

Example Name Label
Users can view the list of tickets User can list tickets $user-list-tickets
Admins can view the details of a specific ticket Admin can view ticket details $admin-view-ticket-details
Agents can create new tickets Agent can create ticket $agent-create-ticket
Agents must assign a ticket to an agent Agent must assign ticket $agent-assign-ticket
Admins can delete an existing ticket Admin can delete ticket $admin-delete-ticket

The above examples are very CRUD-like. Not all features can be described using this exact format but Product Managers should strive to follow this pattern as much as possible.

The naming for all features should follow a pattern that is somewhat similar to the user stories but in a shorter form.

The naming pattern, whenever possible, must be <user> <requirement> <action> <item> where:

  • <user> defines the type of user targeted by the feature.
  • <requirement> should be one of: can, must (used to highlight a hard requirement for a user to accomplish something).
  • <action> should be one of: list, view, create, delete.
  • <item> defines the item that is being developed.

When following this pattern is not possible, feature names should always be descriptive. Generic feature names are frowned upon. For example, if a login feature needs improvement, creating a feature named “Improve login” is virtually useless as it doesn’t describe the update. Moreover, when multiple iterative improvements are being made to a feature a name such as “Improve login” becomes useless and confusing.

Instead, be descriptive. If the login feature needs to receive field validation then the feature should be named “User can see live validation when logging in.” This name is descriptive and helps understand the feature at a glance.

In addition to having a name, features also need a slug for use in labels. The slug is a shorter, more condensed form of the name.

When feature names can follow the recommended pattern, the slug pattern should be <user>-<action>-<item>.

When a feature name can’t follow the recommended pattern, its slug should follow the same ideology being short and condensed. For example: user-login-live-validation.


Versioning software is a basic principle (this very documentation is versioned on GitHub). In the backlog, each user story must be associated with a released version to facilitate tracking and debugging.

Versions are identified by the label @x.x.x where x.x.x is the actual version number. For example, all user stories released as part of version 1.2.2 must have the label @1.2.2.

For the versioning numbers, we follow Semantic Versioning best practices. This means that we do versioning with the following format MAJOR.MINOR.PATCH:

  • MAJOR: when you make backward incompatible changes.
  • MINOR: when you add functionality that is backward compatible.
  • PATCH: when you make bug fixes that are backward compatible.

User Story Types

Module representation in a backlog

We use three types of user stories even if a given backlog management tool offers more (or customizable) types: “User Story” (called “Feature” in some tools), “Bug”, and “Chore”.

Guide on writing user stories


Labels (or tags) are heavily used in our backlogs. They help represent the backlog’s organization (with variations between backlog management tools) and any other sort of data visualization. It is important to use labels (there is no overuse) whenever something important needs to be tracked or presented.

For example, should there be a Request For Change for a product, the associated user stories should be labeled with the RFC number following the format rfc-<number>.

While there are a number of standardized labels, all labels don’t have to be standardized. It is at the Product Manager’s discretion to create and maintain relevant labels in their backlogs.

Standard Labels

There are a handful of standardized labels that are used throughout most backlog management tools.

  • Module label. Its pattern is #<module-name>. Example: #authentication.
  • Feature label. Its pattern is $<feature-name>. Example: $user-list-tickets.
  • Chore label. Its pattern is !<chore-name>. Example: !setup-ci-cd.
  • Version label. Its pattern is @<semver>. Example: @1.2.2.

Those standardized labels are not necessary with every backlog management tool but, when they are necessary, they must follow the above patterns.


The standardized labels are prefixed with a symbol (e.g., # or $). Non-standardized labels must not be prefixed by any symbol.

The use of a symbol for the standardized labels allows for better sorting.

For example, when sorted alphabetically (a default in most tools), the modules authentication and user-profile would likely not be listed consecutively. Other labels would likely be in the middle.

Using a symbol forces the standardized labels to be listed consecutively. In the example above, #authentication and #user-profile will appear with all other module labels without others in-between.

Initial Label

As all projects must start with an exhaustive backlog, all the initial user stories must be labeled initial-scope. It will help later on with differentiating the initial project scope and the changes that made their way into the backlog and to the product. This label will give a snapshot of the project at its early stage.


Taking a user story from “new” to “completed” requires going through a few specific steps. Our implementation workflow has five steps:

State Description
Icebox User stories that are not yet ready to be scheduled or even reviewed by the Engineering team. For example, ideas that the Product Manager doesn’t want to forget but require further research or preparatory work.
Ready for development The user story has been scheduled and developers can pick it up and start implementing it.
In development A developer has picked up the user story and is currently working on it.
In code review The developer finished the implementation and the code is being reviewed by peers.
Ready for QA The code has been successfully reviewed and was accepted requiring a round of manual Quality Assurance (QA).
Completed Quality Assurance has been done and the user story was deemed complete and finished.

If Quality Assurance fails, the user story is moved back to “In development” with a comment detailing why QA did not pass.

Product Development Workflow