Diagnosing Dysfunction Using the Product Backlog

My first car was a ’79 Oldsmobile Cutlass Supreme, and I think I was the third kid in my family to drive it. My friends and I nicknamed it the “old-mobile,” and like any car that could be considered “numerically challenged,” mine had its issues. Of particular concern was an ongoing radiator leak that could cause the car to overheat. 

I quickly learned to pay close attention to the heat indicator light on the dashboard to help me gauge the car’s daily usefulness. Growing up in Texas, you can imagine how this could be a severe problem during the summer months! However, as long as I kept a close eye on that heat indicator gauge, I could determine if I was okay to continue my journey or if I needed to pull over and add extra antifreeze to the tank. If I ignored that gauge, I risked breaking down and derailing whatever plans I had for the day.

Just like that old car, in Scrum we have our own set of indicator lights and gauges. Our ceremonies and artifacts are built in part to help us recognize potential issues before they become bigger problems. If we pay attention to them, we can successfully navigate our course. If we ignore them, we risk breaking down.

Related: Scrum Anti-Patterns Large Product Backlog

In a recent conversation I had with Kert Peterson, he mentioned that when he consults with a new client the first thing he does is ask to see their product backlog and their definition of done. I’ve since come to realize that these two artifacts can be key to diagnosing the health level of a team.

The definition of done (or lack thereof) can tell you quite a bit about what a team considers important in producing a potentially shippable product increment. The product backlog, however, is revealing in a way I had not previously considered and has become one of the main tools I use in coaching a team.

Looking at the product backlog is like looking at tree rings or a core sample: it provides you with an insight into the partnership between the development team and the product owner. A healthy Scrum team exists in a collaborative environment, so the product backlog should reflect this delicate balance.

Related: The Anatomy of an Excellent Scrum Team

If there are problems with the partnership between business and developers, you’ll likely notice it in the makeup of the product backlog. Like shorter tree rings in times of drought, a product backlog reveals the work that was done to produce it and how the various personalities of the team members work together.

In some cases, you can see that the product owner has isolated himself or herself from the development team, resulting in a very business-friendly product backlog: stories are all customer-focused, and little regard is given for the technical architecture of the project. Input from the team has not been considered or worse, not solicited.

The partnership in this case is one-sided and the team is simply taking orders. They deliver exactly what’s been requested but are never given the chance to address technical debt or to contribute their own ideas.

The opposite can also be true for a product backlog that is too developer-centric. In this case, you will see a product backlog full of technical stories with more acronyms than a government agency. Stories will likely not make any sense to the product owner, who is trusting that the technical experts know what they are doing even though he or she has very little visibility into what they are working on.

There are likely strong personalities on the development team that have crossed the line from deciding how to deliver the product increment to defining what the product increment contains. 

Of course, there are a thousand permutations between the two as well, each with their own story to tell about how the Scrum team is collaborating and discovering the requirements as they make the journey toward producing the product.

If you know what you are looking for, though, you can look through the tree rings of your product backlog and find the signs of issues that are preventing your team from realizing its full potential. The product backlog then becomes an incredible diagnostic tool for coaches and can reveal where their time is most needed on the team.

Related: 7 Skills You Need to Be a Great Product Owner

While that “old-mobile” has likely found its way into a scrap heap by now, the lessons I learned from it are just as valid today as they were in high school. When you have a valid indicator that gives you an early warning that a problem is developing, it’s wise to pay attention to it and take corrective action. It’s far better to spend the extra time addressing your issues now before they grow and derail your plans down the road. 

Brian Milner is a Scrum Alliance Certified Scrum Trainer from Dallas. He has been involved with Software Development for over 20 years and has worked with agile teams for half that time. He can be reached at www.scrum360.com or https://www.linkedin.com/in/brianmilner1/.

Scrum Alliance, the world's premier non-profit Scrum and agile certifying organization, offers a full suite of Scrum and agile certifications and support. Learn more about the training and certifications that work best for you, your team, and your business as it becomes an agile organization.