This post by Thomas Schranz caught my attention: Why SCRUM Backlogs lead to bad Product Decisions. One finds numerous articles against Scrum on Thomas’ site. I think he misunderstands Scrum fundamentally.
Is my purpose here to defend Scrum? Friends and colleagues will know that I’m not a Scrum salesperson. I see Scrum as a tool, and not as the answer to the ultimate question of life, the universe, and everything. So, why defend it? My purpose in this post is to caution against blaming one’s tools for one’s results, and to suggest that we try to understand a thing before we criticize it. (I don’t claim to be a flawless practitioner of my own advice.)
Scrum as a tool
I’ve had good results using tools when I use a two-step process to select and apply them: (1) Choose a tool that is appropriate to the task, and (2) Use the tool properly.
My observation is that Scrum yields the most value when it is used to support adaptive development. It can be useful with traditional development as well, by helping to keep the work moving along and helping team members maintain tactical focus, but without the feedback loops and frequent adjustments of the adaptive approach we forfeit some of the potential value.
So, to use Scrum effectively the first step is to apply it to adaptive software development. The second step, then, is to understand how Scrum is meant to work and use it accordingly. In Thomas’ business context, adaptive development is the norm. The problem appears to be with the way he thinks Scrum is meant to be used.
(!Scrum) != Scrum
In the title of his piece, Thomas writes Scrum as “SCRUM,” in all capital letters, as if it were an acronym. That relatively minor issue is a clue to the level of understanding we will find as we continue reading. He writes:
In theory a product backlog is a list of requirements that you’ve committed to implement. As simple as that.
Yes, that’s simple. Unfortunately, it isn’t a description of a Scrum product backlog. According to the Scrum Guide:
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.
The key phrase is “might be needed.” No one has “committed” to implement everything in a product backlog. Backlog items are ideas that may be implemented, if the day comes when it makes business sense to do so.
Thomas also writes:
Committing to granular work items way before you even get to implement them doesn’t make much sense anymore.
“Anymore?” When did it ever make sense? Fortunately, Scrum doesn’t call for “commitment” to granular work items “way before” they might be needed. Instead, it calls for continual refinement of the product backlog based on lessons learned and customer feedback, with features pulled at the last responsible moment. From the Scrum Guide:
The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.
One can break this model quite easily. If the backlog is seen as an absolute list of “committed” requirements, then the entire Scrum process becomes useless. This brings us to the point about blaming our tools.
It’s way too tempting to put everything into the backlog that sounds like a great idea which you don’t want to forget about.
Other times adding a feature request to the product backlog is the only way to keep pushy stakeholders happy without actually having to add the feature to the product immediately.
Even in the face of “temptation,” the responsibility falls to us to use our tools appropriately. The issues Thomas described are not caused by Scrum or by product backlogs. The fact his organization did not apply Scrum properly says nothing at all about whether Scrum is a useful tool generally.
Practical alternative
To their credit, Thomas and his team adapted their process to align with their needs. Their solution is a fairly free-form description of ideas to meet customer needs and guide the evolution of the product, maintained in Google Docs. They call it a Product Strategy Roadmap.
It works pretty much like a Scrum product backlog is supposed to work.