27 Product Backlog Anti-Patterns

Scrum is a tactical framework to build products, provided you identify what is worth making in advance. But even after a successful product discovery phase, you may struggle to create the right thing in the right way if your Product Backlog is not up to the job — garbage in, garbage out. The following article points to 27 common Product Backlog anti-patterns — including the Product Backlog refinement process — limiting your Scrum team’s success.

The Product Backlog According to the Scrum Guide

First of all, let’s have a look at the current edition of the Scrum Guide on the purpose of the Product Backlog:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

Source: Scrum Guide 2020.

Scrum, being a tactical framework, is good at effectively getting validated hypotheses into the hands of the customers to close the learning loop, allowing for the inspection of the initial assumption and decision process to build an Increment and subsequently adapting the preparations for the next Sprint.

Scrum is not good at formulating hypotheses and running experiments, validating or falsifying them, otherwise referred to as product discovery. That is not tactics but part of operations, positioning the Scrum team for success. If you look at the flow diagram above, Scrum’s part—tactics—is on the right side, while the product discovery part—operations—is on the left. There are ample opportunities to deal with the left part of the process, for example, Lean Startup, Design Thinking, Design Sprint, Lean UX, Dual-Track Agile, just to name a few. 

At any given time, a Scrum team needs to practice product discovery and product delivery (or product development) simultaneously and continuously. However, this necessity does not mandate squeezing all work items into the Product Backlog. On the contrary, in my experience, Scrum teams perform below their capabilities when they do not strictly adhere to maintaining two different artifacts for both parts of the process: 

1. There shall be a transparent artifact to keep track of ideas, hypotheses, experiments, and outcomes. (I like to refer to a part of that artifact as the Anti-Product Backlog, a living repository of issues that a Scrum team decides not to pursue.)
2. The second artifact is, of course, the Product Backlog. An effective Scrum team puts a lot of effort into keeping this artifact “actionable.” An actionable Product Backlog reflects the continuous effort of the Scrum team in product discovery in general—developing an informed opinion of which idea may be valuable to the customers—and refining those validated hypotheses into proper Product Backlog items. At this point, everyone on the Scrum team understands why the team pursues this opportunity over others, what the Developers shall build, how they shall accomplish this, and, probably already at this stage, who will work on it. Typically, the size of an action Product Backlog comprises 3-6 Sprints of work, and given that the Product Owner orders Product Backlog items by value, the Scrum team also has a good understanding of when they might work on this.

Common Product Backlog Anti-Patterns

Despite being relatively straightforward, the process of creating and refining a Product Backlog often suffers from various anti-patterns. I have identified five different categories for Product Backlog anti-patterns:

General PB Anti-Patterns

1. Prioritization by proxy: A single stakeholder or a committee of stakeholders prioritizes the Product Backlog. (The strength of Scrum is building on the solid position of the Product Owner. The Product Owner is the only person to decide what tasks become Product Backlog items. Hence, the Product Owner also decides on ordering the Product Backlog. Take away that empowerment, and Scrum turns into a pretty powerful waterfall 2.0 process.)
2. Over-sized: The Product Backlog contains more items than the Scrum team can deliver within three to six sprints. (This practice very likely will result in wasted efforts: You will refine work items that the Developers will never turn into Increments. Moreover, by investing all the efforts upfront, you may fall victim to the sunk cost fallacy, delivering less value than possible.)
3. Outdated issues: The Product Backlog contains items that haven’t been touched for several weeks or more. (That is typically the length of three to four Sprints. If the Product Owner is hoarding backlog items, the risk emerges that older items become outdated, thus rendering previously invested work of the Scrum team obsolete.)
4. Everything is detailed and estimated: All Product Backlog items are entirely detailed and estimated. (That is too much upfront work and bears the risk of misallocating the Scrum team’s time. The refinement of Product Backlog items is a continuous effort only to the point where the Scrum team feels comfortable turning these items into Increments.)
5. INVEST? The Scrum team does not apply the INVEST principle to Product Backlog items. (Failing to create independent, valuable, and small work items increases the risk of implementation failure during the Sprint. Therefore, a Scrum team is well-advised to invest—no pun intended—in a proper Product Backlog refinement practice to address possible problems before they start working.) 
6. Component-based items: The Product Backlog items are sliced horizontally based on components instead of vertically based on end-to-end functionality. (This may be either caused by your organizational structure, an effect called Conway’s law. In this case, overcome this organizational debt by moving to cross-functional teams to improve the Scrum team’s delivery ability. Otherwise, the Scrum team should invest in a workshop on writing better Product Backlog items.)
7. Missing acceptance criteria: There are Product Backlog items that need additional acceptance criteria without listing them. (It is unnecessary to have all acceptance criteria ready at the beginning of the refinement cycle, although they would make the task much more accessible. However, all Product Backlog items need to meet the Definition of Done and—probably—specific requirements at the work item level. If the Definition of Done does not provide the latter ones, the now necessary acceptance criteria shall result from the refinement process.)
8. Too detailed acceptance criteria: There are Product Backlog items with an extensive list of acceptance criteria. (This is the other extreme: the Product Owner covers each edge case without negotiating with the Developers. Typically, three to five acceptance criteria are more than sufficient. If you believe that you need more criteria, this may indicate that the work item is still too large and needs splitting.)
9. 100% in advance: The Scrum team creates a Product Backlog covering the complete project or product upfront because the release scope is believed to be limited. (Let me ask a question: How can you be sure to know today what to deliver six months from now when you work on a complex, adaptive problem? Isn’t not being able to predict the future the reason that you employ Scrum in the first place?)
10. No more than a title: The Product Backlog contains items that comprise little more than a title. (Creating noise by adding numerous “reminders” to the Backlog, thus obfuscating the signal it shall provide, will diminish the Scrum team’s capability to create valuable Increments for the customers. Ideas do not belong in the Product Backlog; they are part of the product discovery system.)
11. No research: The Product Backlog contains few to no spikes or time-boxed research tasks. (This effect often correlates with a Scrum team spending too much time discussing future problems instead of researching them with a spike as part of a continuous Product Backlog refinement process.)

Backlog Anti-Patterns of the Product Owner

1. Storage for ideas: The Product Owner uses the Product Backlog as a repository of ideas and requirements. (A large Product Backlog is probably considered a sign of a “good” Scrum team: You are fully transparent, and this is proof of your usefulness to the organization. However, being “busy” does not equal value to customers and the organization. The additional noise created by the sheer number of issues may also cloud the detection of valuable items. Lastly, the Product Backlog size may have a crowding-out effect on stakeholders as they feel overwhelmed. The idea-inflated Product Backlog may impede critical communication with them as a consequence.)
2. Part-time PO: The Product Owner is not working daily on the product backlog. (The Product Backlog needs to represent the best use of the Developers’ time at any given time. Suppose an update to the Product Backlog happens only occasionally, for example, shortly before the next Sprint Planning. Due to a lack of refinement, it is likely to leave a lot of value on the table. The value of the Product Backlog results in a significant part from the open discussion between the Product Owner and the Developers. In a good Scrum team, the Developers constantly challenge the Product Owner regarding the value of suggested Product Backlog items. This checks & balances approach reduces the probability of the Product Owner falling victim to confirmation bias, thus mitigating the risk that the Scrum team makes a wrong investment decision in the next Sprint Planning. As the saying goes: Love the customers’ problem, not your solution.)
3. Copy & paste PO: The Product Owner creates Product Backlog items by breaking down requirement documents received from stakeholders into smaller chunks. (That scenario helped to coin the nickname “ticket monkey” for the Product Owner. Remember: Refining Product Backlog items is a team exercise. Moreover, using practices like user stories templates helps everyone understand the Why, the What, and the How. Remember Karl Popper: “Always remember that it is impossible to speak in such a way that you cannot be misunderstood.”)
4. Dominant PO: The Product Owner creates Product Backlog items by providing not just the ‘Why’ but also the ‘How’ and the ‘What.’ (Just stick with the Scrum Guide and its built-in checks & balances: The Developers answer the ‘How’ question–the technical implementation–, and both the team and the Product Owner collaborate on the ‘What’ question: What scope is necessary to achieve the desired purpose?)
5. User story author: The Product Owner invests too much time upfront in creating Product Backlog items, making them too detailed. (If a work item looks complete, the Developers might not see the necessity to get involved in further refinement. This way, a “fat” Product Backlog item reduces the team’s engagement level, compromising the creation of a shared understanding. By the way, this didn’t happen back in the days when we used index cards, given their physical limitation.)
6. The ‘I know it all’ PO: The Product Owner does not involve stakeholders or subject matter experts in the refinement process. (A Product Owner who believes to be either omniscient or who is a communication gateway is a risk to the Scrum team’s success. Capable Scrum teams in general and Product Owners, in particular, know well when to reach out to others to better understand a matter at hand.)

Product Backlog Anti-Patterns at Portfolio and Product Roadmap Level

1. Roadmap? The Product Backlog is not in sync with the product roadmap. (The Product Backlog is supposed to be detailed enough to accomplish the current Product Goal. In my experience, this medium planning target often may require up to three to fours Sprints to complete. Beyond that point, the Product Backlog should instead focus on themes from the product roadmap in broad strokes, pointing at the upcoming Product Goal but nothing already too specific. The realization risk of these themes at this point is too high. In that respect, the Product Backlog reflects a “rolling” subset of the product roadmap at any given time.)
2. Annual roadmaps: The organization’s portfolio plan, release plans, or product roadmaps are created once a year in advance, never to be touched again in the meantime. (If the Product Backlog stays aligned to these plans, it probably introduces waterfall planning through the backdoor. Agile planning is always “continuous” to mitigate the risk of misallocating efforts to outdated plans. This kind of “rolling planning” also applies to product roadmaps that benefit from being revised at least every 6-12 weeks, depending on the industry.)
3. Roadmaps secrets: The portfolio planning, the release plan, or the product roadmap are not visible to everybody involved in creating Product Increments. (If you do not know where you are going, any road will get you there. The “big picture” is crucial for any Scrum team’s success. It needs to be available to everybody as product success is a team sport, dependent on the ideas, insights, and skills of every team member and stakeholder.)
4. China in your hands: The portfolio planning, the release plan, or the product roadmap are not considered achievable and believable by those supposed to deliver it. (If this is reflected in the Product Backlog, refining work items will probably be a waste.)

Backlog Anti-Patterns of the Developers

1. A submissive Scrum team: The Developers submissively follow all demands of the Product Owner. (Challenging the Product Owner whether their selection of work items is the best use of the Developers’ time is the noblest obligation of every team member: Why shall we do this? Scrum does not work without everyone living up to the checks & balances built into the framework. It is easy to fall in love with “your solution” over addressing the real customer problem. If Developers simply make whatever the Product Owner “suggests,” the overall value created by the Scrum team will likely be below its potential. That is why you want missionaries on your team, not just mercenaries.)
2. What technical debt? The Developers do not demand adequate time to tackle technical debt and bugs and preserve the quality standard of the product. Instead, they fully embrace the feature factory, shipping one new feature after the other. (My rule of thumb is that the Developers shall consider allocating up to 20 % of their time to fixing bugs and refactoring the codebase. A high-quality tech stack is at the core of being able as a Scrum team to adapt the following steps to lessons learned and recent market trends. Technical excellence is a prerequisite of any form of business agility; preserving this state is a continuous process that requires a steady and substantial investment.)
3. No slack time: The Developers do not demand 20% slack time—or unplanned capacity—from the Product Owner. (This overlaps with the Sprint Planning, creating Sprint Goals, and the team’s ability to forecast. However, it cannot be addressed early enough. If a team’s capacity is always utilized at 100 %, its performance will decrease. Everyone will focus on getting their tasks done. There will be less time to support teammates or to pair. Minor issues will no longer be addressed immediately. And ultimately, the ‘I am busy’ attitude will reduce the creation of a shared understanding among all team members why they do what they are doing.)

Product Backlog Anti-Patterns of the Scrum Team

1. Involving the Scrum team—why? The Product Owner is not involving the entire Scrum team in the Product Backlog refinement process and instead relies on just the “lead engineer” and a designer. Moreover, the Developers are okay with this approach as it allows them to write more code which they prefer over figuring out what is worth building. (When trying to solve a complex problem, there are no experts but many competing ideas. Therefore, limiting the active participants in refinement activities to a few team members instead of the whole Scrum team increases the risk of falling victim to confirmation bias as the diversity of opinion is artificially limited.)
2. No time for refinement: The Scrum team does not have enough Product Backlog refinement sessions, resulting in a low-quality Product Backlog. (The Scrum Guide 2017 initially advised spending up to 10 % of the Scrum team’s time on the Product Backlog refinement. This is a sound business decision: Nothing is more expensive than an ill-designed feature delivering little or no value.)
3. Too much refinement: The Scrum team has too many refinement sessions, resulting in a too detailed Product Backlog. (Too much refinement isn’t healthy either. There is a moment when the marginal return of an additional refinement effort is zero or probably even negative—think analysis-paralysis. The only way for a Scrum team to understand whether the previous validation of the underlying hypotheses of a new feature is correct is to build and ship this thing. There is no way to figure this out at the green table, refining and discussing the issue endlessly.)

Conclusion

Even if you have successfully identified what is worth building next, your Product Backlog and its refinement process will likely provide room for improvement. Just take it to the team and address possible Product Backlog anti-patterns in the next Retrospective. In my experience, it is the easiest way to improve the Scrum team’s performance and thus the team’s standing among stakeholders and customers.

What Product Backlog anti-patterns have you observed? Please share with us in the comments.