User stories are brief, simple descriptions of user functionality written from the user’s point of view. They typically follow a simple template: “As a ____ , I want to ____ ____ so that ____ .” For example: As an anonymous user, I want to see how many users signed up today so that I can know whether my site is gaining momentum. Or… As a user on mobile Safari for iOS 7, I want to use dynamic type so that all text scales automatically based on my settings.
Use case examples are user-oriented statements describing what people can do with your application or website. A typical sentence might be “As a user, I would like to log in securely without being obtrusive.” A key aspect of user stories is that they are user-centric rather than technology-centric. For example, a user story would not say “As a user, I want to click on the menu,” but rather “As a user, I want to access my settings.”
User stories help your team stay focused on building what matters most to users by delivering the right functionality at the right time. This helps you build products that provide user value and meet business goals. User stories also foster collaboration between Product Management, Engineering, Designers and other relevant roles — everyone works together from early on in an Agile project’s lifecycle.
There are many ways to write user stories. Here are some guidelines based on industry best practices for writing user stories:
- Keep user stories brief, but not too brief. This makes user story writing easy to learn because it’s easier to write smaller user stories than larger ones. But don’t make user stories so short that they are hard for Product Owners or Developers to understand them or discuss them with other team members.
Your product backlog should include user stories of varying sizes–so you have user stories that are just a few words long and user stories that are several paragraphs long. This makes it much easier for the entire team to prioritize what is most important to do next in order to help users achieve their goals as well as meet business requirements.
- Use active voice when creating user stories (e.g., “As a user, I want to be able to select the user role dynamically so that I can create users for different user roles”).
- Use user-centric language when creating user stories (e.g., “As a user, I want to be able to upload files securely so that they are not accessible by unauthorized individuals” vs. “The user role must have the ability to upload files securely”).
- Keep user stories focused on one thing/goal at a time (e.g., don’t mix multiple use cases into one story).
- User stories should start with action verbs (e.g., “As a user, I want to login.”) rather than nouns (“I want a user login.”).
- Keep user stories short and simple (e.g., between one and four sentences in length).
- Start user stories with “As a user, I want to…so that…” to provide clarity on the desired outcome for the user at the beginning of their user story creation process.
- A user story must have acceptance criteria in order to be considered complete (e.g., “As a user, I want to login so that I can access my account details”).
Agile user stories are user stories that are written specifically for agile projects. These user stories are typically shorter than user stories used in traditional methods, but one of the biggest differences is that user stories on agile projects are user-centric rather than system-centric. On agile projects, the user story acts as a contract between the business analyst and the product owner or project manager about what should be built to meet the needs of the user. Additionally, it may include acceptance criteria so that everyone (not just the BA) knows when a user story has been completed.
One way to help determine whether to use user stories or use cases is to look at how complex your requirements are—the simpler they are, the more likely you’ll be able to complete them using short user stories. This is more user-oriented and allows developers to more easily complete user stories, since they don’t have to write complex requirement descriptions or meet with BA’s for clarification of requirements before coding begins. However, if you’re dealing with a highly complex user story it may be possible that short user stories will not get the full breadth of information across and you’d need use cases more than user stories.
