Chapter 5
The Product Backlog

Ryan gives a lot of keynotes at conferences all around the world and has a series of product backlog-related questions that are fun to ask, especially when there are a lot of product owners in the audience. He starts with a simple question: “How many of you have a product backlog?” The audience chuckles and the majority of people raise a hand in the air.

Next question: “How many of you have a feature, requirement, task, or bug in your product backlog that’s older than three months?” The laughter fades and a serious vibe falls over the room. The majority of hands stay up.

“Alright, how about older than six months?” A few hands drop, but most stay up and people start looking at each other, realizing what’s next.

“Okay, one year? Two years? How about a PBI that’s older than three years?” Normally we stop there, but recently a gentleman kept his hand up until Ryan got to nine years. Honestly, Ryan was stunned and stopped the keynote. He asked the AV folks to bring the lights up and give this guy a mic: Ryan had to hear what had languished for nine years in a backlog.

Turns out the guy was in the financial industry and had a mainframe change to make.

Ryan:

Sir, you’re never going to make that change.

Gentleman:

No, no—we have to make this change.

Ryan:

Really? But it’s been nine years!

A product backlog is everything a Scrum team knows about their product and what they intend to build and deliver at any given time. It’s the roadmap, product vision, and execution plan. Competitors would love to get their hands on it, but only if the Scrum team has built it well.

Many product owners (and Scrum teams, for that matter) are hesitant to treat the product backlog as a living, changing document—which is exactly what it should be. Instead, they tend to think of it as an unchangeable list of things that must be completed—so they never remove uncompleted items, even if those PBIs have been languishing for years. Too many years of 400-page requirements documents and painful change-order processes keep many POs from refining and changing their product backlogs.

As a Scrum master, you’ll spend a lot of time encouraging cuts and edits to product backlog items. Be patient. It isn’t always easy for your product owner to let go of their best-laid plans and clever feature ideas.

In this chapter, we break down the many anti-patterns that ruin product backlogs. We will make sure you know how to support your product owner and create a product backlog that serves your development team and stakeholders well.