The Scrum Backlog is where Features go to die
Thomas Schranz
1727

You don’t understand the Product Backlog, but the Scrum Guide is here to save you.

I was dismayed to read Thomas Schranz’s article, The Scrum Backlog is where Features go to die. It espouses a great many misunderstandings about one of Scrum’s fundamentals, and there were many readers who echoed those misunderstandings. Mr. Schranz seems like an open-minded fellow, so as a Certified Scrum Professional I submit my rebuttal to correct this misinformation.

To begin, it’s important that we use the right terms. There are two backlogs in Scrum and neither of them are called a “Scrum backlog.” It’s the Product Backlog that’s being discussed (and misrepresented).

The Wikipedia mistake everything else hinged upon

Mr. Schranz’s article begins by defining the Product Backlog using Wikipedia, saying it is “a […] list of requirements that […] need to be done in order to successfully deliver a viable product.”

This is dead wrong, and even the cited Wikipedia’s Scrum article no longer contains this erroneous definition. For the real definition, we turn (as we should do regularly as Scrum professionals) to the only source of Scrum truth.

From the Scrum Guide (edited for brevity, emphasis mine):

“A Product Backlog is never complete. As long as a product exists, its Product Backlog also exists. As a product is used and gains value, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing so a Product Backlog is a living artifact.”
A never-ending, ever-growing Product Backlog is not a problem nor an anti-pattern; it is EXACTLY what Scrum prescribes.

Schranz describes such a backlog as “a black hole for focus, time & resources,” “demoralizing,” and “impossible to prioritize.” Let’s address these concerns, and return again to the Scrum Guide:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

1. Is a big backlog a black hole for focus, time & resources?

In Scrum “all events are time-boxed events.” Nothing can be a black hole for resources if you simply follow Scrum and time-box backlog refinement. My Scrum teams usually refine once a week. By time-boxing refinement, you ensure your team isn’t wasting all their time talking about the entire backlog. Under the pressure of the clock, the important stuff rises to the top of the discussion.

2. Is a big backlog demoralizing?

No. Why should it be?

If your Scrum team has read the incredibly short Scrum Guide (and if they haven’t, why the hell not?) they should expect a never-complete backlog.

Everything that is alive is changing. If your product is alive, it has room to improve. Bugs are being found. Users are demanding new features. Stakeholders are brewing up new ways to make money on it. The Product Backlog is where all those items exist. It is the heartbeat of your product, the sign of its life. The life of your product should be anything but demoralizing. Train your Scrum team to embrace this reality.

3. Is it impossible to prioritize?

Yes. There are Product Backlogs you will never completely prioritize, and you should not aim to.

Worrying about the size of your Product Backlog is a complete waste of time.

Let’s say your Product Owner adds 100 new ideas a day to the Product Backlog. That’s a lot!

Let’s say your Scrum team gathers once a week for a mere 1 hour to refine that backlog.

Question: Which of the 500 new items (plus the old ones) will be prioritized in that little 1-hour block?

Answer: who cares?

The Product Owner sets priority. Whether he/she prioritizes based on return on investment or consults a ouija board for priority, it doesn’t matter in the slightest. Now, a Scrum team should operate as a team — the developers should weigh in on prioritization during refinement, especially if the PO has delegated their responsibilities to a spirit from the nether realms. But the developers develop what’s prioritized, end of story.

If you’re a developer on a Scrum team, worry about priority when the time is right: during Product Backlog refinement.

If you’re a Product Owner on a Scrum team, refine the backlog yourself, constantly. “Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.” — The Scrum Guide

Debunking the rest of the misinformation

I’ll just try to touch on the other misinformation found in the original article here.

Need has nothing to do with it.

Now that we know that “need” has nothing to do with the PB, there is no reason to “fiercely protect” it to ensure the backlog only gets “needed” items. Let the PO do their job and add stuff to the backlog. When the time comes to discuss it, “need” is irrelevant. Only priority matters.

What’s next?

“A backlog tells you what’s coming next,” said the original article. Not true.

“The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

According to the Scrum Guide, it is no problem at all for a Product Backlog to contain features that aren’t coming “next,” or even in the next year.

The pain of needlessly limiting your backlog.

After making a poor case for limiting the backlog, Schranz admits that things that don’t go in the backlog do need to go somewhere, and proceeds to suggest a slew of tools you can use to effectively create multiple product backlogs, needlessly complicating the process.

The rule is very simple: you have a development team. If they will do some work on the product, that work goes into the Product Backlog.

  • “Product strategy” items? That doesn’t sound like development work. “Strategy” (whatever that means) doesn’t belong in a list of product features, so yeah put that somewhere else.
  • Defects? Of course that goes into the backlog. You have to prioritize whether you want to fix a bug or add a feature in the next sprint, because the dev team does both. Think of it this way: at the store you need to buy food for meals, and you need buy poison for bugs. Even if you have a separate list for meals and poison, you still have one wallet to spend out of. Prioritize.
  • Support requests from users? If your development team handles these, of course that goes into the backlog. Again, you have 40 dev-hours in a week. How do you decide where to spend them? You prioritize.
  • Inspirations? Obviously not a work item. Blog about it or something.

What Schranz got right

What matters in the End is what actually gets built.”

I’m glad to read this, because at the end of the day working software and human relationships really are what Agile is about.

But don’t mistake a blog post about Scrum for Scrum. Read the Scrum Guide. Follow it.

Scrum’s been around for 30 years. These days, far too many people (even supposed experts) are glossing over its fundamental concepts and skipping straight to describing their own software development philosophies as Scrum. And maybe those patterns are working for them. But if it contradicts the Scrum Guide, it is counterfeit Scrum, and take it from me — you want the tried, true, genuine article.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.