Picture by Aaron Burden on Unsplash

User Stories or Use Cases?

Published on 11th May 2010 Last Updated on: 7 Mar 2022

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 actual story) and a set of acceptance criteria. The latter formulate conditions that must hold true thereby making the story more precise. User stories are more informal than use cases, as they complement the text with a conversation: The person in charge of the product and the development team members must discuss each story. This creates a shared understanding and ensures that the story is feasible and testbale.

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.

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.


Recommendation

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 person in charge of the product and the development team—be it in form of onsite or online workshops. 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. Alistair Cockburn’s book Writing Effective Use Cases and Mike Cohn’s book User Stories Applied are two classic reads, which will help learn more about the two techniques.

Post a Comment or Ask a Question

5 Comments

  • nour yousef says:

    tacit knowledge, i suppose that stories give you mental image including some simple words by the customer or user language
    in case studies as i’s studies , concerns to these explicit knowledge that could be measured to study but with the user stories there is more space for the tacit knowledge to be impact which apears only when the product owner succeeded in translating this tacit knowledge of the customers language in his story by his words to agile teams in managment & develpment ..
    though i think it’s the tacit knowledge is the main difference between user story & case study

    • Avatar photo Roman Pichler says:

      Thanks for sharing your perspective Nour. I agree that tacit knowledge is a key difference, which requires a closer collaboration in the case of user stories and enables a more informal, less text-heavy approach.

  • jcQualitystreet says:

    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.

    • Avatar photo Roman Pichler says:

      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

  • nour yousef says:

    tacit knowledge, i suppose that stories give you mental image including some simple words by the customer or user language
    in case studies as i’s studies , concerns to these explicit knowledge that could be measured to study but with the user stories there is more space for the tacit knowledge to be impact which apears only when the product owner succeeded in translating this tacit knowledge of the customers language in his story by his words to agile teams in managment & develpment ..
    though i think it’s the tacit knowledge is the main difference between user story & case study

    • Avatar photo Roman Pichler says:

      Thanks for sharing your perspective Nour. I agree that tacit knowledge is a key difference, which requires a closer collaboration in the case of user stories and enables a more informal, less text-heavy approach.

  • jcQualitystreet says:

    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.

    • Avatar photo Roman Pichler says:

      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.

  • Tweets that mention User Stories or Use Cases? « All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership -- Topsy.com says:

    […] This post was mentioned on Twitter by Romain Couturier, Roman Pichler. Roman Pichler said: I've just published a new blog post discussing user stories and use cases on the product backlog: http://bit.ly/caUsJG […]

Leave a Reply

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

Get Regular Updates from Roman

Hear about his latest product management work, new content, new talks and training courses, and more.