We believe the Management Fixes are common and typical so every description is created and adapted from articles, blog posts and definitions from other sources and authors.
This week’s MngtFix is…
Have you ever seen this MngtFix? What problem(s) was it solving?
Share your story!
This week’s “Product Backlog/Roadmap Definition” is often an overlooked solution.
By definition, the product backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
(Extracted and adapted from https://scrumguides.org/scrum-guide.html#artifacts-productbacklog)
The product roadmap is a strategic product-planning tool that shows how the product is likely to grow across several major releases.
If applied correctly, the two tools complement each other nicely. The product roadmap provides an umbrella for the product backlog; it tells a longer-term story about the likely growth of the product, whereas the product backlog contains the details necessary to create the product.
(Extracted and adapted from https://dzone.com/articles/product-roadmap-and-product)
The backlog is a great tool to capture ideas and requirements. But it is less suited to describe how the product is likely to develop in the longer term. This is where the product roadmap comes in.
(Extracted and adapted from https://www.romanpichler.com/blog/product-roadmap-product-backlog/)
When well-prioritized, the backlog not only makes release and iteration planning more manageable, but it also broadcasts all the things your team intends to spend time on, including internal work that the customer will never notice. It helps set expectations with stakeholders and other teams, especially when they bring additional work to you, and makes engineering time a fixed asset.
(Extracted and adapted from https://www.atlassian.com/agile/scrum/backlogs)
When we define our product backlog, we are planning, and this plan comes with some benefits like: