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:
- It’s a simple list, discussed face-to-face
- It provides the customer with control
- The product backlog is allowed to change.
- Inspection and adaptation
- It resolves dependencies timely, and without fancy pansy dependency graphs.
- It allows for some longer-term planning
(Extracted and adapted from http://www.aptoma.com/the-product-backlog-6-benefits/)
Product backlog items act as placeholders for future conversations about an option for achieving your desired outcome. That means a team doesn’t have to have an idea fully fleshed out before adding it to the product backlog. A product backlog item only needs to be fully described when a team is about to start work on it.
(Extracted and adapted from (Extracted and adapted from https://www.agilealliance.org/glossary/backlog/)
This MngtFix has been mentioned with many MngtBugs such as…
“Undefined Project Scope”,
“Lack of Product Backlog Refinement”,
“Lack of Sprint Backlog”,
“Lack of Product Requirements Definition”,
and of course “Lack of Product Backlog” & “Lack of Product Roadmap”!
Call to action
What about you? How can I make this post more relevant for you?
Do you have other suggestions?
I would love to know more about your feedback and stories so that we can learn, share and grow together!
Feel free to subscribe to the Human Management Weekly newsletter and share this with your friends and colleagues. https://mailchi.mp/humanmngt/previousissues
If you liked it, there is a good chance they will like it too!
Have a lovely week and remember…
Human Managers should be open to being inspired and inspire others!