Picture by Aaron Burden, published on Unsplash under the Creative Commons Zero license

User Stories or Use Cases?

Published on 11th May 2010

User stories and use cases are both powerful techniques to capture requirements. But which one is right for you? This post shares my recommendations.

Use Cases and User Stories in a Nutshell

Use cases describe how a customer interacts with the product using one or more scenarios. It commonly consists of several structured scenarios including main success scenario, alternative scenarios and failure scenarios as well as the actor, a trigger, and pre- and postconditions. (Note that there are also so-called casual use cases that simply consist of a brief narrative but I find that these are not very common.)

User stories describe how a customer or user employs the product. Stories consist of a name, a brief narrative (the story) and a set of acceptance criteria. The latter formulate conditions that must hold true thereby making the story more precise.

Both techniques put the customer or user at the center of the development effort. Use cases use actors to characterise the people interacting with the product; user stories use user roles or personas; and the functionality is described from the perspective of a customer or users. This encourages a user-centric and a void a solution centric mindset, that is, to focus first and foremost on the customers and users rather than being guided by technology.

Benefits and Drawbacks

User stories have become so popular since they appeared in the second half of 1990s for one main reason: they help you move fast. User stories encourage you to quickly sketch an idea or requirement, discuss it with the development team, expose the resulting software to the customers and users, analyse the feedback or data, and then decide what to do next. User stories move from documenting requirements to tacit knowledge: product owner and development team have a shared understanding of what the product needs to do, as they discuss and sometimes even co-write the stories. This saves time. But it does require close and effective collaboration–ideally everyone is collocated.

Use cases are more structured and detail-rich, and they can embedded in models, such as, context diagrams. Creating a use case is usually much more work than capturing a user story, and this means that the development speed tends to be slower. But more detailed requirements are useful when a close collaboration between product owner and development team cannot be achieved, for example, when you work with a remote or offshore team.


My advice is: work with user stories whenever you can and write use cases if you must, that is, when you cannot enable close and regular collaboration between the product owner and the development team–be it in form of collocation or videoconferences. This does not imply, however, that you shouldn’t learn more about use cases, including the modelling techniques they offer. The opposite is true: I’d like to encourage you to try out both approaches so you can determine which one works best for you.

Learn More

You can learn more about this topic with the following:

Post a Comment or Ask a Question


  • Use cases or user Stories – User Stories or Use Cases… It is a recurring issue with the teams starting in agility, especially in organizations integrating a Business Analyst role.

    My preference is now going to user stories but in some contexts Use Cases (“Essential use cases” constructed progressively and collaboratively…) remain appropriate.

  • Ron Phillips says:

    Whether you use user stories or fully-dressed use cases, it’s important to start by thinking about for whom you are writing. The end-game is to communicate and create understanding. That will help guide your process and improve your chances of a good result.

    • Great point, Ron. My post assumes that the stories are derived in the context of a product vision stating the target customers and users. I have found that collaboratively writing stories and involving customers and users can be very beneficial. And it’s vital to have customer and user representatives at the sprint review meeting to benefit from their views and adapt the product backlog based on their feedback.

1 Trackback

Leave a Reply

Your email address will not be published. Required fields are marked *