“What are we going to work on next?”
“Are we set to start working on feature ABC?”
“Did you know about this bug XYZ?”
You must have heard these at work. If you are the product manager like me, a Product Backlog may be of great help getting this information to the rest of your team. Whether you already have one or you’re reading this as a step towards your first Product Backlog, I hope you find this article useful.
What is the Product Backlog?
The Product Backlog is is a collection of all needs, defects, and tasks related to a product. It is one of the most important artifacts or tangible assets I use as a product manager. It is a tactical document that implements a product strategy.
How is the Product Backlog related to the Roadmap?
The Roadmap is a representation of the Product Backlog that considers deadlines, priorities, estimates and dependencies between the different elements. It usually stays in the strategy layer, focusing on motivations and objectives, not detailed work items.
What does a good Product Backlog look like?
A product backlog must provide a shared vision, so they must be clear to technical and non-technical users, understood and treated as a living tool, and considered the single source of truth of all the known needs across the organization in relation to the product.
Shared to all relevant stakeholders
Different levels of information are ok, but a partial or high-level view of the product roadmap affects different functions of the business.
A Product Backlog must be clear, and include a description that needs to understanding of technical details. Also remember that you are writing for collaborators, not a marketing blog post: Use plain and descriptive language and use images and videos to support your words.
Communicate very clearly that it is a living plan, that will be adapted with the real delivery dates, the changes in the business priority, technical dependencies found along the way… Scrum.org says: “A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves.” As a living document, it must be kept alive, so make sure to incorporate any changes as early as possible. Commit to at least a weekly update.
Single-source of truth
Centralize all the needs that are related to a given product. Don’t fall into the trap of having separated backlogs for different modules or teams. Just because Jira, Trello and other tools allow the creation of multiple projects and boards it does not mean you have to use that feature. Having one product backlog where different teams collaborate is a much better way to manage work, as it allows everyone to see a high level overview that includes all aspects of the product work and to use filters to grain down the information they need in each specific case.
I hope you found this useful and are ready to start incorporating a Product Backlog in your organization.
Need more arguments?
If you have reached this point and are still not convinced about committing to a Product Backlog, or just need a little reinforcement or an argument to convince your manager or sourcing team, then I encourage you to read my post “No ticket, no party” where I give you 7 winning arguments to track your tasks.
You’re probably wondering about the best tools to do this, so I put together a list of Product Backlog Tools depending on your project size or complexity and your current organization culture.
Let’s talk about how I can help your team master your product backlog.