Product Backlog Perfection: 3 Examples Of Backlogs Done Right
Have you ever looked at your backlog and wanted to delete everything on it and start from scratch? Well, I have had that feeling more than once as building and maintaining product backlogs is not an easy feat. But, to show you how to do backlogs right and inspire you to clean up your own, let me share four exceptional product backlog examples with you.
What Is The Product Backlog In Agile And Scrum About?
The Product Backlog is a living document containing all of the items that the product team, scrum master, and engineering team plan to work on to build their product.
It consists of everything that you need to build and maintain your product including new features, technical debt tasks, technical process improvements from your latest retrospective, QA automation tasks, and more.
The core characteristic of a product backlog is that it is a prioritized list where items at the top have the highest priority and the team should take them first when they are planning their sprints (or when they have spare space on their kanban board).
Product Backlog Vs Sprint Backlog Vs Product Roadmap: What’s The Difference?
In agile project management and scrum methodology, in particular, a product backlog is not the only list of items that the product owner creates for your development team. There are also the Sprint Backlog and the Product Roadmap. But what’s their difference? Let’s understand.
Sprint Backlog: This is a subset of the larger backlog and contains only the items that the scrum team has included in the next sprint or another type of iteration as a result of a sprint planning meeting. Items here are usually well-groomed and contain story points.
Product Roadmap: This is a high-level big-picture document that shows the major features and milestones for the product. Unlike the backlog which is more tactical in nature and contains descriptions of features, the product roadmap is strategic and serves the purpose of showing the team members and stakeholders where the product is headed and what the top-priority focus areas are.
Now that you and the key concepts have been properly introduced, let me jump straight into explaining how to manage your product backlog (and how, um, not to).
How NOT To Do It Right: Here’s A Horrible Product Backlog Example
Understanding the antipatterns of creating and managing product backlogs is probably as important as learning the best practices. The reason is that if you do not know that something is an antipattern, you are risking having it in your backlog and thinking that this is something normal and ordinary.
To go over some of the practices that can significantly decrease the quality of your backlog, let us look at the example below.
Back to the example. Please take your time to examine it closely.
Looks horrible, doesn’t it? In fact, by looking at this backlog, the majority of us will experience two emotions:
- Disgust from the messiness of the items on this backlog.
- Guilt, because let’s admit it, all of us have had a backlog that looked like this (me too, of course).
Now let’s break down the issues found on this backlog.
Overload of Product Backlog Items
Did you notice that there were 665 issues on this backlog? Well, the largest backlog that I had the “joy” of managing had over 2,500 items on it.
The problem with an overloaded backlog is that you will almost certainly be unable to remember what each item on it is and why you have placed it at a certain position/priority on your backlog. As you have no idea what these tasks are about, you are not likely to bring them to your next refinement, discuss their details, and include it in the upcoming sprint.
So, you end up with a huge unmanageable mess that keeps piling up infinitely.
Improper Backlog Prioritization
Another issue that you might have noticed on this backlog list is that there are work items with “Lowest” and “Low” priorities placed at the top—above items with a “Highest” priority.
This represents the typical case when your backlog is not properly prioritized. There can be a lot of reasons for this, but the most likely is that you have deprioritized a “High” priority item by lowering its position on the backlog but have forgotten to change the priority field.
Lack of Detail
Did you notice the item saying “I want seamless integration with all social media platforms”? LOL. That's not even a proper user story, considering the massive scope it is targeting. The scope is so huge, that, in practice, you should have several epics covering it with each epic containing the stories for one social media platform.
Apart from the massive scope, the problem with this item (in fact, with every item in this backlog) is its vagueness. User stories are supposed to describe a specific user experience and action.
Imagine taking this story to the backlog grooming meeting with your agile team. You would face a torrent of questions about nearly every aspect of the story.
"What do you mean by seamless?" "What does the integration look like?" "Which social media platforms are we integrating with?!"
“I want everything, and now”
Another red flag that you might have noticed on the backlog was that 70% of the items on it had a “Highest” priority. This is another typical situation when you are relying purely on the opinions of your stakeholders when setting priorities (and each stakeholder considers their items important) without trying to evaluate them objectively and compare their importance to that of other items in the list.
Now that we have defined what a bad backlog looks like, let’s fix it and discuss four good backlog examples...so you can make your backlog great again.
3 Examples Of Backlogs Done Right
Before I show you these examples, I want to note that there is no single correct way of creating a great backlog. The way your backlog looks will depend on the nature of your product, its maturity, the size of your company/team, etc.
In reality, a great backlog is one that is able to bring clarity and alignment among everyone regarding the current and upcoming scope of your product.
However, there are generic ways that you can manage your backlog that will make it more organized and easier to use for everyone. Each of the examples below represents such a best practice.
Example #1: A Backlog With Sections
It is almost never ok to have a backlog with hundreds or thousands of items on it. However, having 100-ish items is usually quite common and normal. But even with a hundred items on your backlog, it is easy to forget what each one is about or leave them untouched for a long time without adding them to your upcoming sprints.
To make your backlog more organized, you can consider breaking them down into sections.
Some product managers like to use sections to group items based on their areas of focus or milestones. I personally prefer using Version, Epic, and Component tags on tasks for this and breaking my backlog down into sections based on the scope of upcoming sprints.
This is a great way of allocating a sprint (or at least a rough implementation timeline) for the vast majority of items on your backlog and making sure that no task is left neglected.
Another common way of backlog management with sections is by grouping items based on their refinement status/workflow. In this case, you streamline your process with the following sections:
- Current Sprint
- Ready for Planning
- Ready for Grooming
- Backlog
What you do in this case is work on adding requirements and descriptions for the items on the backlog. When the requirements are ready, you are sending them to the “Ready for Grooming” section which serves as your scope for the next refinement meeting.
After refining an item, you are moving it to the “Ready for Planning” section, indicating that it is ready and the team can include it in their upcoming sprint.
Example #2: A Backlog With Properly-placed Components, Epics, and Versions
Segmenting your backlog will surely make it cleaner and more organized. But the limitation of using segmentation only is that you can organize your backlog based on one criterion only (e.g. the sprints, the grooming status, etc.).
Luckily, modern product backlog tools provide you with a wider array of options for organizing your product development to-do list based on multiple criteria. Just look at this delight of a backlog.
Doesn’t it look well-organized and pleasing to the eye? In this particular case, we have taken advantage of the following features to make our backlog more manageable:
Components
This field/characteristic traditionally describes the area of the product where you want to add the feature in question. In the example above, the components are the separate products that make up Grammarly.
Another common way of using components is to organize stories/tasks based on the technology required to create the feature. For web applications, for instance, you can have Frontend/Backend components to help you organize the work and dependencies between engineers specialized either on client-side or server-side development.
Versions/Releases
With this characteristic, you are documenting all of the features and bugfixes that your scrum team will release with a certain version of your product. Version tracking on the backlog comes with two highly-valuable benefits.
- It helps you plan your sprints and releases. For instance, if you plan a release in 2 weeks, then, during the planning meeting, you should make sure to include all of the tasks intended for that release version in the sprint.
- You are able to document everything that your team has put into a certain version and easily trace issues back when something happens on production.
For instance, imagine people start getting Captcha errors on your signup flow on the latest 1.3.2 version. When searching for the task based on which your team made changes to the captcha configurations, you see that it belongs to the 1.3.1 version. It means that you will have to either roll back to version 1.3.0 or do a hotfix.
Epics
Well, I don’t think I need to explain what an epic is and what are the benefits of using it. But, if you want to dive deep into the best practices and nitty-gritty details of epics, you can check out our epic guide (pun intended) on it.
Example #3: A Backlog With the Right Amount of Details For Each Section
This is a best practice that you might have stumbled upon in a lot of books and theoretical pieces about agile and product management. Although we tend to become a bit more skeptical towards theoretic concepts the more experience we gain, this one is actually useful in practice.
So the idea is that the items on top should have a lot of details and ideally you should have taken them through a product backlog refinement at least once. The items at the bottom of the backlog, on the other hand, should have little details, as the chances are high of you learning something new about your product and end-users and this item becoming obsolete.
This means that if the item on the top of your backlog looks like this (or even more detailed than this):
Your stories at the bottom of your backlog should have much fewer details and look like this:
And whatever stories and initiatives you have in the middle of your backlog will have a mid-level of details.
Example #4: I Know It’s Obvious, But… a Clean Backlog
I know it is not easy to keep your backlog clean. I have been there many times and I know that it feels like a chore. However, not reviewing everything on your backlog and remembering to get rid of outdated items are major factors determining the quality of your backlog.
It is not always easy to delete things from your backlog. There are really nice features out there that you hope to do someday (mainly nice-to-have things) and sometimes you don’t really want to get rid of them. But at a certain point, let’s face it, you know that you're never going to implement it. And even if you do, it would mean that you are out of high-priority features which is not a good sign in general.
Sometimes it is your stakeholders that have created these outdated items on your backlog. Before removing them, you try to ask them if their request is still in effect and their answer is almost always yes. Well, if the request is more than 6 months old and they had forgotten about it already, just convince them that it is not something urgent (if it was, they would have followed up with it multiple times) and delete it.
A Great Backlog Is What Works Best for You
If you took into consideration all of the best practices here, would you have a great backlog? Well, they will help, but will not guarantee greatness.
Don’t forget that the purpose of the backlog is to be a single source of truth for everyone. So, apart from these best practices, you need to take into consideration the needs and the working style of your team and stakeholders and build your backlog in a way that helps them stay on the same page.
This guide on great backlogs is part of a larger series of everything agile. Subscribe to our newsletter for more guides and insights like this delivered biweekly to your inbox!