A recent survey found that 90% of respondents who create software using agile methodologies, express requirements using user stories . 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:
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.
 Wang, Xinyu, et al. “The Role of Requirements Engineering Practices in Agile Development: An Empirical Study.” Requirements Engineering. Springer Berlin Heidelberg, 2014. 195-209.
 Liskin, Olga, et al. “ Why we need a granularity concept for user stories. ” Agile Processes in Software Engineering and Extreme Programming. Springer International Publishing, 2014. 110-125.
 Abrahamsson, Pekka, et al. “Predicting development effort from user stories.” Empirical Software Engineering and Measurement (ESEM), 2011 International Symposium on. IEEE, 2011.