Creating specs and describing a product’s functionality is the very first stage of any web development. The process of writing so-called user stories is crucial, even if a development team works with already given specs and requirements. A well-thought-out user story helps to define what to code and why and saves a lot of the dev team's time.
RELATED: Web development methodologies and approaches
You’ll learn what user stories are, how to write user stories, and who to delegate this process to.
What is a user story?
A user story is a list of functions that a product performs whether it is a mobile app or website. As Atlassian describes it, a user story is an end goal, not a feature, expressed from the software user's perspective.
User stories are one of the main methods of control in Agile. For instance, Extreme Programming (XP) features such processes as continuous planning (from Scrum) and customer involvement that are the necessary parts of writing user stories.
A user story answers the following questions:
- who?
- does what?
- does it to get what?
Who is an actor; a website or a mobile app user. This user is either a guest or a developer/product admin.
Does what is an action the user performs to reach their goal.
Does it to get what is the user’s goal of interaction.
For instance, a website visitor (who) may want to fill in a contact form (does what) to get in touch with a company regarding a project (goal).
The most important part of the user story is a goal. Goals are actions that the company wants its target audience to perform. If the company doesn’t understand which processes lead to these main actions, the product won’t work properly.
Let’s expand on the purpose of user stories.
Why are user stories important?
As was said before, user stories are lists of product functions. If a client doesn’t know exactly how a product should work, the user stories are to help to figure it out. If the client has an idea of the product’s work and the list of specs, a development team must hold a meeting regarding a vision of the product anyway.
The client and the team should be on the same page when it comes to the goals of product development and ways of achieving these goals. Otherwise, misunderstanding can happen, and a developer will create a feature nobody actually needs. Time loss, budget loss.
User stories are aimed at:
- delivering a product that the client really needs;
- budget estimation;
- time estimation;
- saving time on coding and giving clear tasks to developers;
- UI design.
User stories writing is a great service to offer clients. If a client doesn’t have time for creating user stories and defining so-called “use cases”, the development team in general and internet marketers in particular can deliver this service.
Use case VS user story
The mentioned term use case is a scenario that users are likely to follow when using the product. Use cases give a general overview of the product. For example, one person can use Facebook for reconnecting with mates and another person for doing business.
User stories clarify and detail how these use cases are implemented in terms of user actions.
How to write a user story
Who writes user stories?
User story creation involves several parties: a client, a development team, and customer representatives. It’s necessary that everybody stays in constant touch. If the client doesn’t have time for deep involvement, this role can be reassigned to the Product Owner (in Scrum) or to an internet marketer from either a client's or developer's side. Anyway, the client/stakeholder must revise these stories since they are the only person who knows the product market best.
Formula
A user story answers the following questions:
- who?
- does what?
- does it to get what?
The formula for a good user story looks like this: “I am as a user (role) want to (action) in order to (goal).”
Bear in mind that there could be several roles and you have to create user stories for all of them. Let’s imagine a situation where somebody wants to fill in the contact form. If it is a user who has an account, we have one story, and if it’s an anonymous user, the story will be different.
I advise you to separate all actors into groups: target audience, main group, secondary group, and others. After this, give unique names to each actor from these groups. Then you need to create stories from the perspective of these actors. It will help you realize which stories are necessary only for the actors from the target audience, and which stories are necessary for each group. You will be able to assign priority more correctly since the stories of the actors of the target group are more important to us.
It is better to write user stories on small sticky notes and keep them within sight while developing. If there are many user stories, it’s strongly recommended to store user stories online. You can use such user story tools as Online Visual Paradigm, Miro, and StoriesOnBoard. These services are a way to organize stories which gives a broader context and helps in planning releases. In other words, these tools are used for user story mapping.
Developing user stories
User stories are written at all development stages: before development, while shaping a product idea, during development, especially when a developer finds out that the story is actually an epic (large user story), and at the release stage (there could be unexpected difficulties during the transition).
The work on user stories must be continued even after the product launch. The thing is, the analysis of user behavior can highlight the irrelevance of previously approved user stories or show that they have nothing in common with real life.
That’s a red flag — it’s high time to order a UX audit from a seasoned front-end development team. This audit might lead to front-end code refactoring, Google Analytics optimization, and a meticulous check-up of the user interface.
RELATED: How to conduct a design and UX audit
Epics vs stories
Epic is the highest-level goal of a project that can be broken down into a number of smaller tasks called user stories. As Delibr describes the process, while user stories are typically added directly to the product backlog, epics usually take the route via a product roadmap or a discovery board, before being added to the backlog.
How to write good user stories
A good user story matches the INVEST model created by Bill Wake. According to this model, user stories are:
- Independent. Reduced dependencies = easier to plan.
- Negotiable. Details are added via collaboration between all parties mentioned above.
- Valuable. Provides value to the customer.
- Estimable. Too big or too vague = not estimable.
- Small. Can be done by the team in less than a week.
- Testable. Good acceptance criterion.
Use a rule of thumb to estimate a story’s size: if any single story takes more than 50% of an iteration (two-week or ten-day sprints), it should be broken into substories.
The last criterion is tricky enough, too. Let’s see what would be an acceptance criterion in the example given earlier: An anonymous website visitor wants to fill in a contact form to get in touch with a company regarding a project. The acceptance criterion here would be the possibility to fill in and send the contact form. Developers and clients could add extra technical criteria. Say, the user should be allowed to submit up to N contact forms a day.
Best user story practices
Good practices
- While creating user stories, engage the whole team which consists of a product manager, client/stakeholder, and even end-users of your product.
- Start writing stories from epics and then break them into smaller stories step by step.
- Identify user stories with numbers or letters.
- Indicate how much time is allocated for each story.
- Indicate priority if needed. If a client needs to release a high-fidelity prototype soon, give the highest priority to the main functions. Use cases will help you find out which user stories form the base of the product.
- Clarify user stories from a technical point of view, for example, how the product’s bugs should be displayed and processed (but do not include technical features in the story!). Usually, it’s a product owner who sets technical requirements and acceptance criteria.
Bad practices
- Using epics for tasks. Break them into substories.
- Using stories that were not approved by a customer group representative. Hold focus groups, and ask for a consultation.
- Breaking low-priority epics down into user stories. The chances are that it will be a waste of time.
- Including technical requirements.
- Making assumptions about a target audience.
Conclusion
I believe user stories should become a necessary part of the development process no matter what you stick to, Waterfall or Agile. It’s a simple and beautiful way of clarifying the product’s goals and functionality. A collaboration of different parties—users, product owners, and developers—gives a synergy effect and provides insights.
I love thinking that having read this intro into user story writing, you will apply this method at least on a small project and will be able to save your precious time. The most important things to remember are keeping the story short and simple (who wants to do what and why), involving users, clients, and developers, and setting detailed technical requirements and acceptance criteria.
Useful links
→ The Web development methodologies and approaches article will introduce you to the most essential development frameworks.
→ Writing Agile user stories is teamwork, learn more about tools for effective teamwork.
→ Creating user stories and building a website is a process of long-term communication with a development team. Learn how to be a perfect client:
