July 1, 2016

Product Backlogs: Not Just Stories!

  —What does Scrum require you to put in the Product Backlog?

In "Feature-Based Development: The Lasagne and the Linguini", Bertrand Meyer raises the spectre of multiplicative complexity and the failure of the user story to address this complexity. In Meyer's view, a user story is too simple to manage requirements except for certain types of systems. User stories become unwieldy if there are feature-based interactions to manage.

The Scrum Guide describes the Product Backlog as providing a single list of requirements for a product. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Backlog items have a description, order, estimate and value.

The Product Backlog doesn't require stories explicitly and acknowledge the existence of other types of requirements. Meyer's book goes on to mention that user stories are the preferred method for expressing requirements within Agile methods. It's obvious how Meyer's arrived that this conclusion for XP but how could he possibly include Scrum in his assessment?

A quick look at Scrum Alliance shows that the Product Backlog should be written using user stories might be easy to come by. For example: Product Backlog and Give Life to Your Product Backlog both discuss how to manage user stories in the Product Backlog.  (In the defence of Scrum Alliance, Core Scrum uses language similar to the Scrum Guide to describe the Product Backlog.)

Curiously, Mike Cohn's Scrum Product Backlog perpetuates the notion that the Product Backlog is populated with user stories. Cohn's article references examples from Scrum Alliance. His article on the Advantages of User Stories for Requirements contains arguments in favour of user stories over traditional requirements.

The SCRUM Development Process was presented at OOPSLA 95 by Ken Schwaber. It discusses a control on the Scrum methodology called the Backlog. The Backlog contains:

Backlog: Product functionality requirements that are not adequately addressed by the current product release. Bugs, defects, customer requested enhancements, competitive product functionality, competitive edge functionality, and technology upgrades are backlog items.

If the Scrum Guide and SCRUM Development Process present similar language for the purpose and content of the (Product) Backlog how have user stories become the favoured method for capturing requirements?

In "Agile! The Good, the Hype and the Ugly", Meyers fingers Test First as the culprit. Test First and the notion that tests are a suitable replacement for requirements and specifications.

Curiously, the Scrum Guide is again virtually silent on testing. It states that development teams have a responsibility for testing and that this responsibility requires that each increment be fully tested to ensure that all increments work together. (An Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.)

Likewise, the SCRUM Development Process requires testing during development. It does not require a specific approach to testing.

In all, I agree with Meyer's position on user stories and XP.  He is correct in applying this reasoning to Scrum as well, although I don't agree that the intent of Scrum was for requirements to be managed only with user stories and Test First.

User stories and test first are artifacts applied to the Scrum framework. They are not a requirement of Scrum itself. Their use is imposed upon the framework by the organization implementing Scrum. That's an important difference.