Agile approaches have few proposed specific rules or techniques that have become de facto standards. One of these technique is to use the “as a <type of user>, I want to <do something>, so that <reason>” format to define requirements as user stories. In this blog post, Jim Bird discusses the idea that this user stories format is not the best way to manage requirements.
Jim Bird starts by saying that the user stories format is too short to manage requirement and is merely used for planning purposes. As he quote it: “They’re not requirements. They’re not use cases. They’re not even narratives. They’re much simpler than that.” It is true that some requirements are complex rules and need more space than two lines on an index card to be defined.
His second issue is that the format is a constraint. Even if it is based on a good idea, people have difficulties to express everything in this format. Sometimes the requirement will be twisted to meet the format. You end up with user stories that have a good syntax but a wrong meaning.
Another problem is that this format is focused on delivering value to the customer, but as Jim Bird wrote it “Focusing exclusively on delivering Customer Value leaves little room for non-functional requirements and constraints, which are critically important in building any real system, and de-emphasizes important design problems and technical work that developer teams need to do in order to deliver a high-quality system and to minimize technical risks. ”
I think that the conclusion of the post brings common sense value: “Capture requirements in whatever format works best. Keep requirements as light and clear and natural as possible. If you have important technical requirements that need to be worked on, write them down and don’t worry about trying to warp them into some kind of arbitrary customer stories because you’ve been told that’s what you have to do in order to be Agile.”
Read the complete blog post on http://swreflections.blogspot.ca/2013/12/stop-telling-stories.html
The post contains also a lot of valuable pointers to other sources sources of thinking and knowledge about user stories and requirements.