What are user stories?
It may sound like we’re about to talk to you about dragons and fairies, but a user story is actually a fairly technical concept, although that doesn’t make it any less interesting. As part of agile methodologies, a user story is the description of a functionality from the user’s perspective. They are usually quite simple, only a few lines long, and don’t go into much detail. User stories also tend to follow the same structure:
As a <user>, I want to/need/can <goal> so that <reason>.
The first part relates to the “who” of the matter: the user, role or persona that will be able or wants to perform a specific action or achieve a goal. The second part of the story relates to that goal and the third part is the “why”: the motivation to perform that action and the outcome or benefit the user gets from it.
Who writes user stories and when?
There is no specific person in charge of user stories. Ultimately, it’s the product owner’s responsibility to make sure they get done, but most likely every member of the team on the project will write one at some point.
These stories are not written at one specific point either but throughout the project. This might involve a story-writing workshop at the beginning of the project to create a product backlog, but new stories can be added later on.
What is the purpose of user stories?
You might think that if you are confident in what you need your app to do, there is not really any point to user stories. However, there are actually several big reasons why user stories are important, if not vital to your project. User stories might seem simple, but they will actually help you define each step in your project more clearly. Here are some of the ways in which they will help you do that:
- They focus on the user: As we’ve covered in other articles, one of the keys to a successful app is to know the user and provide them with the best experience possible. By keeping the focus on the user, these stories allow you to prioritize them and make sure you focus on the person that will actually use your product.
- They help gain clarity all around: User stories provide clarity on what you are building, for whom, why and when. They help you make sure the entire team has a clear picture of what they are working towards.
- They encourage collaboration across the entire team: Unlike coding itself, user stories are simple and don’t make use of technical language. This means any team member (including non-technical ones) can pitch in to define and prioritize user stories, thus having a significant positive impact on teamwork.
- They help define your product: As we’ve mentioned earlier, user stories describe the product’s functionalities from the user’s perspective. They divide your project into small, simple steps that help you define it and prioritize your tasks according to value for the user and the project’s dependencies and complexity. This means you don’t necessarily have to cut out any wild ideas, but can assign a lower priority to them, focus on the core functionalities first, and see if you have the resources for them later on.
How do I write a great user story?
Now that we’ve covered why you should include user stories in your app project, let’s focus on what a great user story looks like. These are all points you should consider and make sure the whole team understands before getting started.
- First of all, keep in mind that user stories are not the same as tasks. You may need hundreds of tasks to complete just one story. User stories define, while tasks are used for implementation. You will need to decide which steps need to be completed for each story and who will be responsible for them.
- Although this may sound repetitive, you will need to focus on the real users of your product. You will have to build their personas, including profiles, points of view, pain points and expectations. Everyone on your team will need to understand the users and think from their perspective. If you have multiple types of end users, you might consider writing multiple stories for them.
- Don’t be afraid to think big or outside the box. There should be no constraints at this stage of the process. As we’ve mentioned earlier, if a story is too crazy or random, you can assign it a lower priority instead of downright discarding it and see what happens later down the road.
- Use epics to organize your stories. Epics describe larger pieces of functionality that require more work and include a set of user stories that share a common goal.On the other end of the spectrum, if a story is too big to complete in one sprint, you might consider breaking them down into smaller ones or make them their own epic.
- Be organized. In the same way you might need to use epics or break down your stories, you will also need to name and categorize them so they are easy to find and prioritize. Avoid renaming or making big changes to a story’s description as this will create confusion. Organization does not stop there, however. You should use tools to help you keep track of your stories and log all of the relevant information. Sticky notes are perfect for brainstorming, but investing in software to manage your project is more than advisable.
What are some examples of user stories?
Now that you have all the basics, let’s look at some real-life examples from The Yoga Collective, one of the apps we’ve developed. This is an online yoga studio where users should be able to subscribe and log in to access the platform and have certain videos and classes available on their dashboard. Taking that into account, let’s start with a simple user story we wrote for this project:
- As a user, I need to be able to log in so that I can access the app’s content.
It might seem rather obvious, but this helps you set up the tasks needed to bring this story to life as well as assign the team members in charge of it.
Then, there are some more complex user stories that include a condition. For example, The Yoga Collective offers paid subscriptions. Subscribers can use the same credentials they use in the app to access the content on the company’s website. With that in mind, we wrote the following user story:
- As a user, if I’m subscribed to the mobile app, I should be able to log in to the web so that I can access the web content.
Finally, let’s take a look at a set of three stories that would be part of the same epic. This epic deals with what users should be able to see on their dashboards once they log in (we’ll drop the “so that” in this case to simplify things):
- As a user, once in the dashboard, I need to be able to see the featured collections section.
- As a user, once in the dashboard, I need to be able to see the trending classes.
- As a user, once in the dashboard, I need to be able to see main featured videos.
In short, user stories are a way to simplify all of your app’s functionalities and help you define your project. They may seem like an unnecessary hassle when you’re eager to get started on a new project, but taking the time to write them will save you precious time later on in development. You can find more advanced information on user stories here.