Whether it’s a software project or a marketing project, all projects have something to deliver. And all projects have users—people who will interact with that end solution, product, service, or other result you deliver. To define the requirements and get agreement on the deliverables, you’ll need the input of these users.

But because users are subject matter experts in their own line of work, they may not always think systematically about how to best tell you what they need. They may struggle to think of all the things that will matter. If you’re the business analyst, that means you have to find creative ways of asking questions to get the information you need.

So, which tool do you choose: a use case or a user story?

The commonality of their names creates some confusion. In the past user stories were thought to be applicable only in the agile development realm. Use cases were always a tool of business analysts. Today, we see the user stories being used alongside of use cases. This is a good thing!

Let’s take a look at the similarities and differences between these two tools and how you can apply them both to improve project outcomes:

• Both can be applied to any project deliverable to define requirements. Lots of people think that these two tools are only used in software development and therefore, only describe the relationship between a user and a system. But no matter what type of project you’re working on, requirements for the end product, service, or result need to be identified.
• User stories are compact statements based on user story templates. User story templates usually follow this format: As a <type of user>, I want <some goal> so that <some reason>.
• User stories describe a need or desire. They are usually thought of as higher level and conceptual and are often easier for users and participants to describe and understand.
• Use cases have much more detail. A use case describes an action and behavior. They describe the actors involved, the preconditions in the beginning, the triggers that initiate action, the flow of events and actions, and the conditions after things are complete.
• Use cases are often accompanied by a use case diagram. This is the graphical depiction of the interactions and requirements. A use case diagram can be created by users and participants, but typically they’re prepared by a business analyst.
• User stories provide the context for use cases. Because user stories provide the high-level conceptual idea of what the client wants, the best approach is to create all of the user stories first and then categorize and prioritize them. After you’ve selected the user stories for development, you can then break them down into use cases to provide the detailed requirements.

Marry the two together to get the results you need. The user stories help the user contribute what they need to contribute, while the use cases provide the detailed requirements the business analyst needs when turning it over to those who will ultimately build the solution.

Agile purists will see this as heresy. They’ll tell you that use cases don’t fit into the agile philosophy and approach. But I’ll tell you that user stories fit nicely with use cases in non-agile development environments. And why not take advantage of all the tools you have!