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.
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.
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.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
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
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.
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.
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.