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?
Hi Keir,
Many teams embarking on their Agile journeys are finding comfort in techniques used in the past for requirements definition, particularly Use Cases. Use Cases resemble user stories in more detail, and User Stories were developed as a condensed technique to alleviate the lack of WHY in Use Cases and to alleviate too much detail too soon when using an Agile approach.
I believe that User Stories and Acceptance Criteria are the techniques aligned to deliver the benefits of the Agile approach and Use Cases compromise and put the benefits of the Agile approach at risk.
Teams thinking about using Use Cases should strongly consider looking at the methods and evolutions of defining Acceptance Criteria (especially the <given><when><then> model) with many scenarios and levels of detail that evolve as feedback through the iterative cycle and delivering increments of the product as it evolves. Keeping with user stories (Including story maps & epics) along with well defined and evolving acceptance criteria will meet the goal of leveraging the benefits of agile without putting timeline and value at risk.
Pablo.
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 have been working in agile - scrum methodology for the past three years where I have dealt with user stories widely. I think if the user stories are illustrated well with all necessary information and foremost correct coverage through the acceptance criterias to be met before giving a go ahead to the story..user stories work very well for my team and project. If the stories are written with all the information available and sometimes quick sketches(not wireframes exactly) it is of good help to the developers. If the Acceptance criteria written for the story is well documented covering all the requirements it gives a great leverage to the testing team while writing their test cases and hence enhances the chances of finding faults much sooner in the sprint cycle.
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.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: