How to Maintain Your Product Backlog in 5 Easy Steps


A product backlog is never done. It is a living, breathing part in your product release process that is constantly revisited. That is why it helps to utilize a backlog refinement or product backlog grooming process to progress the items contributing to your product strategy into your committed roadmap.

Without a strategy to vet features based on business impact, it is easier to add all of them to an endless backlog that never seems to shrink.

Then release planning rolls around. And it becomes too easy for product managers to only focus on what is top of mind today -- which keeps previously requested features a distant memory. The result? An abandoned backlog, where features that could be game-changing get buried beneath the new, new thing.

Here are five steps you can start taking today to maintain your product backlog:

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

Say, "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.

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.

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 grooming processes leverage a multi-metric scorecard that represents an ideal model of a high-value feature.

In these efficient grooming processes, 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).

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 grooming, 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.