Chapter 5 of  Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller addresses the product backlog. The authors start this chapter with a great story about the age of product backlog items (PBI). PBI, unlike fine wines, rarely ages well. In many circumstances, backlogs grow to resemble overgrown shrubs with parts being old and gnarly and some parts fresh and vibrant. Product backlog problems are scenarios many agile practitioners recognize. While the idea of a backlog has been popularized by Scrum and other agile frameworks, backlogs have existed from time immemorial. To-do lists are a form of a backlog that existed before agile (a quick history) – back in the olden days of telephone book requirements documents that no one but lawyers read. I have been cleaning out my attic and have discovered old to-do lists. I personally trim my to-do list/product backlog once a quarter.  I throw almost everything on my to-do list away and start over. I have offered that advice to product owners for years to help them keep their backlog from becoming an equal to an elephant’s graveyard – someplace where ideas go to die. Whether the backlog gets trimmed quarterly or on some other cadence doesn’t matter, the goal is to ensure that the items on the backlog are evergreen.

While I have seen all the scenarios in this chapter, several of the antipatterns resonate with me. The one chronic problem that Todd and Ryan tackle is the “one product, many backlogs” scenario. There are many reasons why most agile practitioners rationalize this scenario as a solution to problems they would rather not address. This is never a good idea. One of the causes of the “one product, many backlogs” scenario is a failure to identify value streams and products. I can not count the number of times I have seen organizations decide that they will treat an application like a product. If every application is a product, almost every feature change will need involvement from many products. Coordinating across many backlogs to bring a single feature to market screams “failure to identify products,” and will make it impossible to have a single well-formed product backlog.

Another antipattern is the need to involve everyone in refinement (and other events). This also resonates with me. One of the current dysfunctions in many businesses is the idea that everyone has to be involved in every decision, every time, and in every circumstance. Once upon a time, there was a term that was used for scenarios where teams spend tons and tons of time doing analysis and never start building the project: analysis paralysis. Today, instead of classic analysis paralysis, meeting or consensus paralysis occurs. Not everyone needs to be in every meeting. Using refinement as an example, one common approach to this problem is to adopt the “three-diverse humans” pattern (formerly known as the Three Amigos). Organize meetings so that people can come and go (vote with their feet) with impunity if they do not need to take part. For meetings that are data dumps, record the meeting and allow people to consume them asynchronously (coupled with a chat channel to deal with Q&A and comments). There are all sorts of mechanisms you can use to break the everyone, every-meeting phenomenon. Stopping meeting paralysis is most critical for refinement because you should only be refining just enough of the backlog so that product can flow continuously through the team. Having the wrong number of people will slow everything down.

In chapter 4 we discussed that the product owner’s role was difficult; part of the difficulty is that the role is responsible for that product backlog. What it doesn’t mean is that the product owner is the only person who can add to work to the product backlog. When this occurs a bottleneck will form. I have seen teams and technical leaders create an under-the-table version of the backlog for things they want to add to the backlog. This will destroy the product owner’s authority or generate inter-team warfare.  The product owner is the person to prioritize work, they are the SINGLE voice on the order in which work gets done.

This chapter reinforces that a team and product owner are only as good as the backlog they are working from. 

If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems 

This Week’s Installment 

Week 1: Re-read Logistics and Front Matter – https://bit.ly/3mgz9P6 

Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad – https://bit.ly/37w4Dv9 

Week 3: Breaking Bad Scrum with a Value-Driven Approach – http://bit.ly/3stGc9Q 

Week 4: The Product Owner – https://bit.ly/3qpKvSn