At Moqod, we use the Agile approach which is very user-centered. With every software development project, we focus deeply on the user persona and on solving his needs.
What are user stories in Agile?
It is in the name — user stories are all about the user. At Moqod, we use the Agile approach which is very user-centered. With every project, we focus deeply on the user persona and on solving his needs.
User stories in Agile are simple descriptions of a feature from a user’s point of view. They are a sentence or two with minimal detail and plain language that describe the user, his problem, and its solution.
In Agile, user stories can have a different level of detail. Larger stories (epics) can be decomposed into smaller stories. User stories usually start large and high-level. During the process and through iterations, they become more and more detailed.
Regardless of its size, each user story contributes to the overall value of the project.
User stories formula
The standard user stories format consists of three parts:
As a user (user persona) …
I want …
So that …
It is the Agile version of the journalist formula ‘Who, What, Why’. By getting into the detail of the user stories trifecta, we get the following:
As a user … Who is the feature for? Who is the user? By this point, we have identified our end customer and we can describe him clearly and concisely.
I want … What is the intention of the user? Here we get into the user’s mind — what is that he wants to do?
So that … What is the big ‘pain’ of the user? What are the final goal he is trying to reach and the problem he is trying to solve?
Important: We write user stories only from the user’s point of view. We don’t adjust the user’s action to what we are trying to implement as a feature. The way to get into the user’s way of thinking is to use Story Mapping — the process we have detailed in our other articles.
The key to getting the user stories right is to think from the user’s point of view. However, it is next to impossible to put yourself into the end user’s shoes if you are trying to elaborate a user story on your own. This is when teamwork comes into play.
User stories allow all the stakeholders to get on the same page and share their understanding of the process.
User stories example
With the above formula, some of the examples of applying the user stories could be the following: Waterfall model
- As a full-time working gym member (detailed user persona), I want a 24/7 gym card so that I can work out on the weekends (solving the problem of not being able to work during the week).
- As a messy person, I want a cleaning service app so that I can call a cleaning lady when I need to.
- As an organized student, I want a digital agenda with an alarm clock so that I can track my time and work in sprints.
At the end of the story, there is always a solution to the problem a certain type of user is searching for. The user story describes the completed task for the user: the what, not the how. Each team member should be writing their stories with the solution for the customer’s problem in mind so that it is visible to the rest of the team.
At Moqod we work very closely with user stories and we would be happy to explain further how they can be beneficial to your project.
When are user stories written during the development process?
The step that goes before compiling user stories is defining user personas. Qualities, demographics, geographical location, interests, occupation, hobbies, challenges, and pains — the deeper you go, the better understanding of the user persona and the issues you will have.
Since the user stories allow to break down the large process into further smaller parts, usually the story-writing meeting takes place at the beginning of the project. This allows getting the whole team on the same page from the first day.
However, there is no restriction on writing all the user stories in the beginning. The beauty of the Agile method is the possibility to go back and review the sprint, get feedback, add changes, edit the story (or write a new one).
New stories can also be written by anyone, at any time.
What are the benefits of the user stories?
From the development point of view, user stories help define the feature with clarity, so that it is understandable by the product owner and every team member. We are avid fans of user stories for many reasons that positively influence every part of the process.
5.1. User stories are easy to create and available to any stakeholder
The simplicity of user stories makes them accessible to everybody in the project. Anyone with an understanding of how the user personas and the product approach work can write a user story.
The clarity of the user story and the plain language makes it understandable to the other parties. As a result, anybody can contribute to any user story to reach a refined user-oriented result.
User stories also help to align the product owner with the team and explain why a certain feature he has in mind is not implemented right away.
5.2. User stories create a shared understanding and cross-team clarity
By getting everyone in the same room to work on the user stories from the very beginning, every party of the future product gets on the same page. User stories encourage the participation of every member. They also serve as a connection between those who generate the ideas and those who execute them.
The developers and business-oriented stakeholders may speak a different language. User stories encourage communication and transparency between all team members. They serve as a translator and an intermediary where both sides can understand what the other side means.
Clarity and accuracy at the beginning of the project save time and money in the long run.
5.3. User stories allow to evaluate the workload estimate
User stories are an indispensable part of the Agile method. Working in sprints where each sprint focuses on a user story (or part thereof) helps with the visibility of the workload for the upcoming weeks. The key here is to make sure the dev team sees the end of the user story so that they can estimate the amount of work to put into it.
This is why we also recommend making sure that most of the user stories have been talked through during the sprint planning.
With this type of calculation, the progress happens faster and the team can work more efficiently.
5.4. User stories help to prioritize the tasks
At the beginning of the project, all features and related tasks may seem important. They probably are, however, the process can show that some of them are obsolete, not essential, or can be done at the last moment. Some of the alterations can happen during rapid prototyping which happens after user stories.
Certain features are irrelevant and unnecessary at the planning stage. By prioritizing user stories when/after writing them, the team can focus on what has to be implemented during the first steps and what can be polished later.
5.5. User stories establish the connection with the user
User-stories are a very user-centric tool. As we often say: “You are not your perfect user”. The connection with the perfect user happens through making the whole team participate in the project, gathering feedback from actual users via rapid prototyping, and tailoring the stories to real users with their problems.
This connection is crucial if you want to sell the product for users, not for you. They also help step back and look outside the box on what you may have missed.
5.6. User stories save money and time in the long run
Even if working on each user story can seem meticulous in the beginning, it is worth it. Let us look at it this way: you are constructing a house. With every layer, you check whether the bricks fit well. If they don’t, you adjust them, change the bricks or happily proceed with the next layer if they do.
Each layer here is a user story. Small detours keep your mind sharp and your attention focused.
Another option is that you decide to check what the whole house feels, looks like, and costs in the end. You find out that one of the layers in the middle is uneven and makes the whole wall look bad. By going back to fix it, you will find yourself with a larger bill and lots of lost work hours. And half a house to rebuild!
5.7. With user stories, the user always wins
Key elements of agile engineering, user stories are a solid magic wand when it comes to customizing the product towards the perfect customer. With each solid user story and feedback on it, your team gets one step closer to the product your end-user is looking for.
Conclusion
If you would like more information on how we work with user stories, how we could help you integrate them into your business model, or anything else, please contact us and we will be happy to help!
