Which should be done first: use cases or user stories?

Question

I've heard both about use cases (I'm talking about the description, not the diagram) and user stories being used to gather requirements and organize them better.

I work alone, so I'm just trying to find the best way to organize requirements, to understand what has to be done in the development. I don't have, nor need, any formal methodologies with huge documents and so forth.

User stories I've seem being used to build the product backlog, which contains everything that needs to be done in the development.

Use cases, on the other hand, provide a description of how things are done in the system, the flow of interaction between external actors and the system.

It seems to me that for one use case there are several user stories.

This leads me to the following question: when discovering requirements, what should I do first? Find and write user stories or find and write use cases? Or they should be done "at the same time" somehow?

I'm actually quite confused. Regarding use cases and user stories, for a developer who works alone, what is a good workflow, to use these methodologies correctly in order to have a better development?

Answer 1

Use cases and user stories are both tools for gathering and expressing requirements.
As you already found, a single use case has typically a broader scope than a single user story because it tries to completely describe a user interaction including errors and deviations from the normal path. A user story can be roughly compared to a single flow through a use case.

As with all tools, it is up to you to use the tools that you think are necessary in a particular situation. This means that you can use only use cases, only user stories or a combination of use cases and user stories as you see fit.

---

It is becoming increasingly common to use user stories as the unit-of-work of what can be developed and delivered in one iteration/sprint.
With that in mind, I wouldn't focus too hard on collecting requirements as use cases, unless the use cases come naturally when talking with the stakeholders.

Answer 2

In my case, I have always found that the level of details needed for full use cases come about by thinking through my user stories first. The first question I ask is "what do people need to be able to do?". Once I have the scenarios, then it's easier to start going through all the use cases and variants of flow for the system.

That being said, for a single developer who works alone, you don't really need to care about whether it's a use case or a user story or a sticky on the wall that says "don't forget about 'x'". What you need is any process that makes you think about what your users are trying to achieve and helps you track the different things they need to be able to do. Everything else is up to you as to the level of detail you need to write down in order to plan out your development.

For example, when I work on a solo side-project, my work tasks look something like this:

1. Login
2. View list of 'foo'
3. Save selections from list
4. Search

Honestly, each one of those would not have anything more on it than an estimate. Why? Because I'm just using them as a reminder of what I need to be able to have the user do and I'll figure out the details when I get around to that part. With a team of a single person, everything can be in your head and that is okay, because you don't have to communicate it to anybody else.

Now, there are caveats...

Single developer working with other specialists

Do you need to report on progress to another team? Do you have testers that need to validate your work? Do you have management that wants to know what you've done? Do you have a project manager that needs to predict a timeline? Do you have a product owner who is determining the features that are required?

If these people are part of your project then you need to make sure your work tasks have enough pieces of information on them to allow them to do their work. The PM probably needs a way of seeing relative sizes of things and progress through that work. Your testers will need details as to how things are expected to flow (use cases) and you may even ask them to help you write them. Management might want to know what it is you are working on, so you'll need enough of a business description so they can understand the features you are going to be delivering.

If you answered 'yes' to all those questions, you probably need to have a more rigidly documented backlog as you will be using it to communicate with the other members of your team.

• You will likely need to have the concept of 'Epics' or 'Features' that will be the high level functionality that you can use to report to management or your product owners.
• You will have nested User Stories inside those Epics/Features that will define the smaller blocks of functionality that will be used to communicate progress with your project manager, define your work tasks within a sprint, and will be used to communicate the business objective to the test team.
• You will have use cases or test cases defined for the stories to capture the various low-level flow decisions that are required to make sure that you, the business, and the test team are aligned and know what will be accepted as 'correct'.

All of the above can just be ignored if you are the one defining the work, managing the progress, testing the software, and deciding if something is 'correct'. Cut out the extra effort and make sure you are doing what is important: building working software!

Answer 3

If you're doing some type of agile, the dogmatic answer is, Do what works for you.

Process should be part of your retrospectives. You should be talking about bottlenecks, redundancies, communication problems, documents that no one ever reads, etc.. And, that's the setting where process changes should be agreed upon and ideally set in motion.

---

In my experience, Project Managers, Analysts, and "business people" are trained to perform the process "inside out." They gather requirements, which are often verbally given by stakeholders in user story form. They ask questions to clarify, so they can create detailed "use case" documents, which the development team tries to translate back into user stories they can iterate on ...

My recommendation, based on my own experience: Try to get your team or analyst or whoever to put user stories right into the backlog, with minimal detail. Include priority information and describe the "problem" the story aims to solve. Maybe list some potential solutions ... but, beyond that, let the "use cases" emerge as your developers iterate with QA and/or the stakeholders on the stories.

Record the use cases you landed on in your documentation as the story resolves, in whatever format helps folks understand the system.

Answer 4

It depends. If you are working alone, try different approaches and take what works best for you.

Disclaimer: There are a lot of methodologies how to write them up. "User stories" have a very common definition whereas "Use cases" can have very different meanings. I refer to the classical UML diagrams, which are very common.

User stories or Use cases

In my experience, there are different mind sets on which way is the better to understand. So I would decide on every new project team, how to document the requirements. Usually a combination is common, using Use cases for the overview and user stories for details.

• Use cases, especially as diagrams, are better suited for people thinking visually
• User stories are preferred by people thinking in discussions who are very talkative

(this is opinion based, without scientific foundation)

What to do first?

On writing the requirements for a project, I would start on a very abstract level. Using use cases, you would paint an (UML-)diagram with the global goals of the project. With user stories, write down a few "epic stories" describing the main goals.

A second step would be to get into the details. Doing this, you should try to keep a reference to an "epic story" or a global goal. This helps structuring the requirements a lot.

Answer 5

I'll look at it the other way round: What needs to come last?

The last step is that you (or someone else) enters requirements into your backlog. The requirements must be such that you know how the code that you write should behave, and so that testers can verify that your code behaves the way it should do.

These requirements can very well be recorded in the form of a well defined user story. So the user story can be the last step. Use cases will usually turn into more than one user story, so they have to come before the user story.

Answer 6

User stories and use cases are not mutually exclusive and there is no "should".

They are just tools which may or may not be helpful to enhance your process to some point. There are many possible ways, I would just propose one with both use cases and stories used together:

• For backlog and planning try user stories as high level features placeholders. (Of course use cases down to user goal level can help as well.)
• To document already implemented requirements use cases would work as their best.

Answer 7

I used to think Use Cases were meant for the waterfall approach, while User Stories came with the Agile process. It took me a while to realize that they're not exclusive.

Since you won't have to share these, it won't be about communication, except with yourself. As long as you can understand your notes a week or so later, you're good. Otherwise, add more detail when you note the requirements.

Do you need a visual and flexible way to follow your progress and set priorities? If so, User Stories would be useful, along with the progress board you'll find in most agile methodologies (todo, done, current sprint).

When it comes to pure requirements, knowing what needs to be solved and how, I'd suggest starting with User Stories as they're easy to create (one sentence), or a Use Case Diagram listing only actors and high-level actions.

When detail is needed, drill down with more User Stories. When you encounter a complex process (branching, lots of conditionals and prerequisites), you may LINK the User Story to a Use Case, whether you use a diagram or the text-template version. And do remember that even those can be created with varying levels of details. The Software Requirements book by Karl Wiegers & Joy Beatty recommends keeping only the level of detail necessary to understand. If something is utterly obvious to you, you don't have to drill down.

The above is what I personally didn't get at first: User Stories are a starting point, a "summary", but each can be complemented by additional documents to further define what's meant and needed, including detailed Use Cases when necessary.