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.
I came across your blog on Technorati. Nice site layout. I will stop by and read more soon.
Mike Harmon
User stories allow the developers to defer decision making on the finer details. Developing things incrementally helps the user see what is being built and can ask for what they need rather than what they think they need. When writing a huge specification or running exhaustive workshops, we easily forget that the users/customers dont always know what they want. By deferring the decisions on such requirements, we are freeing up the users to focus on getting business value rather than completing a specification
Thanks for responding and for the good information, Prashant. By the way, I’ve subscribed to your feed and look forward to more good information from you on agile analysis.
Thanks, Mike. I’ll look forward to hearing from you more in the future. I checked out your blog, too. Lots of good stuff on accounting there.
Any methodology that can help arrive at better requirements should be a tool in the BA arsenal, but I get a little leary when a practice such as requirements elicitation cannot stand on it’s own and requires the broader development methodology to be successful. So if the only way user stories works is in the context of the broader Agile practices, I’m leary.
I hear you, Bill. What I liked about Cohn’s approach is the simple format of user + goal + value. This is certainly arguable, but to me it seems like a more readable format from a user or business stakeholder’s perspective than a page of use case bubbles or “user shall be able to” statements.
With one of my most recent projects I brought a small list of some of the more obvious stories to an elicitation session. I used it to describe to the interviewee what I was looking for in terms of user requirements, and it seemed to work well enough. We were able to identify several more scenarios or stories using that format.
That said, after I finished the elicitation session I just took those stories and transferred them to use case format anyway.
My takeaway after the trial run is this – If I don’t continue to use the story format, I know that I’ll at least continue to emphasize the statement of value with each requirement more than I have in the past. Requiring the statement of value seemed to keep my subject thinking in terms of the value-add instead of just rattling off neat-to-have features.
Now, we have a somewhat iterative approach to development in my shop, but not agile by even by the loosest of definitions. That said, I suppose these stories hold up well enough as an elicitation tool in any methodology – even if not used in alignment with the intent of the agile purist.
Like you said, bottom line is it’s just another tool in my toolbox.