Having some experience of both use cases and user stories as a requirements technique I'm having difficulty seeing the advantages of user stories over use cases. Granted, the user story approach allows the business to specify what they want quickly, with the detail being deferred until the sprint planning stage, whereas a use case requires the detail and precision up front, assuming that you are using "fully dressed" use cases. I was wondering if a valid approach would be to start by writing "light" use cases which capture the essential goals of the actors and add these to a product backlog where they can be prioritised (essentially they would be very similar to user stories at this point). During each sprint the team can work collaboratively with the business to produce code, test plans and fully dressed use cases which can also be used as system documentation. This approach of elaborating the light use cases into a set of fully dressed use cases during the sprint would prompt the team to ask the right questions and would ensure that all the necessary detail is driven out during the sprint. Are there any issues with this approach in the Agile world? Why do use cases appear not to be widely used in Agile?

 Agile was developed as a competing product to RUP and with that Use Cases were not used in Agile. RUP and UML were considered documentation and process heavy and Agile was the answer to that. 

Use Cases are for functional requirements and you should do them in iterations so you are right, you start with the actors and use cases and the goals and then develop them out from there. 

Hi Kier. I see your problem. I have used both User Stories and Use Cases. And I think you need something else. There is a method called Task & Support developed by Soren Lauesen. Tasks are very similar to Use Cases. The difference is that you do not have actors and you do not have to specify how you handle specific steps. With Use Cases you have to decide what user does and what system does. WIth Tasks you just write the steps of the process. Tasks are easier to understand by Business people. You still have there a place for catching exception conditions while they show (it is called Variants).

Tasks descriptions were tested by Soren Lausen on waproject for hospital - medical environemnt. He was able to teach writing tasks to doctors with one day training and they had written all the TAsks themsleves. Imagine asking your customers to write Use Cases.

If you have some questions send me email: [email protected]

Regarding User Stories they are good as a warm-up when you do not understand the business. I think user stories shall never be used to document requirements. They shall rather be thrown away after you start understanding business.