In one of the previous articles, we examined a question of a development process and possible approaches (find the article "Web development methodologies and approaches" in the end of the article).
Now we would love to focus on the very first stage of the development - creating specs and describing a product’s functionality. The process of writing so-called “user stories” is crucial, even if a development team works with already given specs and requirements. User stories help to reveal what to code and why and saves a lot of time on development.
You’ll learn what the user stories are, why write them and who delegate this process to.
What is it
User stories are the list of functions that a product does, whether it is a mobile app or a website. User stories are one of the main methods of control in Agile, for example, Extreme Programming (XP) features such processes as continuous planning (from Scrum) and customer involvement that are the necessary parts of user stories creation.
A user story answers the following questions:
- does what?
- does it get what?
“Who” is an actor who stands for 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 does in order to reach his / her 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).
I advise you to separate all actors into the groups: a target audience, the main group, the group of secondary importance, and others. After this action, you should give unique names to all actors from the groups. Then you need to write stories from the perspective of these actors, indicating their unique names. It will help you to realize which stories are necessary only for the actors from the target audience, which stories are necessary for each group. You will be able to build a priority more correctly since the stories of the actors of the target group are more important for us.
Such user stories are better to write on the small sticky pieces of paper and keep within a reach of eyesight while developing. If there are many user stories it’s strongly recommended to keep the user stories in the electronic device.
You can use the user stories online tools such as Online Visual Paradigm, Miro, StoriesOnBoard. These services are a way to organizing stories that gives a broader context and helps in planning releases, in other words, these tools of user stories mapping.
The most important part of the user story is a goal. The 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, so the product won’t work properly.
Let’s expand on the reasons why we should pay attention to user stories.
What do we write user stories for?
As was said before, user stories are a list of product functions. If a client doesn’t know exactly how a product should work, the user stories are to help to comprehend. If the client has an idea of the product’s work and the list of specs, a development team must anyway hold a meeting regarding a vision of the product. The client and the team should be on the same page about 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.
The 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.
The user stories writing is a great service to offer to the client. If the client doesn’t have time for the user stories and for defining so-called “use cases”, the development team in general and internet marketer, in particular, can deliver this service.
The mentioned term “use cases” is the scenario that users are likely to follow when using the product. They give a general overview of the product. For example, one can use Facebook for reconnecting with mates and another for doing business.
Writing user stories
Who’s in charge of writing
User stories writing involves several parties: a client, a development team, and customer representatives. It’s necessary that everybody stays in touch permanently. If the client doesn’t have time for a constant involvement, this role can be reassigned to the Product owner (in Scrum) or to an internet marketer from either a client or a developer side. Anyway, the client / stakeholder must revise these stories since he/she is the only person who knows a product market best.
A user story answers the following questions:
- does what?
- does it get what?
The formula for the good user story looks like: “I am as a user (role) want to (action) in order to (goal)”.
Bear in mind, that there could be several roles and then you have to write the user story for all the roles separately. Let’s imagine a situation when somebody wants to fill in the contact form. It is a user with an account we have one story, and if it’s an anonymous user - the story is different.
The user stories are written at all the development stages: before development, while shaping a product idea, during development itself, especially when a developer finds out that the story is actually an epic (large user story), and at the release stage for the reason that 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 irrelevance of previously approved user stories or show that they have nothing in common with a real life at all. That’s the red flag - it’s high time to order a UX audit from a seasoned front-end development team. This audit might result in front-end code refactoring, Google Analytics optimizaton, and the meticulous check-up of the user interface.
A good user story matches the following model called “INVEST” created by Bill Wake:
- Independent. Reduced dependencies = easier to plan;
- Negotiable. Details added via collaboration (with all parties mentioned above);
- Valuable. Provides value to the customer;
- Estimable. Too big or too vague = not estimable;
- Small. Can be done in less than a week by the team;
- Testable. Good acceptance criteria.
Use a rule of thumb to estimate a story’s size: if any single story takes more than 50% of an iteration (2 weeks/10-days sprints) it should be broken into substories.
The last criteria are 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 criteria here would be a possibility to fill in and send the contact form. Developers and clients could add extra technical criteria. Say, the user can be allowed to submit up to N contact forms a day.
Good and bad practices
- Write user stories engaging the whole “team” which consists of a product manager/client/stakeholder or 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 this story.
- Indicate priority, if needed. If a client needs to release a high fidelity prototype soon, put the highest priority to the main functions. Use cases will help you to find out which user stories form the base of the product.
- Clarifying user stories from a technical point of view (do not include technical features in the story!), for example, how the product’s bugs should be displayed and processed. Usually, it’s a product owner who sets technical requirements and acceptance criteria.
- Using epics for tasks. Break them into substories.
- Using the stories that were not approved by a customer group representative. Hold focus groups, ask for a consultation.
- Disaggregating low priority epics into user stories. The chances are that it will be a waste of time.
- Including technical requirements.
- Making approximations about a target audience.
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, developers - gives a synergy effect and reveals users’ insights. I love thinking that having read this intro into user stories writing, you will apply this method at least at the small project’s part 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, developers, and setting detailed technical requirements and acceptance criteria.
Learn more about all stages of creating websites here.
The article "Web development methodologies and approaches" will introduce the most essential development frameworks to you.
Writing user stories is teamwork, learn more about tools for effective teamwork here.
Writing user stories and creating a website is a process of long communication with a development team, learn how to be a perfect client here: