What To Use For Agile Projects - Use Cases or User Stories?

User Stories are a key element in Scrum projects and used to capture the high-level requirements for the Product Backlog of requirements.

 

One common misunderstanding is that user stories per definition replace use cases as a concept when developing agile solutions. Another misunderstanding is that if you are using use cases you can’t use agile methodologies for development. Both statements are wrong.

 

Let's first look at the two concepts. User Stories are an element in the agile methodology Scrum, while Use Cases origin from the UML framework for specifying requirements.

 

Similarities

There are some similarities between use cases and user stories.

1. Both concepts involve the users in order to capture the user requirements to be developed.
2. Both concepts are using plain language as the main content in order to enable the users to write or at least understand the produced output.
3. Both concepts are input to the design- and development process

 

Differences

Even though use cases and user stories are comparable there are some distinct differences:

1. Use cases capture more information than user stories. User stories are written stories in native language and often follow this structure: As a [user role], I want to [goal], so I can [reason]. Use cases capture a lot more information for example: Pre-condition, Post-condition, Trigger, Actors involved, Verbal description, sequence of actions etc.
2. User stories are usually shorter – that is by design, refer to difference#1 – than use cases.
3. User stories are slightly easier to create. The fact that user stories are shorter and includes less information justifies the statement that user stories are easier for the users to create. However, judging how much easier it is depends on how complex use cases you intend creating. Use cases can be created with various levels of complexities (See post: How to get use case success).
4. Use cases contain a sequence of actions while user stories are plain unstructured text.
5. Use cases model the behaviour of the system by defining how (usually) a user interacts with the system. User stories don’t model how this interaction should be. 
6. Use cases can be heavily detailed and used for “over-the-fence” projects, while user stories in their short form requires verbal interaction when development starts. Heavy detailed requirements can be useful when capturing very complex requirements or when creating a request for proposal.
7. Use cases are derived from a use case model. User stories are usually not derived from a model. Being derived from a model establishes an overview of the requirements structure.
8. Use cases are primarily used for capturing and documenting requirements, while user stories are primarily used for capturing high-level features and to prioritise work

 

Use cases have been along for many years. It is true, that in the past use cases were usually heavyweight specifications. I have seen 50 pages use case specifications being developed (in some cases that amount of details were needed). Today this is no longer usual. Today use cases are normally found in various levels of detail – from extremely lightweight being just a use case shape with a few sentences of description to heavyweight use cases with exact details of the business rules and requirements. I think the agile methods have influenced the way we use use cases today into a much more agile approach. That is why you can easily use cases for specifying your product backlog. In general think of a use case as containing a user story for each flow in the use case.

  

What is best – use cases or user stories?

In my opinion the best approach is what the development team is most familiar with. If the team favour one of the concepts and you can see it’s working you should not change it.

Saying that use cases or user stories in general are always a better choice is, in my opinion, nonsense.

 

Personally I find it easier to identify use cases from a use case model than to identify user stories. In addition I find it difficult to understand how the selected user stories adds up to be the complete system - looking at a use case model is easier that looking at hundreds of user stories.

 

After all what requirements specification is all about is lowering risk. Lowering the risk that something wrong or incomplete is being developed. How much effort you should put into lowering that risk depends on the impact and the probability that it will happen. What is enough? It depends on the risk assessment – but I think for agile projects a good rule of thumb is that you need enough details to be able to sign-off on a sprint.