Does anyone here have experience with both ways of modelling requirements? Which did you like best and why?
And has anyone tried using both at once?
No responses hey?
Well,
ExpremeProgramming.org has tis to say;
"User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax."
I ask you this - if UNL is so good, why do agile projects find it more useful to go get raw feature descriptions from users?
1. Are user stories only used in Extreme Programming approach and created by users themselves? What If users use the same format for user stories as what BAs use to create user cases?
2. So there is neither BA on a XP project, nor is QA? Who is supposed to do the system design in XP projects? I guess the development lead should be very strong in this case, since he might need to cover some BSA or architect's work.
3. I am also wondering the actual result and experience if anybody here has worked on XP projects?
Thanks for your answers,
- Irene
Hi Irene,
The user stories are not exclusive to XP. They seem to be used on vast majority of the Agile projects with, perhaps, a bit more formalism. In this case they are created by a member of the Agile project team (which could be a business analyst).
Here are a couple more resources:
- Adrian
I have written both use cases and user stories. I would say that I enjoy user stories more, but that was because I was working in a complete agile environment. When I have written Use Cases, they have often been large lists of instructions which were used in a waterfall methodology and were not as fun for me to write. However, I don’t think that in the Use Case environment the User Story would have been successful. SO, I would say that you have to use what works best in the system that you are working in. Documents are really about the audience that will be reading them, and what they need to understand the requirements.
Not every environment is strictly waterfall, or strictly agile, so perhaps a blend would work for you. I would be interested in hearing how it works out for you if you try the blend.
brought to you by enabling practitioners & organizations to achieve their goals using: