April 11th, 2024, posted in learning
by Adelina
This is the second article in a three-part series called “A design-first approach to writing great user stories”. In this series, we talk about why we need to approach product discovery in a more visual way and how to do that in order to write better, more useful user stories. Check out the rest of the articles in the series here:
Intro: A design-first approach to writing great user stories
Part 1: How to use UI/UX design as a tool to discuss, clarify and agree on app requirements
Part 3: How to estimate user stories for improved planning
If you want to read more on our development process as a whole and how we help businesses go from idea to app, also check out our MVP series.
In the first article of this series, we looked at how to use high-fidelity mock-ups and clickable prototypes as your go-to method for capturing and discussing software functionality and requirements. We found this visual approach works better than the regular product discovery route taken by most founders and stakeholders. We also touched on how to organize and work with your designs in order to make them easily translatable into user stories. Now it's time to actually write the user stories.
Throughout the article, we'll be using our user stories template you can find here. Make sure to duplicate it or download it, as we`ll be looking at it in detail later on. As an app example, we'll focus on the same internal project used in the previous article: the back office of a tech recruitment platform. But, before we dive into specifics, let's look at the what, the when, the who and the why.
What are user stories?
A user story is a short description of a feature written from the perspective of the end user. It's considered the smallest unit of work in Agile development and it generally follows the same format:
As a [user type], I [want to], [so that].
Don't confuse user stories with technical documentation or software system requirements. User stories use non-technical language to describe features as they will be used by certain categories of users (user types). The word “users” can mean anything from paying end users to employees using the app internally in their day-to-day work. User stories focus on the value features create for the user (the so that part) by helping them achieve their goals (the want to part).
When should you write user stories?
Traditionally, user stories are written at the beginning of the project, as the team decides on the features to be included in the app. This approach however is not very intuitive and it leaves room for a lot of misunderstandings, as we`ve seen in the previous article. As stories are constantly added, removed, discussed and reprioritized, a lot of things get lost in translation. Plus, the time to reach a tangible design for your app increases. Or even worse, design is skipped entirely, and now the development team is left with a list of sentences that contain a high-level vision of what some users might like to do. So, instead of writing user stories from the very beginning, we suggest starting with the UI/UX first. And then working on the user stories as a way to document your designs and visual flows.
Why write user stories?
But why write user stories at all, you might be wondering, if you already have the screens entirely designed? Think of user stories as the “paper trail”, a way to keep track of details and nuances which might be easy to miss or unavailable in the designs. User stories complement the mock-ups and can even cut down on some of the design work. Instead of creating a new screen for each open dropdown, each available filter, or each select option, you can list the specifics in the user stories. This way, you have your dropdown UI component, which stays the same throughout the screens, and then you have the specific content of each dropdown documented in the user stories.
There are also other reasons why you shouldn't skip user stories, even if you are following a design-first approach:
- writing user stories is a great way to discover gaps and inconsistencies in the designed screens
- user stories are easier to estimate than designs alone
- user stories can be turned into backlog tasks faster
Who writes user stories?
User stories are usually written by Product Owners. Product Owner is a role, rather than a job description, so it can be filled either by a SCRUM Master, a Project Manager, a Product Manager or even someone on the client's side.
However, this doesn't mean writing user stories can`t be a collaborative process. In fact, it's quite the opposite. In our own workflow, we try to involve all team members who have contributed to the project: business analysts, project managers and, of course, UI/UX designers. The Product Owner usually meets up with the UI/UX designers before writing the user stories. After the stories are written, we make sure at least one person from each of the roles mentioned above reviews the user stories.
The anatomy of a user story. Our user story template
So, you`ve read the articles, watched the videos, downloaded the white papers, but still don't know where to start? We've put together an easy to use Excel template you can duplicate or download to use for your own projects. We`ll also be using this template to write user stories for a real-life app example. But first, let's take a look at how the template is organized.
To make the template as easy to use as possible, we avoided any kind of jargon. Fields have intuitive names and follow the general outline: As a [user type], I [want to], [so that].
1.) User types are listed as tabs in the Excel template, so you can easily navigate from one user type to another.
2.) The “want to” part is listed as a Goal (also referred to as an Epic in Agile, which is basically a higher-level story or a grouping of smaller stories serving a common goal). The Goal can take one or more steps to complete, which can be further broken down into user stories.
3.) The “User Story Description” field allows you to add important information to that user story. This can range from descriptions of the app's behavior and the layout of the page to details such as date format.
4.) The “Design” field allows you to add links pointing to the actual screen designs and flows. Pro tip: In addition to the design links, add a text description of the page layout. This will help developers estimate the work more accurately when the time comes and separate between coding the layout and coding the functionality.
5.) The template also includes fields for frontend and backend estimates, as well as additional comments. After writing the user stories, we have a planning meeting with the development team, where we estimate the work for each user story. If you want to read more about estimating user stories, check out the next article in the series.
How to INVEST in good user stories. With examples
Now, let's put the template to work. We'll be using as an example the back office of a tech recruitment platform. The platform allows companies to look for engineers and tech talent, while candidates can fill in a detailed profile in order to get matched with the best opportunities. Admins have access both to companies` and candidates` data and they can manage everything related to them. Right from the start, we can create three separate tabs in the template for the three user types: Admin, Client and Talent.
Since admins can usually do everything other user types can, it's a good idea to start there. Starting with the admin will make it easier to write user stories for the remaining user types, as some things are sure to overlap. Also, when writing user stories, try to keep the same order throughout the document regardless of user type. For example, we always start our user stories with authentication, followed by the general navigation layout and then the app sections most used by that user type. We leave at the end things used less frequently, such as account settings, as it's unlikely a user will change their password or update their profile information daily.
Before diving into the admin user stories, let's pull up the designs we created for this user type. In the previous article, we talked about how to organize your design files and screens in order to make writing user stories easier. Basically, both our Figma design file and our user story Excel template follow the same general structure: one Figma page or Excel tab for each user type, one section for each goal and visual flows/user stories for each step. This is extremely helpful when the time comes to put everything in user story format.
We can now start organizing our template into the first high-level stories or Goals for the admin user type. Looking at the screens, we have the following Goals:
1. View and manage Positions
2. View and manage Clients
3. View and manage Talent Database
Each goal can be broken down into steps and further into user stories. To view and manage Positions, the admin needs to go to the Positions page (Step). There, the admin can perform various actions to fulfill the Goal. These actions are documented as user stories and, like with most admin panels, they cover a series of CRUDs.
Goal: View and manage Positions
Step: Go to Positions page
User stories:
1.) As an Admin, I want to see all active and inactive positions, in order to keep track of what clients are looking for.
For Read CRUDs, we also like to include in the User Story Description field a listing of what the page contains. As previously mentioned, this helps developers provide better estimates by separating the work needed to code the layout and the work needed to code the functionality. The description might sound something like this: “Page Layout: Page title with Add New button, Active/Inactive tabs, Filters above table: Name, Client, Placement, Status, Date Created/Updated, responsive table with pagination and the following table header…).
2.) As an Admin, I want to delete a position, in order to remove it from the Positions list. (Delete CRUD) - make sure to include in the User Story Description field whether confirmation is needed or not when you delete an item.
3.) As an Admin, I want to filter positions, in order to see only positions based on certain criteria. - make sure to include the filtering criteria in the User Story Description field.
4.) As an Admin, I want to perform a search, in order to find a specific Position. You can specify the behavior of the search in the user Story Description field, for example if it uses autocomplete or not.
5.) As an Admin, I want to add a new position, in order to reflect the clients` incoming requests. (Create CRUD)
6.) As an Admin, I want to quickly add a new client when adding a new position, so that I don't have to navigate outside the page. (Create CRUD)
7.) As an Admin, I want to see a position's details, in order to check that everything is up to date (Read CRUD) - make sure to include a description of the layout in the User Story Description field.
8.) As an Admin, I want to edit a position, in order to keep it up to date.
Now that you have the user stories for the first Goal, you can apply the same workflow for the rest of the Goals. Take each Goal and break it down into steps and then user stories/CRUDs. For example, in order to view and manage Clients, the admin needs to be able to perform Create, Read, Update and Delete operations, similar to the ones described for Positions. In addition, the admin can approve or reject Clients who registered on the platform and send onboarding or rejection emails. The admin can also review the Client`s survey answers, where they specify things such as: the positions they are looking for, technical skills, type of schedule, seniority level, etc. You can give it a try and write the user stories for the remaining Goals yourself.
The INVEST principle
As you start writing user stories, you might find yourself second-guessing some of your decisions. Sure, your user stories might follow the same deceptively simple one-sentence format, but is that enough to make them good? The short answer is no. The equally short, but more useful answer is an acronym: INVEST.
INVEST lists the characteristics of a good user story. You can use the checklist to assess the quality of your user stories and make sure they are:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
1.) Independent
User stories should be written in such a way as to not depend on one another. This doesn't mean they don't follow a logical order, it just means that the development team should be able to work on any user story in the backlog without having to work on another user story.
Why this is important:
This is extremely important from a planning and prioritization perspective. Let's say you are building an MVP and want to launch fast. You decide to keep only the core features and move the development of everything else after the launch. If your user stories are not independent, you will have a hard time doing this. You will be stuck in a loop, where in order to build X, you need to build Y, which depends on Z, and so on. Interdependent user stories make it hard to take anything out and, as the app becomes more complex, it even becomes difficult to add things.
❌ As a Paying User, I want to be able to pay with Visa, so that I can purchase the product.
❌ As a Paying User, I want to be able to pay with American Express, so that I can purchase the product.
(Notice how both user stories depend on having one of the payment methods implemented first and then replicated. But which one?)
✅ As a Paying User, I want to have the primary Visa payment option preselected, so that I can easily purchase the product.
✅ As a Paying User, I want to be able to select a secondary payment option using American Express, so that I can purchase the product through additional means.
2.) Negotiable
User stories provide context and structure, but they are not set in stone, especially when it comes to implementation. Remember, user stories are not technical documents. Their goal is to answer questions related to what is needed and why it is needed, but not how it should be done. Finding the best way to fulfill underlying requirements should be open to discussion and negotiation.
Why this is important:
Keeping user stories negotiable is helpful all-round because it prevents unrealistic expectations or unwanted constraints on finding the best technical solution. Developers will be able to do what they do best and stakeholders will get the maximum benefit from this collaboration.
❌ As a user, I want to log in using OAuth 2, so that I can securely access my account.
✅ As a user, I want to securely log in with Facebook or Google, so that I can easily access my account.
3.) Valuable
User stories should provide some sort of value to the user, captured as value statements in the actual story (the “so that” part). This should be easily quantifiable in order to help with planning and prioritizing features that bring the most value to the business.
Why this is important:
Establishing which features are the most valuable to the customer or the user will shape the entire development roadmap. You want to commit your resources to building or improving the highest-priority features rather than the ones which aren’t as imperative. This also helps stakeholders decide if the resource cost of said feature or functionality is worth the investment.
❌ As a customer, I want a way to save my shipping and payment information.
✅ As a customer, I want a way to save my shipping and payment information, so that I can enjoy a more streamlined checkout experience.
4.) Estimable
If user stories are independent, negotiable and valuable, this will also make them easier to estimate. Make sure to check out the next article in the series on estimating user stories to find out more about planning.
Why this is important:
The development team needs to be able to deliver features and functionality in a reasonable time frame. User stories can be of high value, but they might take longer to implement, in which case they might not be the highest priority items because of the length of time to develop them. That's why it's important to make sure your user stories are independent, valuable and small at the same time.
❌ As a customer, I want to complete my order faster, so that I can purchase products easier.
✅ As a customer, I want to click on the one-click payment option, so that I can skip the payment form and complete my order faster.
5.) Small
User stories are the smallest unit of work in Agile development and you should keep them this way. This means they should be small enough to be completed in a Sprint, while delivering the most value to the stakeholders and the users. If you find your user stories take longer to complete than one Sprint, consider turning them into Epics and breaking them down further.
Why this is important:
Agile core philosophy revolves around getting feedback from users as fast as possible. In order to achieve this goal, the developers’ work needs to be cut into multiple smaller segments. This allows them to deploy a feature quickly, so that no time is wasted when gathering feedback.
❌ As a user, I want to use my online banking account, so that I can perform online transactions.
Break the statement above into Epics or steps and then each step into user stories:
✅ As a user, I want to transfer funds between my own accounts, so that I can feed my current account from my savings account.
✅ As a user, I want to transfer funds to an external account, so that I can perform transactions to third-parties.
✅ As a user, I want to see a history of all my transactions, so that I can keep track of my activity.
etc.
6.) Testable
User stories should be accompanied by acceptance criteria, which is a set of predefined requirements that must be met for the user story to be considered successfully implemented. Putting in place acceptance criteria, also allows you to distinguish between Epics, which are too complex to be validated through acceptance testing (“non-functional”), and User Stories, which are the testable (“functional”) parts of an Epic.
Why this is important:
It’s important to be able to assess whether or not the feature is implemented correctly. This helps both the stakeholders and the developers, as less time going back and forth in the development phase means more time to gather feedback and work on the next iterations.
❌ As a user, I want to calculate the cost of repairing a crashed car, so that I can estimate my repair expenses. (This is actually an Epic and not testable).
✅ Break the Epic down into user stories. Consider outlining test cases for each feature and success and failure criteria, for example:
Success:
- valid user logged in, load homepage
Failure:
- Email address in wrong format
- Incorrect password
- Unrecognized username
When it comes to user stories, practice definitely makes perfect. In the grand scheme of development, user stories may sometimes be overlooked, but, as this article hopefully showed, they are an important part of building successful software products. So, write user stories as often as you can, read user stories written by other people and maybe even leave us a comment if our template helped you.
