I have often experienced that the discussion “should we write user stories or use cases?” arises when a new project are about to start. I have also asked the question myself quite a few times. There is no right or wrong answer to this question, it all depends on the nature of the project and organisation. Personally I like to write both user stories and use cases for the projects that I am involved in.

To be able to understand why and how lets first take a look at the differences between a user story and a use case.

User story

A user story is formulated as one sentence written from the user point of view. It is often written like this: As <an actor> I would like to <action> so that <achievement>. As you can see user stories are short and quite easy to understand, but they leave out a lot of details. User stories are often written by the customer or at least together with the customer.

You can read more about user stories in a previous post: Writing user stories for agile (Scrum) projects and the follow up post Writing user stories for agile (Scrum) projects – revisited

Use case

A use case is much more detailed than a user story. A use case is often formulated with several fields like; name, description, standard flow, alternate flow, preconditions, post condition and so on. It is easy to see that the persons involved in writing use cases needs to know much more details about the project than the persons involved in writing user stories. Due to this the customers often find it hard to write use cases and this part is often left to the team involved in developing the system (in case of a software project).

You can read more about use case in a previous post: Writing use cases for agile (Scrum) projects

Applying user stories and use cases in a project

As I mentioned in the ingress for this post I like to use both user stories and use cases in the projects were I am involved. We start with writing the user stories to describe the functionality for the system. This can be delivered to you by the customer as system requirements. Most of the projects you need to take initiative to write these together with the customer and is typically done during a work shop (or several). When this is done you have a great basis for the project. You have ensured that both you and the customer have the same expectations on what to be developed.

Great! You know what to develop but I do not find the user stories alone detailed enough to accurate estimate how many hours this will take or when you will be able to deliver the system. Now it is time to start detailing the user stories and a good way to do this is to create use cases based on the user stories. This can be done by the development team alone and does not require involving the customer. Small user stories are often detailed into just one use case but often you have larger and more complex user stories resulting in several use cases.

The use cases are mapped to their respective user stories and you can also map them to other system requirements that have not been included in the user stories.

By doing it this way you have ensured that you have covered the functionality required by the customer since you have written the user stories together. You have also ensured (or at least increased the possibility) that estimates and delivery dates can be reached.