I find that the product backlog is best used to capture the product details. In this sense, it is a tactical tool that facilitates product delivery. If that’s the case, then you will benefit from completing your product backlog with a product roadmap. A product roadmap sketches the overall journey you want to take your product on.
I like to work with goal-oriented product roadmaps, which contain product goals that describe the benefits or outcomes your product should create in the course of the next six to twelve months. This picture below illustrates this setup.
Use a product goal like acquiring users, increasing conversion, or future proofing the product by reducing technical debt to direct and focus your product backlog. Any items in the product backlog should help meet this goal. If that’s not the case, you should remove them. While this approach may sound radical, it will result in a concise product backlog that is comparatively easy to update and change
If you complement your product backlog with a product roadmap that contains the product goals your product should meet, as I recommended in tip #1, you can use the next goal on the roadmap and copy it into your product backlog. This nicely connects your product backlog and product roadmap.
Starting with an incomplete product backlog with largely coarse-grained items is particularly beneficial when you create a new product or add new features. Collect the user and customer feedback on early product increments to decide which functionality should be implemented, to evolve the product backlog, and to refine its items. Note that is alright to have a longer, more detailed backlog when your product is mature and your focus is on incremental changes and bug fixes.
Involve the development team members in the product backlog work, for example, by running collaborative product backlog workshops. This allows you to benefit from their knowledge and creativity and discover technical risks and dependencies. It also increases the understanding and buy-in of the team members and results in better, clearer requirements. Ask your Scrum Master to facilitate the sessions to help you focus on offering product leadership while ensuring that everyone is heard and nobody dominates.
Use uncertainty and risk to decide how soon an item should be implemented. Addressing uncertain items early on allows you to test your ideas, to fail fast, and to learn how to continue. Complement risk with cost-benefit and take into account dependencies when necessary. If you struggle to prioritise your product backlog, see my article “Prioritising a Product Backlog When Everything is Important.”
A key purpose of the product backlog is to direct the work of the development team: High-priority items are pulled into the sprint transformed into a product increment. To ensure that this can happen, you have to break larger items into smaller ones until they are ready for sprint planning: the items should be clear, feasible, and testable. This facilitates choosing a realistic sprint goal, and it helps the development team members do their work without having to constantly ask you for clarification during the sprint.
The product backlog is not a static, fixed plan. Instead, it evolves based on the insights you gain from collecting user feedback and building the product. You should therefore regularly update and refine it together with the development team.
Analyse the feedback and data collected from exposing the latest product increment to the users and apply the new insights to the product backlog: remove and add new items, and update existing ones. This maximises the chances of building a product that users want, and it keeps the product backlog up concise and usable.
Have the courage to say no and decline ideas and requirements that do not help you meet the product goal and move you closer to realising the product vision. This ensures that your product has a clear value-proposition, and it prevents your product from getting bloated. If the idea or requirement is important but cannot be realised in the next months, then consider adding it to the product roadmap.
While user stories, and functional requirements in general, are important, they are usually not enough. Also consider the user interaction, the nonfunctional qualities of your product, and the user interface and capture them in your product backlog.
As the product backlog describes the outstanding work required to progress the product, it is important that everyone involved in the development effort has access to it. I therefore recommend using a product backlog tool that is easy to use and that facilitates collaboration.
One option is to use a paper-based product backlog that’s on the office wall—assuming that people are collocated. A tool like my Product Canvas can help you structure and visualise your product backlog.
As markets, products, and technologies change at an ever-faster pace, strategies that used to last…
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
View Comments
Hello Roman,
I am a big fan and find the resources in your blog very helpful. I'm dealing with the dilemma of how to incorporate a physical board along side the use of a digital tool for backlog tracking (as the business requires us to use one due to the nature of a particular project). I wondering, from your own experience, how you can best make this work without creating too much 'overhead' of tracking (either for the team, Scrum Master or PO) as the team should be focused on the actual work and not the tracking of it. That being said, the way they are currently using both is causing some confusion as team members might update one but not the other and vice versa.
Your feedback is appreciated!
Thanks
Hi Tseten,
Thank you for your feedback and question. When working with a backlog that is partially physical and partially electronic, I like to visualise epics, scenarios, workflow diagrams, sketches, and global non-functional requirements like robustness and interoperability on the wall using my Product Canvas template. I store the detailed, ready user stories in an electronic tool like JIRA or a spreadsheet. This makes the big picture visible and easily accessible and it allows conveniently sharing the items to be worked on in the next sprint.
Does this approach work for you?
Hi, thank you for this post I agree with your point that Use a roadmap to sketch the overall journey you want to take your product on. State the upcoming major releases with their goals or benefits. very useful information
Thanks Tushar. Glad to hear that you find the post helpful.
Thanks for your feedback Tushar!
What helps me the most in case of backlogs is the deep analysis of the tasks waiting - as you said, DEEP. Prioritising sounds obvious but is ommited very often.
I'm to try creating dimensions like described on here: http://kanbantool.com/blog/how-to-deal-with-an-ever-growing-backlog , what do you think about this method? Have you tried it?
Thanks for your comment Kaya. if you struggle with a long product backlog, the try the following: Limit it to the next major release or three months; keep the lower-priority items coarse-grained; say no to ideas and requirements that are not moving you closer to your release goal and/or vision. If you are interested in experimenting with structured product backlogs, take a look at my product canvas. Hope this helps!
Insanely valuable post. Thank you!
Hi Roman,
all good points! Some I already had in mind, others not yet. The one with vertical products will be really hard, I think. Ten years of component-focused development and product management will be hard to overcome. However, product portfolio management is what I miss most.
Thanks a lot!
Andreas
In my current situation, I have at least seven products in my backlog. There is a mix of customer-facing products and software components that are required to make the rest work. Hence, maintenance stories exist along with product features, customer requests and bugs. Unfortunately, I act more as a proxy PO since we have product managers for most of the products . However, I am also missing roadmaps that I could use as input for product-based backlogs. I am seriously thinking to switch to Kanban for the maintenance team and use Scrum for roadmap-based product dev only.
If you have any advise, that would be great!
Thanks for sharing your know-how anyway!
Andreas
Hi Andreas, It sounds like you are facing four challenges: How do you best slice your products? How do you capture how each product is likely to develop? Which process is best suited for developing new features, which for maintenance? And finally, who owns the products?
To tackle the issues, I suggest you get together with the product managers and and the team. Decide how you want to set-up each products to enable effective development. Consider using vertically aligned products, products that have a user-facing part as well as the middle tear or backend components necessary to provide the desired functionality. Capture each product in a separate product backlog and create a product roadmap that communicates how the product is likely to grow in the next 12-18 months. Decide which process is best suited to develop each product. For products that are being maintained, a Kanban-based process is likely to be more appropriate than Scrum. Finally, tackle the ownership piece. Discuss who manages which product, and who manages the product portfolio.
Does this help?
Excellent article. Thank you for sharing!
Solid article. Thanks for sharing!