A product backlog is just an ordered list of all the things that need to be done to build your product.
There’s the definition. So, are we done?
Not so fast. While the definition is simple, in our experience, we’ve seen a lot of costly mistakes that could have been prevented by a better-managed backlog.
Generally speaking, the problems that cost the most for your business are the problems created by spending time and money on building the wrong thing.
Have any idea how much it’s costing you?
According to research, 30% of IT spend is wasted due to ineffective prioritization.
This is where having and using an effective product backlog can come to the rescue.
Unfortunately, there’s a lot of confusion out there in regards to product backlogs:
- How is a product backlog different from a product roadmap?
- Who is in charge of a product backlog?
- What is product backlog grooming?
- Does it matter whether you’re using Kanban or Scrum?
In this article, we’ll give you a comprehensive guide to what a product backlog is, how it’s best managed, and answer the most important frequently asked questions.
What is a Product Backlog?
Like we said, a product backlog is an ordered list of all things that need to be done. Within a backlog, items are ordered by priority, and the priority will (and should) change based on the work done in sprints, based on user interviews, based on stakeholder input and more.
But let’s keep going with what a product backlog should not turn into.
Product backlogs shouldn’t become a to-do list made by product managers who divide out tasks like they are managing an assembly line. A product backlog shouldn’t be run by just one person.
A product backlog shouldn’t be written in stone.
Instead, a product backlog should be a living document that guides your team sprint by sprint.
Think of the product backlog as the connection between what needs to get done and how it’ll get done.
This means a product backlog gets input from stakeholders, developers, designers, and customers.
Usually – and we’ll go over this in more detail later – all of the inputs are managed by the Product managers to help keep communication transparent and streamlined.
Finally, think of a product backlog as how to turn the vision outlined in your roadmap into a reality. When you create a product backlog, you’re effectively planning out, from a high-level point of view, your product development process.
A caveat before we get deep into the subject of how to make a product backlog work for you…
At Sprintwell, our expertise is in agile development. And our experience has taught us that teams need to adapt to find what works for them.
A lot of guides out there will tell you that “this is how we do a Product Backlog” full stop. Other guides will conflate Scrum with Agile (one of the seven deadly sins in our book).
But neither of those things is our cup of tea. Instead, we will tell you what, in our years of experience working with businesses like yours, generally works and what generally doesn’t. We are always trying to create efficient and flexible teams, which means adapting what you’re seeing here for your business and based on your objectives and resources.
Creating a Product Backlog
As we said above, a product backlog is a list of what your team will do next. But hold on.
We don’t want you thinking you need to detail your entire dev plan step-by-step, from start to finish.
If you do that, you’re outside of Agile territory, and you’re back to working with the sequential Waterfall method.
That’s why when you create a backlog, you want to do these seven primary things:
- Make sure you’re obsessed with getting feedback.
Just in case we haven’t made it clear yet, a product backlog is not a product manager’s to-do list.
Product managers will need to work to get significant input from multiple team members, users, and everyone else they can.
A product backlog requires you to blend development requirements and design requirements, distilling what the customer wants and how the business can deliver.
- Save the detail for the first few product backlog items.
Let’s say your backlog had twenty items and your team is typically handling 2 or 3 items per sprint.
You’d have a good amount of detail in items 1-5 and a little less detail in backlog items 6 – 10, and finally, you’d have the minimal detail needed, think of it as just an elevator pitch, of items 11 -20.
Why? Because backlog items 6 – 10 are subject to change based on the outcomes of the sprints conducted for backlog items 1-5. We’ve seen teams waste time by working deep in a backlog, only to have things change on them.
- Tie your product backlog to your product roadmap.
We’ll get more into this down below in our section on how a product roadmap helps you manage your product backlog items.
- Make sure backlog grooming is a team mindset and not just a daily or weekly morning meeting.
Hands down, one of the most common mistakes we see Agile-aspiring teams make is to adopt the names, the meetings, and the processes but to abandon the values and the principles.
We go over exactly what we mean in our section on cultivating a culture of consistent backlog grooming.
- Stick to one product backlog.
The point of a product backlog is to create a streamlined process that is easy to change. It’s nearly an oxymoron.
You want something task-focused that can, within a day, be re-arranged. Having more than one product backlog just gets confusing when it comes to re-shuffling priorities.
Here’s an Agile pro-tip: be cautious of any change you make to a process that has as its end result a negative impact on your team’s adaptability.
- Consistently revisit the product backlog and re-order as necessary.
A Product Backlog is never really complete. It’s a living document. Hence the grooming mindset in point 4.
And when you do revisit your backlog, frame what you can as a user story. Example: When X occurs, I want to Y, so I can Z.
- Put your product backlog on the wall.
This might be obvious, but it’s a big deal.
You want your backlog visible at all times, by all team members. Putting it on the wall allows you to create a culture where the backlog is discussed and changed, not just blindly followed.
We’ve also seen teams make their backlog available digitally, such as on a site like Trello. If that works for your team, then that works for us. The key takeaway is to put it somewhere where it’s easy for your team to reference.
How a Product Roadmap Helps You Manage Your Product Backlog
First, a product roadmap and a product backlog are not interchangeable.
But you should use the information in your product roadmap to help prioritize your backlog, and use it as a guiding principle when establishing acceptance criteria (basically, what sort of tasks get added as backlog items).
A good product roadmap doesn’t need to be complicated. In fact, it only needs three sections:
- Why: This section answers why this product is being built.
- What: This section will focus on what you hope will change because of the product. For example, What do you want users to do? And what do you want users to feel?
- How: This section breaks down the nitty-gritty: how it will get done and in what timeframe (though avoid getting too specific with a timetable).
A product roadmap gives you direction.
A clear, concise, and compelling product roadmap inspires the team, keeps everyone on the same page, and moves the product forward.
In our experience, the secret ingredient in making a good product roadmap is being obsessed with your customers.
The product manager has relationships with everyone, from stakeholders to team members to customers, but the product manager needs to be customer-obsessed.
This is critical when creating a product roadmap because a roadmap tells you which road to go down. And as we discussed in the intro, going down the wrong road and creating solutions that aren’t needed is a major waste of time, money, and energy.
If you’re new to building a product roadmap or think yours can be improved upon, download our free product roadmap template.
Who is in charge of the Product Backlog?
You may have heard that the Product Owner is in charge of the Product Backlog. And, sure enough, per Scrum’s guidelines, the Product Owner is the one responsible for task execution, structure, and overall content.
But here’s the thing.
The role of the “Product Owner” was to create and manage the backlog, approving or rejecting stories completed by development. And that’s a title and responsibility that solely exists within a Scrum system.
(A little further down we will go into things like Scrum, Kanban, what they are and more importantly what they aren’t, so bear with us for a moment).
So yes, you do want your Product Manager to, more or less, be the point person on managing the product backlog.
But what you desperately want to avoid is being so rigid that no one else gets involved in the product backlog.
Working within an Agile mindset isn’t natural for many teams. But the old way of working just didn’t apply to developing software. That’s why in 2001 a group of software-industry rebels got together to define the Agile Manifesto.
And when new set-in-stone processes prop up, like having only a Product Manager handle the backlog, you’re running the risk of undermining the very Agile principles you’re trying to incorporate.
What is the Difference Between the Product Backlog and the Sprint Backlog?
A product backlog is the big list of things needed for the product. A sprint backlog is the backlog for the action items with a specific sprint.
Think of a sprint backlog as a subset of the product backlog. So, within a product backlog, you’ll have several sprint backlogs.
This makes sense because you don’t want the structure and guiding values that you’ve used to help create the product backlog to disappear as soon as you start a sprint.
What is Product Backlog Grooming?
Sometimes we hear about structured meetings or time set aside for Backlog Grooming.
And yes, it’s important to have grooming sessions, but we really recommend you create a consistent mindset where backlog grooming is always occurring.
To do this, make sure your backlog is visible. This way, everyone on the team can comment, ask questions, and see any new changes.
Don’t make backlog grooming so formal a process that people within a team feel the need to wait until the next day to bring up an issue or suggestion.
Remember, in Sprints, even 2-3 days is a long time.
But whenever you do backlog grooming, we recommend that you follow a few best practices:
- Breakdown user stories into smaller tasks.
For example, let’s say I’m getting married and need to plan for the wedding. This is a huge user story. As a result, you break it down into stages: In order to have a wedding at my dream venue, I need to book the building. That stage can, equally, be broken down: To book the building for my wedding, I need to contact the coordinator. And so on.
The best teams break stories down into very small parts when it’s time to build.
Warning: Breaking stories down too far before a sprint leads to waste.
- Confirm the team is on the same page.
From developers to designers, the one thing you don’t want in your sprint is miscommunication and confusion.
Most importantly: Align on the ‘why.’ There’s no room for ambiguities when it comes to why any story is being worked on. Your team should know the answers to these two questions:
- What metric will this move?
- What larger initiative is this a part of?
- Bypass story points (which are often just a waste of time) and instead focus on expectations.
The biggest risk is that you ship things that don’t cause the change you want. Story points don’t help mitigate that risk at all.
Instead of talking about points, talk about impact.
Having conversations with developers about the size of stories, how to break stories down, and how long they generally think stories will take is a much better approach than fiddling with Fibonacci sequence and arguments over numbers (is this 5? or is this 8?).
Kanban vs. Scrum
We are going to be honest with you here: This section is mostly about clearing up misconceptions we often see in our line of work.
Kanban and Scrum are both specific ways to implement agile values and principles. Think of them as best practices that are trying to get your team closer to the agile school of thought.
Unfortunately, this has led to some confusion.
Far too often, we have to work against the misconception that Scrum is Agile. Scrum isn’t Agile. Kanban isn’t Agile.
Agile is Agile, and everything else is trying to create tools and processes that simply promote Agile values.
Furthermore, we don’t recommend you think in a “Kanban vs. Scrum” mindset but in a Kanban or Scrum or even Kanban and Scrum mindset.
Now, we aren’t just over here attacking Scrum frameworks and poking fun at a Kanban board. Both Scrum and Kanban have their purpose.
Scrum is an Agile framework focused on iteration and aims to help dev teams work together and deliver value as quickly as possible.
To clarify, your team can use words like scrum master, product owner, sprint planning, and you can be certified scrum, talk about scrum artifact and still be miles away from adopting an Agile methodology.
Kanban is an Agile scheduling system that allows teams to visualize the entire software dev process to see any potential bottlenecks.
Kanban is also great for teams that are simply responding to requests – in Kanban, the focus isn’t on individual, 2-week sprints but grabbing the next highest priority item off the board. For example, an IT support team would use a kanban board to prioritize requests. But again, just because you have your tasks lined up in an app that says Kanban doesn’t make your process Agile.
Generally speaking, most clients use Kanban for when requirements are stable, and the team is small. Scrum gets used when the requirements are rapidly changing, and the team size is large.
But to clarify: both Scrum and Kanban use backlogs. And backlogs in both systems help to gather and prioritize work that’s going to happen.
Conclusion
A product backlog allows you to make work visible, specifically aligning your team on which work needs to happen at any given moment or stage of your product design process.
When it comes to making a product backlog, there are various templates and numerous best practices available online. But you, as product manager and team member, will want to assess (with support from the dev team and stakeholders), the best method for your product development process.