How and when to use each, how to apply the techniques and tools properly
User stories are not the same as a use case. Yes, both are terms used in gathering requirements from customers in software development. Yes, both identify users and user goals, but they serve for different purposes.
User stories are a short description of what your user will do when they come to your website or use your software. They use the natural language of the business and do not tell the whole story. The BA writes acceptance criteria which define the boundaries of a user story and can help the development team to know when a story is indeed complete.
A user story is usually written in the following format: As an [actor] I want [action] so that [achievement].
?As a traveler I want to check in for a flight, so I can fly to my destination?. ?As a small business owner, I want to create an invoice so that I can bill a customer?. Or ?As a customer, I want to update my customer profile so that future purchases are billed to a new credit card number?.
In Scrum, the development of your product is split into a series of iterations called sprints, where each is usually between 2?4 weeks long. Usually, a user story is implemented all in a single iteration of an agile project, while it?s common to split a use case across multiple iterations. During a sprint, each story will go through a number of stages such as: not started, started, in testing, finished, delivered and accepted.
There is an acronym INVEST that is a checklist for a widely accepted set of criteria where BA and its team can assess the quality of user story. If User story fails to meet one of these criteria, the team might consider rewriting. Therefore a good User story should be:
Independent (of all others),
Negotiable (not a specific contract for futures),
Valuable (It?s all about the end-user. If you can?t describe the value a customer is going to get out of your story, it?s not a good story),
Estimatable (to a good approximation),
Small (so as to fit within an iteration) and
Testable (in principle even if there isn?t a test for it yet).
On the other hand, the Use case is a more detailed description of a set of interactions between the system and one or more actors, where an actor is either a user or another system. The use case is created as a document that includes:
Short description with the goal,
The trigger (event or sequence of events that initiate the use case),
Specify the actors,
Preconditions (the things that must happen in the system),
Normal flow, alternative flow, exceptions (deviations from normal flow) and
Post conditions (what system must have been achieved at the end of the normal or alternative flow steps).
In other words, use cases are more about behavior that the technical team will have to build into the software. As mentioned in the bullet points, it will contain a lot of details; clearly describing everything that a developer needs to build to meet user need?s need. And developers will get a good sense what the software needs to do!
There are a lot of story mapping agile tools that help BA to visualize the bigger picture while keeping all user stories, and use case elements in perspective. It helps stakeholders to stay updated about their project progress. Some of them are Jira Agile, Lucidchart, Team Foundation Server, BoardThing, Stories on board, FeatureMap and etc.
Based on my experience, Lucidchart (free trial) are pretty easy to use, have hundreds of templates and examples: Flowcharts, Mind map, ERD, Hundreds of shapes with easy drag and drop functionality ? Export to PDF, PNG, JPG and Microsoft Visio. The wireframes made on Lucid Charts can be interactive to show pop-ups and different screen states. However, if you decide to upgrade your account there are integrations with Slack, JIRA, BitBucket, Ofice365, AWS, Excel, Quip, and etc. Real-time collaboration: there are multiple ways to share your diagrams with your clients and your viewer can easily add comments and edit the chart. The software has a revision history feature so that you can keep track of what?s been updated on your diagram.
At the end, we can sum up that User stories are centered on the result and the benefit of the thing customer is describing, while use cases are more detailed, and describe how your software will work. Both put the user at the centre of the development efforts making sure that your software project delivers an end product that users want and that satisfies their needs.
Reference:
- International Institute of Business Analysis 2015, A Guide to the Business Analyst?s Body of Knowledge (BABOK Guide), Version 3.0, Toronto, Ontario, Canada.
- Requirements 101: User Stories vs. Use Cases
