## What Risks Come With Regularly Reviewing the Entire Product Backlog? Regularly reviewing the entire backlog can waste time and create false expectations. Teams may repeatedly discuss low-value or outdated items that are unlikely ever to be delivered, adding no real value. This not only drains focus from high-priority work but can also give stakeholders misplaced hope that irrelevant items might still be acted on. Focusing reviews on items likely to be delivered helps avoid this trap and keeps refinement meaningful. >[!experience] >I once worked with a team that had an extremely large Product Backlog—so large that they split it into two sections, labeling the lower-priority items as the "bottom of the backlog." Over time, even that section became so long that they created yet another layer, jokingly called the "bottom of the bottom." </br> As part of quarterly reviews, we were expected to go through both lists to ensure nothing valuable was overlooked. </br> We regularly spent time discussing these low-priority items, confirming that they were things we still _wanted_ to do someday. However, no meaningful action was ever taken on them, and we continued to carry them forward quarter after quarter. </br> Ultimately, this became a wasteful exercise—valuable time was spent rehashing work that realistically was never going to be done. It taught me the importance of keeping backlogs focused on items likely to be delivered, rather than maintaining “false hope” for work that adds no immediate value. ## Works Consulted 1. Personal Reflection/Experience. ## Connections follows:: [[3.2b Episodic Reviews Prevent Stale and Irrelevant Backlog Items]] topics:: [[Product Backlog]], [[Backlog Refinement]], [[Waste]] Related | [[3.2c Deleting or Moving Items Keeps the Backlog Relevant]] -> To ensure that we're not just reviewing the same old issues over and over again, we've got to be willing to delete or remove aging work items that we're realistically not going to prioritize. ![[Footer]]