In the IT world, a backlog is a list of to-be-done tasks needed to complete the project. It should be managed by the Product Owner (PO) – the person responsible for setting the direction of the project development. Still, that person often asks different teammates to log their tasks, and that’s where the backlog mess starts.

Product backlogs

In terms of product, the backlog lists all the requirements for the system being created. It does not matter whether we are talking about functionalities, plans for system development, non-functional requirements, or errors reported by users.

Think about it as a big sack into which we place all ideas related to our project as reported by users, testers, or developers. I have already seen quite a few backlogs run in such a way, where the list of tasks waiting for implementation exceeded three-digit numbers (sic!).

Task attributes of a good Product Backlog in Agile

The less mess there is, the faster the work will be. It’s a simple principle. But for it to work, each backlog user should sign under a document outlining the task creation process. 

Whether a task is an Epic, a User Story (or User Stories), Use Case , or else, the description needs to be elementary enough for the product team’s new member to understand what needs to be done and what’s the expected end result. That’s the first attribute. Clarity eliminates time wasted on explainer chats and meetings, which a Product Owner can easily get dragged into.

The value of a tasks’ elements is another important product backlog attribute to consider. “Positive” tasks bring positive change, so they should have priority over other elements. Negatives are for later.

In order to plan the upcoming workload, it is also worth knowing the time consumption and complexity of a task. That’s called task estimation — the third attribute in a well-managed Product Backlog.

Order is the last attribute of a good product backlog. At the top of our list, there should be tasks ready for implementation with heavier tasks below where discussion and analysis are still needed.

Recommended practices

It’s good to top our list with enough tasks for the two upcoming Sprints (if that’s how you work). To do that, our PO needs to know the development’s team performance and to have task estimates at the top of the backlog.

Discussing tasks longer doesn’t always make sense. If you expect business priorities can soon change swiftly, then fight for the time needed for actual work.

Another important approach is to put tasks that meet the so-called Definition of Ready at the top of our list. It is an agreement between the Product Owner and the development team on what elements the task should have before it goes into the implementation phase. 

To be complete, each task should have these four elements.

• A description – thanks to that we will know the business value of the task
• Acceptance criteria – thanks to that we will know what the customer expects and will also allow us to conduct appropriate tests
• Designs – if it is a task with new graphics, it is worth having it delivered to the task
• The user path (sometimes called the happy path in the Gherkin language) – what allows us to learn the next steps that the user will take

Now, let’s open the Sprint Backlog

Once we have the Product Backlog set up, we can move onto the Sprint Backlog. What’s that? The Scrum Guide says:

The Sprint Backlog is a set of Product Backlog items selected for the Sprint plus a plan to deliver the Product Increment and meet the Sprint Goal.

Pretty simple, right? 😉 But let’s start from the beginning.

You create the Sprint Backlog during Sprint Planning. Items that go to the Sprint Backlog come from our previously discussed Product Backlog. You should keep in mind that the Product Backlog may be a to-do list for multiple teams working on one system, but the Sprint Backlog is a to-do list for just one specific team. 

When planning the next Sprint, the team decides which elements they will deliver. The most important question is what is the goal of the next Sprint? The development team is the owner of the Sprint Backlog. It’s their responsibility to prioritize and manage individual tasks that are on the list. This means that the team has control over the elements on which they work. 

Tasks that fulfill the Sprint goal should be nearly at the top of our list for the next Sprint, so that they’re picked up first.

If during a Sprint there is a need to add, modify, or delete anything in the Sprint Backlog, the Development Team can do this. The team doesn’t have to ask anyone for permission, as long as it doesn’t change the scope of the Sprint.

Of course, there may be a situation (it’s quite common) that during the Sprint, the Product Owner or even the team want to change the scope of the Sprint. When there is a change of priorities, the new task should replace an old one that’s already in the scope. The replacement needs to be similar in terms of its complexity and timeframes.

On a bright day, when the team reports that it has completed or is close to completion of the Sprint’s scope, they may hop onto new tasks. After consultation with the Product Owner, they may select another task for implementation.

Managing both backlogs

List management is one of the hardest and most essential activities around the backlog. Merely writing down tasks, organizing and estimating them won’t help us progress if we don’t update our lists.

To make this process easy to do, our lists should remain open to team members. For this purpose, we use the so-called Scrum Board or an available plain board. As I mentioned before, for our two lists, we have other people responsible for keeping them in order.

In the case of Sprint Backlog, the team handles the order. Very often, tasks are updated during the Daily Standup Meeting. It mainly consists of “dragging” the task to the appropriate column on the board and setting a status update. It all depends on what the team agreed on and how they set up the board.

Working with the Product Backlog is more challenging. The Product Owner is (or at least should be) the main person responsible for the transparency of this list. This does not mean that other stakeholders cannot add anything to this list. It meas the PO should call the shots.

As I mentioned before, the Product Backlog can very often resemble a bottomless well with unfiltered suggestions for the development, improvement, or refactoring. Fortunately, there’s a time to clean up this list during the development work called. We call it the Refinement meeting.

In that moment, the Product Owner (often in collaboration with others) adds, adjusts, grooms, and prioritizes items within the backlog to make sure the most valuable product is shipped to customers. The meeting also aims to evaluate if everything in this Sprint needs to be delivered and what are the priorities for the next one.

Remember that an extensive Backlog can really hurt the project.

• Costs of maintenance – each item on the list eats resources for in analysis or execution
• Reduced product innovation – a vanity basket has a negative impact on all stakeholders, because they won’t be able to add workloa

Prioritizing brings results

A dependable Product Owner will understand their responsibility for running our Backlog at max efficiency as long as collaborators will follow the lead on task creation, delivery, and refinement. In fact, you should have your own holy book for backlog management that sets a cross-department standard of work.

You may also want to determine an optimal submission process for new backlog entries that ensures each task comes with well-registered business needs. You can also try progress markers that will help everybody navigate backlogs at a speed (e.g. on hold; ready for refinement; ready for development)

Creating a backlog itself is a stroll. Keeping it updated like a news presenter is hard but certainly doable. Good luck!