As I hear more and more BAs talking about user stories I feel the need to begin a dialogue on our blog. User stories have been promoted by the iterative and agile software development approaches as a quick way to elicit and document user requirements. Some BAs are being told that user stories are the only requirements that they need. I disagree. Alister Cockburn appropriately writes that user stories “are markers that promise a conversation about what is associated with the phrase on the card.” Cockburn also notes that these are not the only tool used to gather requirements on an agile project and in fact this technique may be a very weak strategy for many types of agile projects (e.g. projects with very large or diverse stakeholders).
User stories are brief descriptions or phrases written on an index card called a story card. They can be a great starting point for analysis because they are easy for users to describe and easy to document. They give an analyst or developer who is new to the business area examples of the type of work that is accomplished by the business. They also can be used to develop initial high level test cases.
The limitations of user stories are easily seen from the strengths above. They are not detailed and only describe a specific business transaction or situation. The number and choice of stories determines how well they, as a group, cover the scope of the business area. They do not formally call out data needs, business rules, or include consistent definitions.
For projects where user stories are dictated as the preferred requirements deliverable the experienced BA will be able to use them to drive down to detailed business and functional requirements which will complete the picture.
Tell us what you think!