User stories and use cases are powerful techniques to capture requirements. Even though Scrum is agnostic about how requirements are described, user stories are becoming the standard way to express functional requirements on the product backlog. Before I explain why, let’s briefly reflect on what user stories and use cases have in common.
Both techniques put the customer or user at the center of the development effort. Use cases describe how a customer interacts with the product using one or more scenarios. A use case may consist of a short narrative or of several structured scenarios including main success scenario, alternative scenarios and failure scenarios. 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. Uses cases and user stories employ customer roles known as primary actors and user roles respectively. Both techniques can be applied at different levels of granularity: Use cases may be written as business or system level use cases. User stories may be formulated as epics, coarse-grained or detailed stories.
User stories are particularly popular on the product backlog for two main reasons: First, applying the technique is easy (but writing good stories can be hard). There are no complicated templates, no pre and post conditions, no triggers and exceptions to be specified. Since the barrier for writing stories is low, it’s easy to do it together involving the entire Scrum team. Second, decomposing stories is comparatively easy; large stories or epics are broken into smaller, more detailed ones over time to ensure that they can be delivered within a sprint according to the definition of done. Having worked with both user stories and uses cases in Scrum, I do prefer stories over use cases on the product backlog.
If you like to work with business use cases to create the product vision, then derive user stories from your use cases by splitting each use case scenario into one or more stories. The stories are then used to stock the product backlog. And don’t feel obliged to describe every single product backlog item as a user story. User experience requirements, for instance, are best captured using different techniques such as user sketches, storyboards, user interface navigation diagrams, and prototypes. These artifacts complement and elaborate the stories on the product backlog.
You can learn more about stories on the product backlog in my book Agile Product Management with Scrum or by attending one of my upcoming product owner classes.
RSS
[...] 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 [...]
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.
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.
In this blog post, I mentionned the major differences I’ve noticed, and usually share with teams :
http://www.agile-ux.com/2009/01/23/use-cases-user-stories-so-precious-but-not-the-same/