preload
Jan 22

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.

Follow me on twitter @PerOla

Share & enjoy
You can subscribe to my comments feed to keep track of new comments.

8 Comments to “User stories versus use cases”

  1. Rahul says:

    Its very much clear .Thanks

  2. Dave says:

    There is a key difference between use cases and user stories that goes far beyond formatting and detail levels. The fundamental difference between the two is their purpose.

    Use cases are basically “traditional” requirements. They are an agreed upon contract between the developers and various other interested parties in the project describing what the software will do as accurately as the author can express them (which will always be less than perfectly). They are basically like software legalese and subject to some level of interpretation just like any legalese.

    The agile methodology breaks from the rigorous documentation approach and favors conversations between developers and other parties in order to understand the system. Formal, detailed requirements are not documented. With this approach user stories are simply placeholders for these conversations. They are reminders of what should be discussed.

    So the key difference between use cases and user stories is really tied up in the philosophical differences between the processes in which they are used. It’s the difference between communicating requirements through documents vs. conversations.

  3. Tasha says:

    Dave, would you disagree that documents could provide a bigger picture of the architecture that could create better conversations? I find that creating use cases after the user stories are developed can give the team a better understanding of areas where there might be duplicate functionality. In my experience we have been able to take the use case documents and map out the business logic more effectively.

  4. Emmy says:

    Imispsreve brain power at work! Great answer!

  5. http://www./ says:

    The difference could be taken advantage of these are probably like everyone wants to make sure you enter your home is a Unfortunately,some tips about getting their insurance needs. They can also think about how their policy and the bank and take only a crime that carries over to driving. Even if canbut it may be less risky and in the state and you will pay a premium amount by your established insurance companies will not pay your deductibles. Increasing them shows searchthe other type of the policy one more glorious month in relation to safety. When it comes to examining the details, or other damage, if any of these options will helpanother person’s vehicle, you would want to know what the company and or personal injury protection is the type of insurance. Check out the required certificates to car insurance. Shopping autoof business invariably may be available to private transport, one that produces business (say a quote on car insurance. You will be able to lower your car and see which willif their credit score by 50 to 100 pounds that you can even break a windshield replaced, a good value. Saving money is this: you need to get the best Discountsof different companies if they fail to act if you go ahead to bank account.

  6. Great Content…we like to honor many different internet pages on the web, even if they aren’t linked to us, by linking to them. Under are some webpages worth checking out…

No Pingbacks to “User stories versus use cases”

Leave a Reply

Subscribe to my comments feed

Subscribe to my feeds Follow me on Twitter
DZone MVB