Stefan Wolpers February 9, 2021 TL; DR: Product Owner Anti-Patterns from Job Ads
Garbage in, garbage out: No matter whether your team chose Scrum for the right purpose—solving complex, adaptive problems. No matter whether your Scrum Team’s product quality is top-notch or whether your teammates embrace self-management to the fullest. If your Product Backlog is not up to the job, all of these accomplishments will account for little, as your team will provide less value to its customers than possible. Here is where the forensic Product Backlog analysis steps in, a light-weight, simple practice to help Product Owners and Scrum Masters unearth anti-patterns that led to your low-value Product Backlog.
Learn more on how a piece of paper and a pencil can turn around the perception of your Scrum Team among stakeholders and customers.
Product Backlog Analysis: From Oversized to Waterfall Planning in Disguise
What does “forensic” mean in the context of Product Backlog management? I borrowed the term from the incident analysis: “Forensic analysis refers to a detailed investigation for detecting and documenting the course, reasons, culprits, and consequences of a security incident or violation of rules of the organization or state laws.” (Source: What is Forensic Analysis?)
Last week, Scrum.org invited me to a webinar to explain this approach to the Scrum community. The webinar was designed to show:
- Why an actionable Product Backlog is essential for your Scrum Team’s success,
- How to spot and remedy issues that prevent your Product Backlog from becoming actionable,
- How you can defend your Product Backlog from falling back into the “old ways.”
On my top-ten list for issues suitable for Product Backlog analysis, the following five Product Backlog anti-patterns occupy the positions ten to six:
The Oversized Product Backlog
Symptom: The Product Backlog is massive as it contains hundreds, maybe even thousands, of Product Backlog items.
Problems: 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 oversized Product Backlog may impede the critical communication with them as a consequence.
Solution: Go for a Product Backlog that holds items for three to six Sprints worth of work. Just count the team’s throughput and do the math. Then remove the excess Product Backlog items.
A Random Assortment of Stuff
Symptom: As a consequence of being oversized, the Product Backlog contains information items of all kinds, from regular Product Backlog items to ideas in various stages to notes and even documents somehow related to the project.
Problems: This Product Backlog anti-pattern is diminishing the overall value of the work the team is investing into Product Backlog refinement. It makes it harder to identify the signal in the noise; it may frustrate stakeholders to access and work with the Product Backlog. Generally, the (poor) state of the Product Backlog will be reflected in the outcome of the Scrum team’s work.
Solution: During the Product Backlog analysis, watch out and list “stuff” of questionable benefit. Engage the team in a further inspection of the items in question. Remove all “stuff” in the process that did not survive the inspection. Consider creating different areas for product ideas than the Product Backlog or establish a process that feeds the experimentation funnel. Also, check who is making the “stuff” and reach out to those to offer support by amending the team’s working agreement. (Note: I am not generally advocating creating a Definition of Ready.)
Outdated Product Backlog Items
Symptom: The Product Backlog analysis reveals Product Backlog items that haven’t been discussed or changed for months.
Problems: What is the purpose of preserving work items that do not seem valuable enough to build them? Keeping them is just clogging the Product Backlog, thus creating noise obfuscating the signal, and hence is wasteful.
Solution: Make a list of the Product Backlog items older than three months and triage them for value. Start refining those items that are still valuable and delete the rest. Regarding the latter part of the recipe, you will typically encounter two objections: (1) We cannot delete just them; those are part of our documentation. This points to both the loss aversion and procedural misuse of the Product Backlog artifact. (2) We put in a lot of work into these Product Backlog items, and we might need them in the future. Well, there is no hoarding in Scrum and embrace the mental model of sunk cost to allocate your team’s time best.
From Requirement Document to Product Backlog Items
Symptom: Product Backlog items look like they have been created by copying and pasting text from requirement documents.
Problems: A Product Backlog item is generally a token for discussion. This way, everyone on the team is on the same page of the why, the what, and the how of creating value for customers. Copying & pasting eliminate this crucial step in team communication; Developers may conclude that refinement is no longer necessary, as the Product Backlog item looks “ready.”
Solution: Watch out for copy & paste items during the Product Backlog analysis that lack documented interaction and take them to the team for further inspection. (Note, though, that some (technical) Product Backlog items may not need collaborative refinement; for example, maintenance of installed software.)
MS Project in Disguise
Symptom: The Product Backlog is fully formed upfront at the beginning of the project.
Problems: A Product Backlog is not a [software management tool of your choice]-based requirement document; it is about co-creation, discussion, and creating a shared understanding among all participants. However, building the Product Backlog upfront feels good; it feeds our bias for action and provides a sense of “being in control.” (Which, in a complex environment, is an illusion.) Furthermore, loss aversion and the sunk cost fallacy will make adapting to change over following a plan—the existing Product Backlog—more challenging in the long run.
Solution: Watch out for batch creation of Product Backlog items in a short period at the beginning or during the project. Take the list to the team for further inspection and adaptation.
Conclusion — Forensic Product Backlog Analysis
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.
Business & Finance Articles on Business 2 Community
(23)
