10 Product Backlog Tips

By Roman Pichler, 2nd November 2016
Photo courtesy of Pexels

Working with the product backlog can be challenging, and many product owners wrestle with overly long and detailed backlogs. This blog post provides ten practical tips that help you work with your product backlog effectively.


Tip #1: Complement your Product Backlog with a Product Roadmap

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. Then derive your product backlog from the roadmap and use the goals to discover the right backlog items. This ensures that your backlog is aligned with the product strategy, and it helps you decide which items should be added to the product backlog and which should not.

ProductRoadmapAndProductBacklog


Tip #2: Focus your Backlog on the Next Major Release

Use the product backlog as a tactical tool that states the product details–including epics and user stories–that have to be implemented to deliver the next major release. This results in a concise backlog, which is comparatively easy to update and change. The longer-term growth of your product should be captured on the product roadmap.


Tip #3: Start with a Short and Sketchy Product Backlog

Particularly when you create a new product or new features and keep the lower-priority items coarse-grained. Use the user and customer feedback to decide which feature to implement, to evolve the product backlog, and to refine its items. It’s OK, however, to have a longer, more detailed backlog when your product is mature and your focus is on incremental changes and bug fixes.


Tip #4. Collaborate with the Development Team

Involve the team members in the product backlog work. 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.


Tip #5: Say No

Decline ideas and requirements that do not help you meet the release 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 few months, then consider adding it to the product roadmap.


Tip #6: Look beyond User Stories

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.


Tip #7: Prioritise your Backlog

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.


Tip #8: Proactively Manage your Product Backlog

Regularly groom 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 backlog: remove and add new items, and update existing ones. This maximises the chances of building a product that users really want and it keeps the product backlog up to date and concise.


Tip #9: Get the Backlog Ready

Break larger items into smaller ones by leveraging the insights gained from exposing product increments to the users. Ensure that the high-priority items are ready for sprint planning: the items should be clear, feasible, and testable. This facilitates a realistic commitment, and it helps the team turn the items into a product increment without having to constantly ask you during the sprint what the user story means and if there is something missing.


Tip #10: Make your Product Backlog Visible and Easily Accessible

Try a paper-based backlog and put it on the wall. Such a backlog offers several benefits:

  • It is clearly visible and creates transparency–assuming that it’s on the team room wall and people are colocated.
  • It alerts you when your backlog is becoming too big, as you will be running out of wall space.

A tool like my Product Canvas helps you structure and visualise your backlog.

PersonasOnTheProductCanvas

If using a paper-based product backlog is not possible, employ an electronic tool that is easy to use; or consider a mixed approach with some of the items on the wall and others–like the high-priority stories–in a tool like JIRA.

Summary
Article Name
10 Product Backlog Tips
Description
10 practical tips to help you work with your product backlog effectively and prevent it from becoming too big and complex.
Author
Pichler Consulting

Learn More

You can learn more about effectively working with the product backlog with the following:

Source: http://www.romanpichler.com/blog/ten-product-backlog-tips/

RSS Feed

Tags related to this post:


16 comments on “10 Product Backlog Tips

  1. tushar

    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

    • Roman Pichler

      Thanks for your feedback Tushar!

    • Roman Pichler

      Thanks Tushar. Glad to hear that you find the post helpful.

  2. Kaya

    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?

    • Roman Pichler

      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!

  3. Tommi Joentakanen

    Insanely valuable post. Thank you!

  4. Andreas

    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

  5. 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

    • Roman Pichler

      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?

  6. Nina Madeira

    Excellent article. Thank you for sharing!

  7. Agile Scout

    Solid article. Thanks for sharing!

Leave a Reply

Your email address will not be published. Required fields are marked *