In one of the previous articles we examined a question of a development process and possible approaches (find the article "Internal development kitchen" at our website).
Now we would love to focus on the very first stage of the development - creating specs and describing a product’s functionality. A process of writing so called “user stories” is very 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 whom 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 is 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 a user stories creation.
A user story answers the following questions:
- does what?
- does it to get what?
“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).
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.
The most important part of the user story is a goal. The goals are actions that the company want their 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 is 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 scenarios 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 a business.
Writing user stories
Who’s in charge of writing
User stories writing involves several parties: a client, a development team and customers 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 Product owner (in Scrum) or to an internet marketer from either a client or a developer side. Anyway, the client / a 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 to 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 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.
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 week / 10 day sprint) it should be broken into substories.
The last criteria is tricky enough, too. Let’s see what would be an acceptance criteria 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 criterias. Say, the user can be allowed to submit up to N contact forms a day.
Good and bad practices
- 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 technical point of view (do not include technical features in the story!), for example, how 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 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. In the next paragraph we will tell you few tips on getting to know the audience.
There are different ways of studying one’s target audience. Besides discussing user stories with potential users and a client, we can use a few handy tools.
Webvisor tracks user’s visits and allows you to see mouse movements, clicks and forms completion, what text was copied. That service works for existing web sites, so it’s only possible to use if you write stories for product enhancement. Inspectlet does almost the same. Appsee is used for mobile apps visits tracking.
When it comes to a completely new product with undefined audience, we encourage you to examine competitors’ websites and get to know what their audience is with such tools as Similar Web, Alexa.
I believe user stories should become the necessary part of the development process, no matter what you stick to - Waterfall or Agile. It’s simple and beautiful way of clarifying product’s goals and functionality. 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 criterias.