We’re a fan of product backlogs as you can probably tell: after all, we named our project management software after them! But what is a product backlog, and why are they so useful?
A product backlog is essentially a prioritized task list of everything that needs to be done within a project. If a job isn’t listed on the backlog, then it doesn’t get done.
The product owner is in charge of the task list, including its content and order. But — and this is important — unlike traditional team schedules or to-do lists, the product owner isn’t in charge of defining when each individual task is to be completed. That’s down to the team members.
How a product backlog boosts your team’s productivity
A product backlog makes both developer’s and product owner’s lives easier; instead of the dev team working at someone else’s pace and having work pushed on them, they can instead look at the product backlog, work out which jobs need to be done in what order, and pull jobs from it as and when they’re ready. This means they can focus on doing the best job they can, free from the stress of unrealistic deadlines and frequent interruptions.
Because everything is transparent, product owners and other team members alike are always up to date on work. This greater level of openness helps with iteration planning, as well as budgeting and expectation management.
Kanban vs Scrum: different ways to run your backlog
There are two main ways of working through your backlog list. You can either take a Kanban approach, which requires the team to continually pull jobs through and communicate in real-time. Or you can implement a Scrum way of working, and pull jobs through iteratively.
The Kanban approach is highly collaborative: team members pull jobs through and share tasks equally, free from any predefined roles. It’s particularly good for iterative improvements and projects with widely varying task priorities.
Scrum, on the other hand, sees the project management group tasks together in batches (known as ‘sprints), each of which has its own set completion date. So while team members still pull jobs through at their own pace, they have their own defined roles and are working towards an overarching deadline. This offers a more defined, structured way of working and is best suited to projects where the priorities are stable and are unlikely to change much over time.
How to create a product backlog
First, create a roadmap. This is essentially a way to give your team context; it should show your team how the product will evolve and grow, and includes all the information about product functionality and features, as well as timelines. The roadmap is a top-level document that should give a broad overview of the entire project.
Roadmap features are then broken down into milestones. Milestones, like sprints, and are made up of smaller tasks that contribute to the overarching project objective. After the team has completed one milestone, they’ll move onto the next.
Milestones are traditionally shown as a feature, accompanied by a short one- or two-line description, which is expanded upon in user stories, i.e. descriptions that help define the benefit from a customer’s perspective. Here’s an example:
“As a <shopper> , I want to <see my shopping cart before checkout> , so I can <review my items before I pay>.
The words in bold are the variables. They change depending on your goal or business, but the format remains the same whether you’re creating a user story for an e-commerce site, a government form, and everything in-between.
Essentially it should define the user, the action, and the goal so the person working on the task knows what they have to do. Most importantly, it should define why it’s valuable to the end user.
What’s the difference between milestones and epics? Milestones are fixed in scope and are used to track tasks and issues according to time. Epics, on the other hand, track issues and bugs according to subject.
How to prioritize your product backlog
It’s tricky to prioritize when everything is urgent. But if you’re a product owner, it’s all in a day’s work.
It’s the product owner’s job to decide on the priority order based on factors like customer need, implementation difficulty, task dependencies, and feedback urgency while keeping a good line of communication between all parties to optimize planning.
In terms of the task order, there’s no right or wrong way, and many choose to mix and match depending on their priorities. Sometimes, the product owner may want to deliver a complete epic first. At other times, they’ll pick and choose certain stories from different epics.
That’s the beauty of having a product backlog and a roadmap; the backlog means everyone can see and control progress, whereas the roadmap provides that all-important context.
Defining long-term and near-term jobs
As the backlog gets bigger, it becomes necessary for product owners to group tasks according to their near and long-term status.
Near-term jobs are fully fleshed out with complete user stories, cross-team collaboration plans, and estimates in place. Longer-term items tend to be more loosely defined. Although if you do have information to add, provide those details as early as possible.
Remember, even rough estimates and plans are helpful (just remember to state their ‘roughness’ so people know the estimates are likely to change).
How to make your product backlog a success
- Do keep it well organized and updated. Product owners should review the backlog with the addition of every new feature and iteration to make sure everything’s prioritized correctly and feedback has been incorporated. It should be a reliable source of information for your dev team.
- Don’t create multiple backlog lists to track bugs. It’s easier if the dev team is all working from one unified list. If you have multiple teams, then create one list per team, rather than several lists for one team. Keep it simple!
- Do close jobs and issues. If your team won’t have time to work on something, create a protocol for setting it aside for later. If you’re using Backlog, you can either list it as ‘resolved’, close the issue and reopen it later, or set a date for it to be followed up on as needed. Simple!
- Do re-prioritize jobs. If you’re a product owner, then do feel free to re-prioritize tasks according to new requirements and customer feedback. But remember to keep changes to a minimum so as to not disrupt the dev team and their focus.
- Do encourage conversation. Stakeholders and dev team members will challenge your priorities. And you may want to challenge the dev team about their task completion speed. Use this as an opportunity to shape your planning and get everyone on the same page.
Backlog grooming is sometimes called backlog refinement, but they both mean the same thing: keeping your backlog tidy, organized, and up-to-date. Whatever you call it, smart product owners keep their product backlog well-tended.
Final thoughts
It’s the product owner’s job to define the priority of task items. And it’s the dev team’s job to dictate the task completion speeds.
For product owners who are used to defining both priority and speed, handing the latter over to the developers can be tough; it requires a hefty dose of trust, something that’s even more of a challenge if the relationship is a new one.
The key to taking the stress out of this situation is — you guessed it — a healthy helping of communication. Using project management software, like our Backlog, keeps that flow of communication strong with things like work-in-progress statuses, real-time notifications, version control, and time-management features. When it comes to product backlogs, it’s simple: the more transparency, the better!