User story – a useful tool in agile development

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

1. What is user story?
   – User stories structure
2. Why creating user stories is important?
3. How to write user stories?
   – Who writes user stories and why
   – The 3 C’s of user stories
   – INVEST
4. User story examples
5. 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 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.

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