Roman’s Top Ten Product Backlog Tips

Posted on Tuesday 8th February 2011

Summary

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

Working with the product backlog can be challenging, and many product owners wrestle with overly long and detailed backlogs. The following ten tips help you use your product backlog effectively.

  1. Derive your product backlog from the Vision Board or the product roadmap. Your product backlog should describe one product.
  2. Make your product backlog DEEP. Ensure that is detailed appropriately, emergent, estimated, and prioritised.
  3. Use a multi-dimensional backlog like my Product Canvas for new products and for product updates aimed at new markets.
  4. Make your product backlog visible. Put your backlog up on the wall or if that’s not possible, on a wiki server where it can be accessed easily by everyone involved in the development effort.
  5. Keep your backlog focussed and concise. Your backlog is likely to change and grow based on customer and user feedback.
  6. Employ user stories to capture ideas and requirements. Start with epics and progressively decompose them into detailed stories thereby incorporating the user feedback.
  7. 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.
  8. Capture generic operational qualities such as performance, robustness and interoperability as constraint stories; describe the product or user interface design visually, for instance, in form of sketches, mock-ups, and screen shots.
  9. Update your product backlog to incorporate the insights you have gained from demoing or releasing software to the customers and users. Involve the development team to leverage the team members’ knowledge and creativity. Include stakeholders as appropriate.
  10. Make sure the top items are “ready“: clear, feasible, and testable. This allows the team to turn the items into a product increment, and it facilitates a realistic commitment.

You can learn out more about the product backlog by attending my Certified Scrum Product Owner training course.

  • Pingback: Tweets that mention Roman’s Top Ten Product Backlog Tips » All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership -- Topsy.com

  • http://agilescout.com Agile Scout

    Solid article. Thanks for sharing!

  • Pingback: Produktmanagement Lesetipps: Überblick agiler und schlanker Methoden, die Rolle des Product Owners, 10 Tipps zur Backlogpflege, Sprint-Retrospektiven, Usertests « Produktmanagement und Vermarktung von Internet-Anwendungen

  • Pingback: [Product Owner] – Top 10 Backlog Tips | Agile Scout

  • Nina Madeira

    Excellent article. Thank you for sharing!

  • Pingback: Top Ten Backlog Tips | Team Sake Bomb

  • http://www.whatevermobile.com 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

    • http://www.romanpichler.com 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?

  • http://www.whatevermobile.com 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

  • Pingback: No Backlog Policy | Pawel's Blog

  • http://www.wapice.com Tommi Joentakanen

    Insanely valuable post. Thank you!