What is a product backlog?
A product backlog is a prioritized inventory of features, defects, or technical work that has yet to be worked on. It should be work that is considered valuable from the product owner’s perspective. It can also include ideas that have been identified and, in some cases, prioritized to include in future releases.
When working on your product roadmap, you also need a spot for all the features that you want to implement, but are not yet tied to a release. This is typically called a product backlog. As features get prioritized, they should be aligned with product strategy. This ensures that when a release is finalized and shipped to development, the whole product team is working on what matters most to customers.
Managing and grooming product backlogs can be overwhelming. It's important to remember that each backlog item represents a customer request - even if it's an internal customer or team member. The request represents a need that a customer expects you to fulfill within your roadmap. If it cannot be fulfilled within your plans, the customer will need to fulfill their request goal some other way. This is why an efficient, scalable backlog management process and product backlog template is required to remain responsive as a product owner. It is also necessary to execute impactful and efficient release management.
The goals of a successful product backlog
A successful product backlog doesn't mean you fulfill every request. A backlog is a collection of what could be done next, but a successful backlog makes clear what should be done next. To clarify the future of a roadmap, a backlog must be organized in a way that answers the questions stakeholders may ask about your product journey and strategy.
You use a successful backlog in overall release management to plan strategically-themed, impactful releases that can be efficiently delivered.
A product backlog should be accessible
Even the most skilled product manager will be baffled by what to select next within a long list of homogeneous requests. And even a few dozen will seem like too many to review. Utilize organizational categories or tagging of backlog items so that you can retrieve a certain subset of backlog requests at any time. This makes your backlog accessible.
For example, if your executive sponsor often asks you what you have planned for a particular buyer persona in Q3, this is a good indicator that your backlog features should have a persona tie-in. If you will need to respond to the sales team on which opportunity requests will move forward, you should be keeping customer or opportunity reflected in your backlog.
A product backlog should be strategic
Some may say that a backlog directs your roadmap; in fact, it's the reverse. Your strategy roadmap is the journey you wish to take with your product. It drives selecting items from the backlog that contribute to the completion of that journey. You have already done the legwork to create your journey and strategy; use these strategic categories and their relative product impact to refine, or groom, your backlog to roadmap readiness. Leveraging your core strategy to groom your backlog will tame even the most unwieldy (or inherited) archive of dusty requests. So, categorize your backlog based on how each request rolls up to the established strategy for your product.
A product backlog should be inclusive
Remember that your product journey may not just include features. Your backlog may also include technical training for the scrum team, refactoring or re-architecture efforts, and other non-feature projects that may better position the team supporting your product. Include these items, but utilize the same grooming process to review them. Add feature types or product domain areas of categorization to your backlog to easily identify these items. If these items start to indicate a large effort that must be done, reflect this in your product strategy as a major initiative rolling up to a goal. This avoids "missing resources" in release management, because everything that can be worked on is represented.
Grooming a product backlog
A product backlog is never "done" — it is a living, breathing asset in your product release process that is constantly revisited. Utilize a backlog refinement or product backlog grooming process to progress the items contributing to your product strategy into your committed roadmap.
Gathering feedback
Continually leverage your stakeholders, customers, and supporting teams about new reveals and updates that might affect your product. Then, analyze their feedback — it's your job as the product owner to manage perspectives and incorporate feedback into a revised product journey. Spearhead the creation of a discussion and feedback engine to keep you scalable to the volume of feedback coming in. With each release you manage, a feedback cycle should be incorporated.
Saying "No"
Remember that every backlog item is a request with a requestor. Being as responsive as possible in saying "No" to an item enables the requestor to revisit why it was needed in the first place, or to go somewhere better aligned to meeting their needs. If you have inherited a backlog, finding and removing obsolete items will trim historical items considerably.
Categorizing backlog items
After you have identified the categories that will enable your backlog to be strategic, accessible, and inclusive, adopt a continual process to tag incoming backlog items with these categories. Your backlog categorization needs to identify those who have vested interest in this feature. Your "first cut" backlog grooming process of categorization should enable you to quickly identify which strategic objective the backlog feature belongs to; who will likely benefit if implemented (or be impacted if not); and who will be needed to execute the feature.
This process, in turn, identifies the sponsors, customers, and supporting teams related to the feature — and those that will likely ask you about its status later. So, choose "buckets" you can call upon quickly if any of those parties approach you for a backlog status update. Categorization can usually be completed by the product owner with minimal feedback from others. For example, a common backlog categorization would be to use buckets of product areas or themes like analytics, UX, safety, or compliance, with supporting tags for the feature related to strategic objectives or customer type.
Prioritizing backlog items
Once a product backlog has been liberated of obsolescence and put into categorized buckets with supporting tags, those buckets can be prioritized. Prioritizing a backlog means comparing features to confirm their strategic importance. In this stage, you are scoring your backlog items relative to each other. So, establishing a scoring metric is required.
The fidelity of your scoring metric may depend on your organization. The most efficient backlog refinement processes leverage a multi-metric scorecard that represents an ideal model of a high-value feature. Backlog candidates are scored against the metrics, and a prioritized list is the result. At minimum, a prioritized "High/Medium/Low" pattern should be achieved within your backlog.
Prioritization should be reviewed collectively with key stakeholders for buy-in at a product level. It is expected that this will be done on a recurring basis to keep your backlog fresh and responsive to changing market drivers. Remember to include the team as a stakeholder in review for backlog items that position your team to be better (research or internal projects).
Detailing backlog items
A categorized, prioritized backlog is one that development will be engaged with and execute. To do so, the backlog features must be refined with details and requirements to get them to a "ready" state. In order to complete this part of backlog refinement, the organization must agree on what it means for a feature to be ready. As a product owner, you will then drive the backlog items to this level of detail.
In agile environments, a backlog grooming session with stakeholders and the development team (normally a few days prior to the next sprint or re-engagement) will be done regularly. This ensures that enough features in the backlog are ready for development. These sessions will be most efficient if the collaboration team can access the backlog items to review in advance. In these sessions, collaborators will ask questions and the product owner will refine the backlog items with stories, requirements, and sufficient breakdown for developers. The stories will be estimated to know (and agree) on the level of effort. Planning poker or other estimation methodologies are used to complete this stage.
During this session, backlog items may stall in the refinement lifecycle if there is not enough detail for them to proceed or be estimated. This is expected and encouraged. It is also a far better outcome than pushing an item to development and getting unpredictable outcomes. Backlog refinement should be curious, detailed, and stringent to ensure that development is building what matters and what to build is clear. So, make sure your backlog is accessible with respect to "Ready" status. This ensures that others can quickly retrieve features that are ready vs. those that need additional refinement.
Scheduling from your backlog
The prioritization and refinement of your backlog is separate from its actual scheduling in a sprint and release cycle. Maximizing the development team's efficiency is another goal of a successful backlog. To maximize the development team's efficiency, they need easy access to the backlog of "Ready" items.
Keep in mind that releases typically have themes related to the value you are delivering and strategy they are executing. Therefore, you should balance this in your methodology for scheduling.
A successful product backlog is opportunistic
Product development resources free up at varied and unpredictable times as you release features. The best scrum product backlogs allow self-direction to individual developers on what to do next. This is accomplished by creating and adhering to the backlog refinement process.
If the scrum product backlog is accessible, detailed, strategic, and categorized, a developer that frees up can select the right "Next" priority task from the scrum product backlog — without needing to ask the product manager. Providing this scrum product backlog enables the product team to be as efficient and opportunistic as possible with available resources. Even a few extra story points in a sprint buffer can then be filled with a detailed, strategic, right-sized backlog feature. The product owner can then choose to "go to market" with the extra work in a given release if it aligns with the release-managed theme.
Revisiting a backlog
Continually leverage your product backlog grooming process within your organization to keep achieving your product backlog goals. As a product manager, it is your job to keep a finger on the pulse of what customers want. Market conditions and requirements will evolve constantly. As this occurs — and you keep speaking to your product’s end users — don't forget to revisit lower-scoring features to determine if they should move up in value.
Revisiting a product backlog not only means reviewing items as they come in. You should also review the process you've established to ensure that all teams achieve their needs from your product backlog and release roadmap.
Build products like you always wanted. See for yourself — start a free 30-day trial.
