views:

1364

answers:

5

Are use cases just multiple user stories??

What are the benefits of using user stories over use cases.. and vice-versa... When to use one over other... Does all agile methodologies uses user stories??

+7  A: 

When it comes down to it "agile" is just a label, and people disagree over exactly what it means. Similarly people call very different things "use cases."

In my experience the primary difference between the two is that a user story is focused on the user, and is usually shorter and less formal - ideally, it should easily fit on a postcard. It probably doesn't give details of error handling etc.

Use cases can be much more formal (although some people write them informally too) - they focus on every interaction with the system, and may well go into more detail about several different systems/actors/etc within the same use case.

That's just my experience though - chances are everyone will have used these tools in different ways. I wouldn't get too hung up about labels - just use what works for your project.

Jon Skeet
People mostly disagree because they don't know enough about agile philosophy.
Robert Koritnik
+1  A: 

You can think of a usecase as a user story, but not the other way around. A usecase will cover multiple "endings" to the story, special requirements (e.g. form fields must be entered in format xyz, and show error message 123 if the user enters a field in the wrong format). Also, a usecase can include additional references to external documents, such as security guidelines.

Elie
+1  A: 

In one word, no.

Use Cases are typically detailed specifications laying out how some particular piece of functionality is going to work, or how a specific user is going to utilize the system. It typically is in the voice of a specific user (or Actor) and is fairly self-contained.

A user story on the other hand is "an invitation for discussion". It is typically one or two sentences. Here is one good resource for that. And Mike Cohn's User Stories Applied is well worth it.

The typical syntax is "As a I need to achieve ", or "To achieve as a I need " which drives home the value of the story.

User stories are not meant to be stand-alone, but meant to invite discussion of the story between the developer and the customer (or customer proxy).

Cory Foy
+6  A: 

Actually, the original use cases (see Jacobson's OOSE) were pretty lightweight, much as user stories are now. Over time, they evolved until a common format for "use cases" now is a complicated document with inputs, outputs, inheritance, uses relationships, pseudocode, etc. Programmers, in general, try to convert everything into programming.

In any case, the attempt to defined what distinguishes a "use case" from a "user story" fro a "scenario" is pretty futile, as it's hard to find two authorities who agree.\

Personally, I find the pattern "[Actor] [verbs] [noun] to get [business value]" helpful. If it gets over about a paragraph of text, it may be too big.

Charlie Martin
I would emphasize that the "business value" is very important part of it, since it can help with estimation as well as produce acceptance test.
Robert Koritnik
+3  A: 

Use cases aren't compilations of user stories.

User stories are generally much simpler than use cases. I think use cases try to cover absolutely everything to do with the behaviour of some aspect of the system. That is, all behaviours, all error paths and all exception handling.

The recommended template for a user is:

As a (role) I want (something) so that (benefit)

(Thanks Mike Cohn for providing this simple template)

Descriptions of behaviour expressed like this are more agile.

This sort of template lets you describe behaviour using different levels of detail. For example:

  1. for those stories being implemented in a much later sprint, you can describe behaviour in a high level sort of way, e.g. as an ops team member I want to monitor the system remotely so that I can determine system health while on the road.
  2. for those stories being implemented in the next sprint, you can describe behaviour is a slightly more detailed way, e.g. as an ops team member I want to have a dedicated ops only login so that I can check system health.
  3. for those stories being implemented in the current sprint, you can describe behaviour in a highly detailed way, e.g. as an ops team member I want to have a web interface so that I can check current status of the ingest ftp server.

IMHO Use cases are much more carved in stone! And hence can be a problem to update after the initial version.

HTH

cheers,

Rob

Rob Wells