How to structure the backlog to make it work

Having worked on software development projects for years, I’ve seen lots of ways how a backlog can be organised. Throughout my professional career, I have come up with a few simple definitions and rules for backlog items, which helped me make the backlogs more productive. Let’s have a look.

Defining the issue types

Look how amazingly they use different sea creatures for different types of items! Photo Credit: led-maha.weebly.com on Flickr. cc

The first thing you need to do when planning a backlog structure is think about which types of items you expect to have in it. A typical agile backlog will consist of things like stories, and spikes, and sub-tasks. But the question is — what do they actually mean and which purpose do they serve? Understanding this will dictate the format and type of information you are going to capture in the tickets.

At the end of the day, the tickets in the backlog represent our knowledge of the product to be built. The way we slice and present this knowledge will inform how easy it is for the project team to comprehend it and to build something of value. With this in mind, let’s exercise a tad of practical ontology and model the types of elements that may go into a functional backlog.

 * * *

The main purpose of the product backlog is to scope the product to be built. So whenever possible a single backlog item should describe the functionality or capability that will be delivered when the backlog item is done. In the traditional project management methodology this was called a product breakdown structure. You take the vision of the final product, break it down into smaller elements that you need to deliver, and call it a backlog.

This approach to structuring your backlog is preferable compared to the backlog consisting of the work items — tasks to be done — because it ensures a holistic view of the final result. This creates a shared understanding across the team and the stakeholders of how the product is going to look like. A good format for capturing these types of backlog items is using something like a “user story” or a “job story”. I will refer to them just as “stories”.

The goal of such a backlog item is to define what the final functionality is going to be, which value it is going to deliver, and how to prove that it has been delivered in full.

In terms of a life-cycle for such a backlog item, it will start with defining the scope of the solution as per the team’s “definition of ready” and finish with delivering the final product as per the “definition of done” the team has. Of course, we assume your team has these amazingly helpful definitions in place. If not — you should start thinking about them right now!

   * * *

Sometimes, you don’t know what your solution is going to be. Still, you need to have an item to capture this unknown as a part of your backlog. Such items are often referred to as “spikes”.

The idea of a “spike” is that the team uses a time allocation to explore the problem area and define a potential solution that in turn can translate into a “story” type of a ticket. The aim of having these tickets is to give the team the context of the problem and scope the problem in terms of the user outcomes the solution is going to support. Understanding the context and the expected outcomes, the team will have flexibility in trying to find and validate a potential solution design. This design can be translated into delivery ready backlog items.

Because we use the expected user outcomes as a way to scope these tickets, the team I work with started to call them “outcome stories” as opposed to some other terms like “spikes”.

To a sense, the definition of done for such a story should meet the definition of ready for the resulting development story(-ies). This enables a smooth transition from discovery/design/validation work into development work.

* * *

Scope of the project and scope of the product are things interrelated, but different. If we refer back to the classic PM theory, the product breakdown structure should be eventually translated into a work breakdown structure. The idea behind it is simple: if there is a piece of functionality that needs to be delivered, there must be some effort to produce it. So each functionality based backlog item (each “story”) will eventually be broken down into actionable steps to get it delivered — either physically in the backlog as technical tasks or mentally in the people’s heads when estimating the stories.

In addition to these steps which describe how to deliver a particular story, a project scope will have lots of extra activities that often need to be captured and accounted for. This is when you need to introduce a new type of backlog item — a “task”.

The idea behind a “task” is simple. It captures an activity that needs to happen but does not directly result in an element of a final product. For example, you could use a task to capture meetings, reports, local computer set up tasks, etc.

A natural question arises: when do we stop using tasks and start using stories? Is setting up a local environment a task or a story? Is configuring a certain setting on production a task or a story? I usually follow this simple rule: if a backlog item does not bring immediate value to stakeholders outside of the project team, call it a “task”. If it does, call it a “story”.

* * *

Not always the promises are kept. Not always our expectations are met. Not always the requirements are implemented in full from the first attempt. This is when there is a need to capture the mismatches between expectation and reality and store them in the backlog.

A typical way to capture it is to raise a new item type — “bug”. The goal of this backlog item type is to highlight the difference between the requirement and the actual implementation and give enough details to understand the severity of the problem and to subsequently troubleshoot and resolve it.

Due to its nature, a bug should be somehow linked to the story it is related to. If we claim a requirement is not met, we should be able to trace this claim back to the original statement. There are two ways this linkage can be established, and depending on your delivery methodology and toolset you may decide which one works better for you.

The first option, a bug can be created as a separate backlog item. It will mention the original story in its description (e.g. a link to another backlog record, or story’s ID). This allows you to separate the life-cycle of a story and the life-cycle of a bug, and effectively treat a bug as a standalone backlog item which can be independently prioritised.

Another option, a bug can be raised as a part of the original story, e.g. as a sub-task to it. This makes the bond between the story and the bug much stronger, effectively saying: unless you fix this bug, the story cannot be considered done — it will still have an outstanding sub-task.

I typically tend to create bugs as sub-tasks if a bug is found when the story is still in progress. This way we acknowledge that the story is not complete and needs more work. It becomes a managerial decision whether the bug needs to be fixed within the same iterations (e.g. the same sprint) or not. If the decision is to defer the bug, then I would change its state from sub-task to a standalone backlog item, which can be addressed in a later iteration. This action will also unblock the story from being closed. However, if a defect is found for an already closed and accepted story, I’d rather raise it as a separate item straight away. I find it generally a bad practice to reopen tickets, and adding sub-tasks to something that is closed means dooming them to never be done anyway.

Logical grouping

Photo Credit: institute_west_uni_koblenz on Flickr. cc

The longer the backlog gets, the harder it is to manage it. This is where different types of classification will come handy. They will help your backlog be not a scary list of hundreds of items, but a powerful tool that will help prioritise, make decisions and assign work to teams or team members. Let’s expand our little ontology model with tools that help add structure to the backlog.

First of all, you will need a way to group elements of the backlog that are likely to be released together. Typically, you will achieve this by assigning tickets to “releases” — logical chunks of tickets that need to be done by a certain date altogether.

This does not, however, by default mean that all of these items need to be worked on at the same time. It is a good practice to separate which tickets the team needs to address together vs. which tickets need to go live together. I’ve seen teams trying to manage both using the same mechanism, such as “sprints” in Jira — it gets messy real fast. Much better to separate the fields.

An individual ticket may belong to a particular element of the solution architecture. It may become vital to translate this link between a requirement and an element of the solution into the development team — it is an architectural decision that must have had some thinking behind it; we don’t want to lose it. So you may think of adding another field into your ticket template for “solution components” the ticket should be addressed by.

Last but not least, a group of tickets may solve a common problem or address a common customer need. It becomes handy to keep this connection in place, as it helps prioritise work and build roadmaps. You may capture this commonality as a common “theme” between the backlog items.

Let’s put it all together

These 4 types of backlog items should be enough to structure and manage any type of software challenge. We chose the ticket type based on which goal we have in mind:

• describe an expectation of a final piece of software functionality (a “story”)

• indicate an unknown that needs to be validated before a product solution can be built (a “spike” or an “outcome story”)

• capture an activity to be performed (a “task”)

• highlight a mismatch between a requirement and an implementation (a “bug”)

The tickets can be grouped in multiple categories to ease prioritisation and planning of work. Specifically, from the scoping perspective think about which tickets address a common problem and which tickets will be delivered by a common solution component? From the planning perspective, understand which items need to be delivered by a certain common date, and which items will need to appear on the team’s board at the same date?

It is important to ask yourself a question: “Why am I writing this ticket?”. Understanding the goal implies using a better suited semantic structure for your ticket. In simple words: depending on your goal you will choose a different ticket type. The ticket type will dictate which template to use and which information to provide within.

Answering these questions while building your product backlog will help you get a well-structured tool to manage the product development as opposed to just a list of tasks. Use it well, your backlog needs to be your friend ;)