Dark Scrum: The Case Against the Backlog

We’ve spoken often before about the backlog. Let’s get down and dirty today.

Here’s the most recent backlog article, which tried to be more or less fair and balanced. Let’s bear down a bit.

I think the evolving theme in these “case against” articles is that the world system that Scrum, and all of Agile, and all of us, are embedded in, doesn’t work quite the way our approach seems to think. Mind you, if people would just do what we say, everything might work out just fine … although in the case of the backlog, I would still have my doubts. But people do what they think they should do, based on what they’ve experienced and on what they hear or think they heard. And the backlog, in the hands of those people, is not such a good idea.

In the ecology article, I make the point that when the seeds of Scrum or Agile ideas fall onto the wrong soil, bad things happen. And I’m saying that we need to be aware of this, and to take more responsibility for dealing with those issues than we have in the past.

I could be wrong. You can make a case that if people would do as we suggest, emphatically including think and inspect and adapt, they’d probably do OK, and the people who are misusing these ideas aren’t doing as we suggest, are adopting only part of what we said, are adopting it wrongly, and apparently are staring right at the fake tunnel painted on the wall as they drive right into it. It’s just not our concern. Well, I think it is our concern and I’m calling on people to be a bit more cognizant of what happens when we release these ideas into ecologies that are not really ready for them.

The backlog. We were going to talk about the backlog. Let me put it out there: the idea of the backlog is fundamentally broken. Here’s that paragraph from the Scrum Guide again:

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.

“… all features … that constitute the changes to be made to the product in future releases.” All. Each one with an estimate, priority order, and value. All.

Once you’ve said this, all the softening you might do, saying well it changes all the time and well it belongs to the Product Owner and she can change it as needed and anyway it could be just a list of three very high level statements with a wild-assed guess as to the estimate and value and stand down little fella Scrum didn’t say you have to get all up tight about the details Scrum is just as happy and in fact even more happy if your list just has one item on it in every Sprint and a bunch of done stuff off to the side that you did in previous Sprints and no really you can be just as free and dynamic and just as team oriented and self-organizing and all butterflies and buttercups as you want.

You can say that. But you’ve already said “all features [all] changes [all] future releases”. After that, right there in the Scrum Guide, you can back away all you want, the traditional software world hears this and says “Voila! That’s where our requirements document goes¹!”

It’s not that this isn’t ideal, or that it’s subject to well a bit of a misunderstanding really. It is fundamentally wrong! The real philosophy of Agile is customer and developers working together, with customers either being the rest of the company, or represented by the company, in the form of the Product Owner. The Product Owner and the Dev Team are supposed to work together, to self-organize, with the PO responsible for getting the best possible value from the team, by the deadline (there is always a deadline), by choosing the most important things to work on, and working with the whole Scrum team to set Sprint Goals that deliver the most value possible from the expenditures on the team.

You can’t do that from a Jira full of all the requirements in the world. The right solution might not include any of the requirements shown in a typical Jira list or requirements document. The right solution would discover what the real problem is, and solve it in some sensible way.

Read my article on estimation in prag-prog, noting this paragraph and what’s around it:

The C3 Payroll, held up as one of the original successes—and original failures—of Agile, would very likely have been more successful had it not assumed that the job was to predict when it would all be done, or even track and project when it would be done. The job was to convene a team to solve the problems of the Payroll organization, and when the return on that investment declined, to move on. More would surely have been accomplished, and quite likely more of it would be still running today.

This is the fundamental error that the backlog invites: focus on the list of things you think you need to do, instead of on the real problems you have and the solutions thereto. The C3 team was very bright, very expert in the subject matter, and had excellent coaching. (I was also coaching but I hope I didn’t do much harm.) They could, if asked, have created elegant and long-lasting solutions to the important problems of payroll. They weren’t asked. We all thought our job was to tick through the list.

There it is in black and white: all the changes needed for [all] future releases.

A really good Agile method, if there were one, would allow the backlog as one option, rarely to be used, in the incredibly rare situation where you have such a simple situation that you know in advance exactly what needs to be done. That is, to be used, well, never.

One way we could improve the Agile world, the Scrum Ecology, would be to deprecate the backlog all the way down to “Hey, here’s an idea for pretty much never”.

I only wish I had seen that decades ago, the first time it was mentioned to me. Anyway, there it is. Delenda est backlogus, or something like that.