28 Product Backlog and Refinement Anti-Patterns

TL; DR: 28 Product Backlog and Refinement Anti-Patterns

Scrum is a practical framework to build products, provided you identify in advance what to build. But even after a successful product discovery phase, you may struggle to make the right thing in the right way if your product backlog is not up to the job. Garbage in, garbage out – as the saying goes. The following article points at 28 of the most common product backlog anti-patterns – including the product backlog refinement process – that limit your Scrum team’s success.

Product Backlog Anti-Patterns — Age-of-Product.com

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 30,000-plus other subscribers.

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

Hands-on Agile #33: Adapt How You Lead for Agile Success—Johanna Rothman — August 10, 2021

📅 Join us on August 10, 2021: Hands-on Agile #33: Adapt How You Lead for Agile Success—Johanna Rothman.

Update 2019-03-27: The Replay of the Webinar Product Backlog Anti-Patterns Is on Youtube Available

The video of the webinar is now on Youtube available—click twice:

Scrum Product Backlog Anti-Patterns (Hands-on Agile Webinar #3)

Note: If the browser will not start the video automatically, click here to watch the replay of the webinar product backlog anti-patterns directly on Youtube.

Upcoming Scrum and Liberating Stuctures training classes and workshops — Berlin Product People GmbH

The Product Backlog Refinement According to the Scrum Guide

First of all, let’s have a look at the current issue of the Scrum Guide on the product backlog refinement:

“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection during Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above-described refining activities.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.”

Source & Copyright: ©2016 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible here and also described in summary form.

Cannot see the form?
Please click here

A Typical Product Backlog Refinement Process

Based on the Scrum Guide, a typical process looks as follows:

  1. The product owner prioritizes the backlog in advance, so it reflects the best possible use of the development team’s resources:
    • The product owner creates and pre-populates the two upcoming sprints with user stories, using the team’s project management software (or a spreadsheet or any other organizational tool the team applies): Scrum Product Backlog Anti-Patterns by Hands-on Agile

    • The product owner maintains this pattern continuously.
    • The product owner also adds new user stories that he or she may have identified since the previous refinement session.

  2. The product owner and the development team are jointly working on user stories:
    • The product owner provides the answer to the ‘why’ question (business purpose),
    • The team answers the ‘how’ question (technical implementation),
    • And both collaborate on the ‘what’ question: what scope is necessary to achieve the desired purpose?

  3. The whole team agrees to time-box discussions. A typical time-box per user story would be around five minutes on average per cycle.
  4. The product owner provides the acceptance criteria to user stories.
  5. The development team defines what is required to consider a user story to be ready for becoming a sprint backlog item.
  6. The product owner clarifies questions of the team or invites subject matter experts to refinement sessions who can answer the team’s questions.
  7. Consecutive refinement cycles last until each user story meets the definition of ready, or is no longer pursued.
  8. Lastly, the team may estimate the available user stories that meet the “definition of ready” criteria. The product owner can now choose from those user stories to become part of an upcoming sprint.

Common Product Backlog Anti-Patterns

Despite being a 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 Product Backlog Anti-Patterns

  1. Prioritization by proxy: A single stakeholder or a committee of stakeholder prioritizes the product backlog. (The strength of Scrum is building on the strong 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 the priority. Take away that empowerment, and Scrum turns into a pretty robust waterfall 2.0 process.)

  2. 100% in advance: The scrum team creates a product backlog covering the complete project or product upfront because the scope of the release is limited. (Question: how can you be sure to know today what to deliver in six months from now?)

  3. Over-sized: The product backlog contains more items than the scrum team can deliver within three to four sprints. (This way the product owner creates waste by hoarding issues that might never materialize.)

  4. Outdated issues: The product backlog contains items that haven’t been touched for six to eight weeks or more. (That is typically the length of two 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.)

  5. Everything is estimated: All user stories of the product backlog are detailed and estimated. (That is too much upfront work and bears the risk of misallocating the scrum team’s time.)

  6. Component-based items: The product backlog items are sliced horizontally based on components instead of vertically based on end-to-end features. (This may be either caused by your organizational structure. Then move to cross-functional teams to improve the team’s ability to deliver. Otherwise, the team – and the product owner – need a workshop on writing user stories.)

  7. Missing acceptance criteria: There are user stories in the product backlog without acceptance criteria. (It is not necessary to have acceptance criteria at the beginning of the refinement cycle although they would make the task much easier. In the end, however, all user stories need to meet the definition of ready standard, and acceptance criteria are a part of that definition.)

  8. No more than a title: The product backlog contains user stories that comprise of little more than a title. (See above.)

  9. Issues too detailed: There are user stories with an extensive list of acceptance criteria. (This is the other extreme: the product owner covers each edge case without negotiating with the team. Typically, three to five acceptance criteria are more than sufficient.)

  10. Neither themes nor epics: The product backlog is not structured by themes or epics. (This makes it hard to align individual items with the “big picture” of the organization. The product backlog is not supposed to be an assortment of isolated tasks or a large to-do-list.)

  11. No research: The product backlog contains few to no spikes. (This often correlates with a team that is spending too much time on discussing prospective problems, instead of researching them with a spike as a part of an iterative user story creation process.)

Hands-on Agile: Join 9,000 peers and download the free ‘38+6-Scrum-Master Interview Questions’ ebook

Product Backlog Anti-Patterns at Portfolio and Product Roadmap Level

  1. Roadmap? The product backlog is not reflecting the roadmap. (The product backlog is supposed to be detailed only for the first two or three sprints. Beyond that point, the product backlog should rather focus on themes and epics from the product roadmap. If those are not available, the product backlog is likely to granular.)

  2. Annual roadmaps: The organization’s portfolio plan, as well as the release plan or product roadmap, are created once a year in advance. (If the product backlog stays aligned to these plans, it introduces waterfall planning through the backdoor. Agile planning is always “continuous”. At the portfolio level, the plan needs to be revised be least every three months.)

  3. Roadmaps kept secret: The portfolio planning and the release plan or product roadmap are not visible to everybody. (If you do not know where you are going any road will get you there. This information is crucial for any scrum team and needs to be available to everybody at any time. )

  4. China in your hands: The portfolio planning and the release plan or the product roadmap are not considered achievable and believable. (If this is reflected in the product backlog, working on user stories will probably be a waste.)

Product Backlog Anti-Patterns of the Product Owner

  1. Storage for ideas: The product owner is using the product backlog as a repository of ideas and requirements. (This practice is clogging the product backlog, may lead to cognitive overload and makes alignment with the ‘big picture’ at portfolio management and roadmap planning level very tough.)

  2. Part-time PO: The product owner is not working daily on the product backlog. (The product backlog needs to represent at any given time the best use of the development team’s resources. Updating it once a week before the next refinement session does not suffice to meet this requirement.)

  3. Copy & paste PO: The product owner creates user stories 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: user story creation is a team exercise.)

  4. Dominant PO: The product owner creates user stories by providing not just the ‘why’ but also the ‘how’, and the ‘what’. (The team answers the ‘how’ question – the technical implementation –, and both the team and the PO collaborate on the ‘what’ question: what scope is necessary to achieve the desired purpose.)

  5. INVEST? The product owner is not applying the INVEST principle by Bill Wake to user stories.

  6. Issues too detailed: The product owner invests too much time upfront in user stories making them too detailed. (If a user story looks complete, the team members might not see the necessity to get involved in further refinement. This way a “fat” user story reduces the engagement level of the team, 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.)

  7. What team? The product owner is not involving the entire scrum team in the refinement process and instead is relying on just the “lead engineer” (or any other member of the team independently of the others).

  8. ‘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 a communication gateway is a risk to the Scrum team’s success.)

Product Backlog Anti-Patterns of the Development Team

  1. Submissive team: The development team submissively follows the demands of the product owner. (Challenging the product owner whether his or her selection of issues is the best use of the development team’s time is the noblest obligation of every team member: why shall we do this?)

  2. What technical debt? The development team is not demanding adequate resources to tackle technical debt and bugs. (The rule of thumb is that 25% of resources are allocated every sprint to fixings bugs and refactor the codebase.)

  3. No slack: The development team is not demanding 20% slack time from the product owner. (This is overlapping with the sprint planning and the team’s forecast. However, it cannot be addressed early enough. If a team’s capacity is always utilized at 100 %, its performance will decrease over time. Everyone will focus on getting his or her tasks done. There will be less time to support teammates or to pair. Small issues will no longer be addressed immediately. And ultimately, the ‘I am busy’ attitude will reduce the generation of a shared understanding among all team members why they do what they are doing.)28 Product Backlog Anti-Patterns: The importance of slack time during capacity planning

Product Backlog Anti-Patterns of the Scrum Team

  1. No time for refinement: The team does not have enough refinement sessions, resulting in a low-quality backlog. (The Scrum Guide advises spending up to 10% of the Scrum team’s time on the product backlog refinement. Which is a sound business decision: Nothing is more expensive than a feature that is not delivering any value.)

  2. Too much refinement: The team has too many refinement sessions, resulting in a too detailed backlog. (Too much refinement isn’t healthy either.)

  3. No DoR: The scrum team has not created a ‘definition of ready’ that product backlog items need to match before becoming selectable for a sprint. (A simple checklist like the ‘definition of ready’ can significantly improve the scrum team’s work. It will increase the quality of both the resulting user stories as well as the general way of working as a team.)


Even in the case, you have successfully identified what to build next, your product backlog, as well as its refinement process, will likely provide room for improvement. Just take it to the team and address possible product backlog anti-patterns.

What product backlog anti-patterns are missing? Please share with us in the comments.

✋ Do Not Miss Out: Join the 3,100-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

Join the Hands-on Agile Slack Group

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

Related Posts

16 Stand-up Anti-Patterns Threatening Your Transition to Scrum

Scrum: 19 Sprint Planning Anti-Patterns.

Why Engineers Despise Agile

📅 Training & Event Schedule

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

DateClass and LanguageCityPrice
🖥 💯 🇬🇧 August 10, 2021GUARANTEED: Hands-on Agile #33: Adapt How You Lead for Agile Success—Johanna Rothman (English)Live Virtual MeetupFREE
🖥 💯 🇩🇪 August 17-20, 2021GUARANTEED: Professional Scrum Master Training (PSM I; German; Live Virtual Class)Live Virtual Class €1.199 incl. 19% VAT
🖥 💯 🇬🇧 August 24-27, 2021GUARANTEED: Advanced Professional Scrum Master Online Training w/ PSM II CertificateLive Virtual Class €1.199 incl. 19% VAT
🖥 💯 🇩🇪 Aug 31-Sept 3, 2021GUARANTEED: Professional Agile Leadership Essentials Training (PAL-E; German; Live Virtual Class)Live Virtual Class €1.199 incl. 19% VAT
🖥 💯 🇩🇪 September 21-24, 2021GUARANTEED: Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class)Live Virtual Class €1.199 incl. 19% VAT
🖥 🇩🇪 Sept 28 – Oct 1, 2021Advanced Professional Scrum Master Online Training (PSM II; German; Live Virtual Class)Live Virtual Class €1.199 incl. 19% VAT
🖥 🇩🇪 October 12-15, 2021Professional Scrum Master Training (PSM I; German; Live Virtual Class)Live Virtual Class €1.199 incl. 19% VAT
🖥 🇬🇧 October 19-22, 2021Professional Scrum Master Training (PSM I; English; Live Virtual Class)Live Virtual Class €1.199 incl. 19% VAT
🖥 🇬🇧 October 26-29, 2021Professional Scrum Product Owner Training (PSPO I; English; Live Virtual Class)Live Virtual Class €1.199 incl. 19% VAT

See all upcoming classes here.

Professional Scrum Training by PST Stefan Wolpers, Berlin  Product People

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.

4 thoughts on “28 Product Backlog and Refinement Anti-Patterns”

  1. @Guido Graver – as long as DoR does not become a very strict sprint back-log bouncer, DoR is a very good thing to have. You just need to keep your whole team aligned on that 😉 This is an example of DoR of one of teams I’m working with:
    – Story must be written as a user story (i.e. “As a I want so that ”) hence it has some justification/background for the team to understand, also references to Confluence are provided for the team if there is any available;
    – Story has acceptance criteria provided by Product Owner, which are understood by the team;
    – If story is too complex it should be split. Splitting is done during back-log refinement session by Product Owner and dev. team;
    – Story is ready for development if it is estimated by dev. team except Production issues and cases, when UAT testing is impeded;
    – Production issues or UAT issues with attached screenshots and steps on how to reproduce and logged on JIRA, would help us a lot.

  2. Is a DoR not part of a anti pattern? A common understanding of how much details a pbi must have is good, but a DoR is often used as a gatekeeper. A pbi is a communication tool – as long as it’s clear, then it’s fine.

  3. Thanks. Great advice. I’d like to add one more: Your only option for Backlog Items are user stories. Sometimes user stories don’t fit the requirements. The Scrum Guide talks about PBIs not user stories, yet some people think you have to do user stories if you’re doing Scrum. This may lead to cramped, forced and often tautological user stories, just for the sake of writing stories. It’s up to the team to figure out what suits them best in each case.

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.