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:
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!