Successful projects are based on a common understanding of a product vision. Without a clear product vision, projects risk wasting resources and may be exposed to delivery delays and failures.
Assuming everyone on your team shares a common vision for what you will build together, one of the key tasks for moving forward is breaking that vision down into actionable pieces of work. Clients regularly ask us, “Should these detailed requirements be written in the form of user stories or use cases?” Based on EK’s experience, we’ve found that user stories are the more effective method for communicating business needs.
User stories are the building blocks for communicating:
- What a product should be able to do;
- How each feature adds value; and
- Who benefits from the value those features offer.
Here are the benefits we have found in writing requirements in a user story format.
Perspective, Purpose, and Priority
The distinction between use cases and user stories is summed up as follows:
| Waterfall Projects | Agile Projects |
| Business analysts capture requirements and write them in isolation away from stakeholders. All requirements are documented in detail in the form of use cases. We try to avoid change as much as possible. | Product owners elicit requirements by facilitating conversations with stakeholders. Conversations are documented in the form of user stories. We anticipate change, so we add detail to only the highest priority user stories. |
User stories are written in a way that reveals a requirement’s perspective, purpose, and priority.
Perspective
Too often, internal stakeholders decide what to build based solely on what they think should be built. What we think other people want or should have is unlikely to be what people actually need. To minimize the risk of 
building unnecessary features, we have to start by thinking from the perspective of the user and when possible, involve them in the requirements definition process.
When writing user stories, shifting to the user’s perspective dramatically enhances the usefulness of the end product. There’s a tendency to write stories from the business owner’s perspective, which leads to a website that may be heavy on campaigns and advertisements with not enough focus on user-centric content or features. Another potential pitfall is writing stories based on features that are technically very impressive, but don’t address any of the challenges that end-users face.
By defining personas and conducting user tests, you can get a better understanding of what users actually need. Further, by involving users throughout the development process, you can use their feedback to determine whether to pivot and head in a different direction.
Purpose
When discussing features to build, we encourage our stakeholders to speak in terms of the value they want to deliver to end users. The “I want to… so that…” part of the user story includes a brief description of the feature and how it benefits the user group that is represented by the persona. This is important because this is the
element of the user story that generates conversation among stakeholders. We have to understand not only what we want to build, but why we want to build it.
This “why” is critical due to the number of ways a feature could be built. We could say “build me a horse and carriage” when really what we want to express is that we want a vehicle to get us from point a to point b in the safest and most efficient way. Why ask specifically for a horse and carriage when you can let a team of experts propose a design for a Tesla once they know what you need?
Another real-life example comes from one of my recent consulting efforts. Our client needed an intuitive content management system that rendered beautiful web pages. Rather than prescribing the platform and asking the developers to build the web application using only Drupal, we allowed the cutting-edge technical team to deliver a solution that fit our needs. They built the site using a headless Drupal approach, which used an Ember.js app to render the front-end and added a custom content editor using mobiledocs. This was only possible because we focused on our business needs before defining the technical solution.
| Use Cases | User Stories |
| Written with the system first:
“The system shall…” Example: The system shall display a product image and product details. |
Written with the person first:
“As a [persona], I want to [do something], so that [I can get some sort of value from that something].” Example: “As a store vendor, I want to showcase my products so that customers can identify items to purchase from my store.” |
In most cases, we’re building products for people, so we should shape the technology to fit their needs rather than the other way around.
Priority
Lastly, user stories are written in a way that allows them to be easily prioritized. Given the value that a certain feature brings, you can rank your user stories in order of importance using techniques such as card sorting, MoSCoW (which categorizes requirements as Must, Should, Could, or Won’t), or something as simple as Critical, High, Medium, or Low. Working on the most important features first ensures that you deliver the most value as soon as possible.
Summary
Are user stories enough to completely define a product’s features and design? The answer is no. Just as user stories are the product of conversation, they also spark continuing conversation about user needs. In order for a story to be ready for development, you still need to:
- Add acceptance criteria that testers will use to make sure the product was built properly;
- Define development tasks that will guide the team in coding the application; and
- Supplement the user story with process flows, tables, wireframes, and design comps, as needed, to clearly communicate expectations to the development team.
Defining and communicating requirements is a team effort and user stories can help your team collaboratively achieve this goal. Not sure where to start? EK’s Agile Coaching, Facilitation, and Workshops can help show you the way.