en
plUser story – a useful tool in agile development
Alexa Trachim
Agile software development is practiced by most of the seasoned software houses on the market. That’s because it’s flexible, productive and effective. Many principles rule the stages of agile. We will discuss one of them in this article – a user story.
Table of contents
- What is user story?
– User stories structure - Why creating user stories is important?
- How to write user stories?
– Who writes user stories and why
– The 3 C’s of user stories
– INVEST - User story examples
- User stories – summary
What is user story?
A software development team can use their sophisticated terms to describe functionalities they create, but what actually matters it the user’s perspective. A user story is a simplified way to tell who is the person that will use our product, what do they want to achieve by using it and why they should choose it. A user story can define each requirement of the project.
What’s important is that the user story should be as simple as it can be. Usually, they are as long as one sentence. In agile development, they are put on sticky notes or index cards and glued to the wall or board when discussing the idea for a mobile or web app. Because that’s one of the primary purposes of user stories – to spark a conversation about the concept for the software project – how it should work, what it should offer and who will use it. User stories also help to work out the order of features development and the timeframe for the whole development process.
User stories structure
So as we mentioned, a user story needs to answer three basic questions: who, what and why. Then we build a sentence which goes like this:
As a <user>, I want <what> so that <why>.
Let’s explain a little bit each of these elements.
Who
Also known as a persona – most of the time, it is a characteristic of the end-user that will use our product, but not always. These do not always have to be your customers, but also internal clients or teammates that might have an insight on the outcome because they will use the system – as admins, managers, or customer service representatives.
What
That’s the goal that the user wants to achieve using the product.
Why
And here, we have a reason that the user wants to use this exact functionality.
Why creating user stories is important?
There are many benefits to writing user stories that should not be ignored. First of all, they give each task a context that should include the value that the team needs to pursue. The focus is moved to the user, which helps each member focus on what really matters – it’s not only about ticking to-dos off the list but also about solving people’s real problems.
With user stories, the team fires up their creativity and critical thinking. They can also find out common ground when working towards the end goals desired by the users. Each story is a pretext to move the project forward by enhancing motivation and morale. They are also an excellent tool for prioritizing tasks and avoid limitations that might happen when we determined features beforehand without analyzing how they could be implemented into the product. Finally, they can be helpful to make use of the previously collected user feedback.
How to write user stories?
There are a couple of rules that you might want to follow when you write user stories. First of all, you need to think: what type of user I want to consider when writing them. There are usually multiple personas the team and product owner should have in mind – as there is more than one end-user for almost every software product. When that’s the case, we need to write a user story or many user stories for each of them and every goal they want to achieve.
Then, define the stage when the action that leads to completing the goal is done. We don’t want our user story to keep the user in the middle of something, but rather to finish the activity with the predicted result. If the process is composed of smaller steps, you need a user story written for each of them.
You can also add details to the story using “conditions of satisfaction”, which are acceptance criteria that are used in agile user stories to determine what exactly is meant by the user. To simplify, they are rules that describe the conditions that need to be met to achieve expected results.
As for the agile software development team, there are also some things they should determine. Each user story should correspond with tasks and subtasks that need to be completed by a particular team member and you need to assign them while writing the user stories. Also, it is worth to discuss timeframes once more when working on each user story – as initial estimations might be not as detailed. Having your user stories on the board, you can see better how much time they will require to be developed into functionalities.
Last but not least, collect and analyze feedback from your potential customers or other end-users and write stories based on it. It is a much more productive way to get them written than playing a guessing game to find out what each type of user might desire.
Who writes user stories and why
Writing user stories should be a team effort. In well-executed agile projects, usually, everyone participates in this process. The product owner is claimed to be the key person, as the responsibility here is to keep the backlog of user stories for the whole development team. Although, we should understand that writing user stories is not as crucial as talking them through and drawing conclusions.
The 3 C’s of user stories
The agile team should know the three C’s that are the main components of user stories before they get written. This way, they can create them the way it’s supposed to be. Let’s see what each C means and why it is essential.
The card
The first C seems pretty self-explanatory. It’s the card you put the user story on. They are a part of the product backlog, but it’s important to understand that you don’t need perfect items in it to start discussing them. That’s what the cards in user stories are for – to spark the conversation between the agile team members.
The conversation
That’s the crucial part and primary purpose of user stories. The product owner and the development team need to talk about each story. What matters, it is usually a verbal conversation, but it can be supported by documentation, tests and other useful data. But we can’t forget about the spirit of user stories conversations – and that is to lively discuss each idea and how they can be executed.
The confirmation
Each story has its own “acceptance criteria”, which is the indicator that establishes if the action written on the card is done. Acceptance criteria need to be agreed upon by the whole agile team.
INVEST
Yet another rule that is used to determine if the story is written in a way that is understandable for the team and allows them to proceed with work. By the way, the INVEST approach can apply to all backlog items, not only user stories.
I – Independent
All user stories need to be independent of each other. It means that the features should also work without technical dependencies whenever it’s possible. That requires creative thinking, solving problems and agile development techniques to be applied.
N – Negotiable
We need to remember that user stories are not the same as requirements. They need some dose of flexibility. Each story should be open to discussions and changes before the production phase starts.
V – Valuable
Each user story should have the business goals written between the lines. So the acceptance criteria of the end result should definitely focus on achieving them. Not all results of the user stories will provide direct benefits to them. You need to find balance – give the users the end goal they are looking for and complete business needs you have in mind.
E – Estimable
The user story needs to allow the developers and other team members to estimate how long it will take to convert it into functionality.
S – Small
All stories need to be small enough to be completed as a feature within one agile sprint. It is considered a good practice to not put in the backlog items that are bigger than that.
T – Testable
The verification of each user story is important to see if it delivers the goal we determined. Testing acceptance criteria to see if the definition of finished activity is actually as it should be, needs to be a part of user story writing.
User story examples
Now you know how to write a user story and what should be the key elements to consider when creating them. Here’s a couple of examples that will showcase to you how the stories can look like.
As a user, I want to add pictures so my friends can see my achievements.
As a manager, I want to have insight into work statistics to analyze the progress of employees.
As Kate, I want to organize my notes to gain control over my work.
As Ryan, I want to have access to the administration panel to fulfill my duties as an administrator of the system.
As you can see, not all the people here are customers. Also, the last two examples of the stories have names – that’s because a common practice when creating personas is giving them personal information like name, age, or even details of their appearance. That helps to imagine even better what can be their goals and needs.
FAQ User Stories
Before the project starts, we need to know what has to be done. Discussing all the details during workshops is the best way to determine what kind of functionalities are desired by the product owner. We write them down using the user stories pattern because it’s convenient, straightforward and specific. We can prioritize and organize the list of stories, decide on each iteration, and then work step by step towards the final digital product. User stories creation is one of the practices often introduced in Agile Scrum workflows. Since itCraft team works according to this methodology, we write them to deliver perfect results successfully.
Theoretically no, but we recommend them, and that’s our standard practice at itCraft. They offer many benefits. First of all, user stories simplify the documentation and promote productive workflow. With the list of stories, we know precisely what each functionality should look like and how it must work to satisfy the end-user. We can look at the project and tell exactly which functions are crucial for the product and which ones can be done later or discarded. Every sprint focuses on different user stories, which helps the team to provide results quickly and efficiently. During the collaboration with itCraft, you will create user stories together with the team, giving you knowledge and control of the whole production process.
Because it’s the easiest way to describe a particular functionality. We know exactly who is doing what and why. It represents the user’s path to achieve a specific goal. This way, designers, developers and testers know how each part of the digital product should be built to make the navigation intuitive and logical. Usability is the key here. No one will use the software if finding information or doing activities is complicated. User stories focus on the goals of your customers and stakeholders. It’s a much better approach than writing comprehensive documentation with tons of hard-to-find data.
In Agile Scrum projects, the development team collaborates with the product owner when writing user stories. Why? Because you are the person that knows everything about your business, potential audience, competition and industry. Your insight is priceless. We want you to be a part of the process because it can help us build an ideal digital product suitable for your needs and goals. Of course, we give you our know-how and support. The only thing you have to deliver is information and ideas. Together, we can create something unique, a solution that will help you achieve all your business goals.
User stories – summary
If your dream is to develop custom software – like a web or mobile application, a website, or other useful product – you probably will work with an experienced software house that also hires a talented design team. And all companies like that use agile and scrum methodologies in their projects. User stories are written by them, too.
Understanding your customers and users better, achieving business goals by bringing value to them and mindfully building each requirement are enormous benefits of user stories. Be a part of the process and you will see that agile is a great framework to work with.
If you need a business partner that knows how user stories should be written and can use them in a software development project – contact us and we can talk about the details of your product. We will create the stories together and then bring them to life in the form of an app or other software.
Read more
Android app development technology – introduction to Kotlin
Why is machine learning a growing trend?
What is a cloud application?
How much does it cost to make a booking type app?
19 Apps built with Flutter Framework
