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.
You can learn more about user stories by attending my Writing Great User Stories training course. To find out more about user stories in the context of Scrum, take a look at my book Agile Product Management with Scrum. And to learn more about use cases, I recommend Alistair Cockburn’s book Writing Effective Use Cases.