I must admit that I am not as knowledgeable as I’d like to be when it comes to some of the agile methods. To remedy this, I’ve been doing some research to learn more about user stores and to determine how they are different from use cases and from traditional requirements.
Here are some of my recent findings of interest that I wanted to share in case others of you may be in the same boat.
Martin Fowler specifically addresses the question, “What is the difference between UseCases and XP’s stories?“:
Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories… break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP’s release planning process. Because these uses of requirements are different, heuristics for good use cases and stories will differ.
Mike Cohn, whom I’ve cited before on the topic of user stories, provides insight on a format for articulating user stories that he has found to work well.
I advocate writing user stories in the form of “As a <type of user>, I want <some goal> so that <some reason>.”
For example, “As a corporate finance user, I want to know yearly how much in taxes are due to the state treasury so that the company can comply with state tax regulations (and avoid penalties for non-compliance).”
I think this format could be just as beneficial in a non-XP environment as a mechanism for requirements elicitation. In fact, I’m going to use the spreadsheet form of which he provides a sample for use in one of my new projects. I plan to ask my stakeholders to put themselves in the place of the user (in at least one case, the stakeholder will actually be one of the users) and let them state, from a first-person perspective, what they need to be able to do, and the value of being able to do it.
Too often as I’ve written traditional SRS documents I’ve either been asked or wondered to myself what was the value of a given requirement or set of requirements. With this format, we’d include a statement of business value with each user requirement. Good stuff.
For your reference, and contrasts them with traditional requirements.
In summary, here is what I’ve gathered so far based from my readings on user stories (much of this is derived from ExtremeProgramming.org’s useful description of user stories) :
User stories are primarily used to estimate development time, as opposed to use cases which focus on how users (actors) interact with a system.
User stories focus on user needs and are technology/implementation detail agnostic.
User stories become acceptance test scenarios.
User stories are typically written on cards and not diagrammed using the UML as are use cases.
User stories are an alternative to the traditional SRS document full of “shalls”. When it comes to detailed functional, system and quality requirements, those are worked out between developers and the customer.
User stories are most often identified with the XP (extreme programming) approach to release planning and development, which is a form of agile development.
I am a student as much as a practitioner of requirements analysis, and am always open to new information in tips. If you have any additional information or personal feedback on user stories or extreme programming or other agile methods, then please share. I’m always interested in learning more.
Comments