User Stories, Scenarios & Use Cases
|
Nadine Schaeffer
In general, all three terms represent ways that application teams try to define and understand what the app will do from the user perspective. User stories, scenarios and use cases can therefore be understood as framing devices; they provide mechanisms to understand and plan technology development around the end user, instead of focusing on development and product features around the constraints of the business, the platform or the underlying development of languages and libraries. The exact purpose and audience for each term varies. Scenarios are generally used by user research people to communicate with design teams. User stories are written largely by project/product managers as part of definition and requirements documentation. The audience for use cases is primarily developers who need to write test cases and need to understand if their data objects are handling the appropriate i/o, errors, and exceptions. Now let’s examine closely all three terms, associated deliverables and processes. Scenarios Let’s start with scenarios. They are usually tied to personas and are part of creating a story about who the user of a particular technology is, what they want, what they know. A scenario is therefore usually written in narrative form, perhaps with pictures and illustrations as well. Scenarios are generally written at the beginning of a project during discovery and requirement gathering phases. They provide human-centered anchors to guide design and development by providing tangible faces, names and stories for how the technology will be used. A common generic format for scenarios goes something like this:
User Stories Now what about user stories? User stories are generally used by Agile development teams. They are meant to replace long complex documentation with short sentences that capture the essence of a user’s needs. They are intentionally short and granular—each story captures just one task or action. User stories are defined during development before or at the beginning of each sprint. User stories are generally written in this kind of syntax:
Use Cases Finally, let’s describe use cases. Use cases are generally written as part of detailed product requirement documentation. They capture the goal of an action, the trigger event that starts a process, and then describe each step of the process including inputs, outputs, errors and exceptions. Use cases are often written in the form of an actor or user performing an action followed by the expected system response and alternative outcomes. Use cases tend to employ this kind of format and content:
User Story: Use Case: In Summary Links & More Info
Nadine Schaeffer is a consultant professional with over fifteen years experience planning and building internet, mobile and desktop applications. She has aided many companies large and small launch successful technology and branding projects. In the past years, her work has focused on building successful user interface designs and flexible information architecture systems that integrate web 2.0 technologies as well as social and community initiatives. For more information, visit CloudForest. Read more on LogiGear Magazine - July 2011 | Volume V | Issue 5FEATURE ARTICLE:
RELATED ARTICLE:
SPOTLIGHT INTERVIEW: VIET NAM SCOPE: BLOGGER OF THE MONTH: |
