Product Backlog Anti-Patterns Q&A

TL; DR: Product Backlog Anti-Patterns Q&A

A few weeks, Scrum.org hosted a webinar on Product Backlog anti-patterns with me, which left several questions unanswered as we ran out of time. Hence please find following my answers to the additional 18 questions I could not answer during the webinar Product Backlog anti-patterns Q&A session.

Making Your Scrum Work: Product Backlog Anti-Patterns Q&A — Age-of-Product.com

I also included the replay of the webinar at the end of the article.

🗞 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!

📅 🖥 Virtual Agile Camp Berlin 2021 — May 27-29, 2021 — Berlin Product People GmbH

Join us from May 27-29, 2021, for the Virtual Agile Camp Berlin 2021, a live virtual Barcamp using open space technology principles and practices.

Cannot see the form?
Please click here

Your Questions Regarding Product Backlog Anti-Patterns

Please find the following my answers to the additional 18 questions I could not answer during the webinar Product Backlog anti-patterns Q&A session:

Q: “How much time per Sprint should POs spend writing stories for the PB?” A: Writing Product Backlog items should, in most cases, be a joint exercise by the Product Owner and the Developers. As a Product Owner, I would try and minimize my solo-effect in this regard.
Q: “This might be out of context, but we have big questions about UX tasks in the [Product] Backlog. We know UX designers do work ahead of the Sprint, but should those tasks be tracked in Scrum and in the [Product] Backlog?” A: I would take that question to the team: Is it helpful to do so, or is this tracking clogging the Product Backlog by adding more noise, thus obfuscating the signal?
Q: “How do you manage a product when you have 3 Product Owners — each from a different department with different requests?” A: Consolidate the number of Product Owners: one product, one Product Owner, one Product Backlog.
Q: “If an item is added at the last movement, but Developers say the effort required is more than the number of Sprints we have. How to deal with this?” A: Refine the item further until the Developers are confident that they can deliver.
Q: “How do you deal with external dependencies in your [Product] Backlog?” A: Track them, visualize them, be transparent about them—particularly in the Sprint Review when stakeholders learn about the product’s state.
Q: “How to deal with situations when Product Backlog prioritization is impacted by legal constraints (e.g. Brexit)?” A: Legal constraints do not require a different approach or change the nature of the Product Backlog.
Q: “How to create a [Product] Backlog that covers a migration of an “app” to new technology? For example, replacing CMS X with CMX Y, which could take a year or more?” A: What a tempting scenario for upfront planning! Just create the whole Product Backlog in advance as you already know what needs building. However, then you are just practicing WaterScrumfall. My approach in the past has been to keep the Product Backlog short and have the later stage of the migration sketched in a migration roadmap.
Q: “Starting on an older Product Backlog that has fallen into all of these patterns, where would your starting point be to start whipping it into shape?” A: Have an overall Retrospective with the Scrum Team and the stakeholders regarding the team’s previous deliveries, pointing to that the team could improve value delivery to customers with a lean, anti-pattern-free Product Backlog. Remember: The trash bin is—figuratively and literally—your ally.
Q: “How do you see the status of [Product] Backlog items? How many statuses would you recommend to drive from idea to Done?” A: There is no common rule for the number of statuses. It is up to the Developers to decide on how to organize their work. If necessary, support them in becoming more transparent about their work.
Q: “What behaviors do you see in the teams which have these [Product Backlog] anti-patterns?” A: Generally, the Scrum team performs below its potential, thus delivering significantly less value to customers. There are secondary effects, such as a low level of engagement or a high turn-over rate among team members.
Q: “If PO does not define a Product, Release, or Sprint Goal then what can an SM do?” A: Raise the issue at Retrospectives and offer support to overcome the problem? By the way, the Sprint Goal is defined by the Scrum Team, not the Product Owner.
Q: “Can you talk about how to form a Product Goal when you have multiple projects coming up? Should we just keep the Product Backlog to one project at a time?” A: A Scrum Team pursues one Product Goal at a time. If you have to split your attention between several different projects simultaneously, you may want to analyze whether Scrum is the proper practice for this scenario. Maybe, Kanban would be better suited to meet the challenge?
Q: “How do you establish Sprint Goals, or break down a larger product vision, when work may spill over across Sprints and there is not a strict deployments/release for each Sprint?” A: First, address the issue of spill-overs. What are the reasons for those: does the Scrum team fail to refine Product Backlog items properly, or is the application riddled with technical debt? Once the team feels more comfortable, address having regular releases to close the feedback loop with customers as soon as possible.
Q: “If you have experiments and delivery work, do you recommend showing both categories of work on a single Jira board or on separate boards or both?” A: I would favor separate boards. Experiments do not belong to delivery work.
Q: “Is it a good idea to have several [Product] Backlogs for different time frames?” A: My approach in the past has been to keep the Product Backlog short and have the later stage of the product development sketched in a themed product roadmap.
Q: “I do agree that the definition of “Ready” for the PBIs could turn into a stage-gate. But what I found at the same time without one, it is either the PO who does not refine the PBis enough or the developer having each a different opinion of what a “Ready” PBI is and sometimes refusing to take it on during the sprint. What would you advise?” A: Preparing Product Backlog items to the level of “Sprint-ready” is a process, requires deliberate practice and takes time. In the beginning, a “Definition of Ready” may act as training wheels to the Scrum team. However, like in real life, I would advocate getting rid of the training wheels as soon as possible.
Q: “What can you do if you have a Product Owner that will stay no but still has to fold and do the pet project?” A: I would ask: “How can I help?”
Q: “How would you recommend fixing this [Product Backlog] antipattern, or what steps to take, with a team that doesn’t have the capacity to take more work?” A: Lose your output-oriented perspective on your team’s work and make room for this task. Being busy does not equal creating value for customers.

Watch the Webinar Replay Leading to the Product Backlog Anti-Patterns Q&A

You can watch the Scrum.org Webinar that led to the Product Backlog Anti-Patterns Q&A session here:

Watch this video on YouTube

Conclusion — Product Backlog Anti-Patterns Q&A

In my opinion, a forensic Product Backlog analysis is an excellent way for new Product Owners and Scrum Masters to learn about their new Scrum Team’s way of working. You do not need much to delve into the practices, processes, and habits of your teammates and unearth the patterns on how the team is going about its work within the organizational boundaries. All you need is access to the Product Backlog, a pencil, and a piece of paper. Then start gathering the data that will provide you with the information needed to run a Retrospective with your team.

What other Product Backlog anti-patterns have you noticed? Please share your findings with us in the comments.