RSSUser 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.
