Why writing user stories the right way is not childish

A recent survey found that 90% of respondents who create software using agile methodologies, express requirements using user stories [1]. User stories are simple, great and should look like this:

But frequently, they don’t. Despite the community’s best efforts to define the characteristics of a good user story such as INVEST, every set of user stories we have seen contains serious errors. In fact, running the AQUSA tests on 6 high-quality sets consisting of 429 user stories found that 39% (166!) contain easily preventable errors. These errors are overwhelmingly as straight-forward as this:

“Now wait a minute. Me and my colleagues are not children. These errors are too simple. We clearly get our work done despite them.”

Of course you get the work done, you always do. But here are three good reasons why you should still care:

1. Breaking down the task of developing a system into separate user stories that focus on a single action makes thinking and reasoning about what you are actually expected to deliver amazingly easy. This substantially simplifies your life during initial development, but turns into a life-line when you revisit an older visit.
2. A high quality user story set simplifies conducting more advanced analyses. Research has shown that practitioners are better at estimating the required effort when the user story is smaller[2,3]. Additionally, detecting ambiguity or conflicting user stories requires substantially less energy when your user stories are easily comprehendible.
3. Error-free, uniform user stories are important to consistently convey a professional image towards customers. After all, they are your customer’s most frequent and concrete way to keep up-to date on progress. Those issues you wrote in a rush that disregard all guidelines? A very small, but real, step down in quality in the eyes of your customer.

Much like how the Ruby programming language optimizes for developer happiness, user stories optimize for stakeholder happiness. Personally, I think this benefit alone already increases customer loyalty, developer productivity and software quality.

Convinced? Not convinced? Utrecht University would love to hear your opinion!