Tag: temptag

What are user stories?

User stories are tightly connected to software system requirements, and some people think they’re the same thing, but they are not.

A user story is a general and simple description of a feature from a user’s perspective. It usually consists of three elements:

• Persona
• Purpose
• Need

While software system requirements are focused on features and functionality above all else, user stories are there to prioritize the customer perspective of the product. What does that mean?

Features and technical requirements answer the question “how”. User stories answer the question “why”.

Diving into technicalities and all the intricacies of implementing features is very easy during software development. They answer the question “how.” On the other hand, user stories answer the “why” of each feature — why does a person need it? What problem does this feature solve? What type of user you’re catering to?

User stories help the whole development team adopt the user or customer mindset while implementing the functionality and developing the best solutions for each potential request and need.

User stories and epics in Agile development

In Agile development, you’ll see the terms “user story” and “epic” equally frequently. So, what are epics? 

Epics are large tasks that string across sprints, teams, and even projects. They usually contain full segments of a software product. To make them manageable, they’re divided into user stories that are easy to implement one at a time.

An epic consists of:

• An introduction that describes the goals and reasons for creating a product or its part
• A product requirement that explains in detail what’s to be designed, built, and released
• A technical requirement that explains the technologies, tools, and frameworks that will be used during the development
• A design requirement that shows what the product will look like

Just like user stories, epics need to be flexible and have room to change depending on customer feedback, market changes, business need changes, team workflow, etc. 

What user stories look like: Examples

As I stated earlier, all stories share the same three elements that create a simple template:

• Persona — who is your user?
• Purpose — what outcome do they want to achieve?
• Need — why do they want it?

So, a typical user story looks like this: As a [persona], I want to [action] to achieve [purpose]. 

To write a story, you need to get in your user’s shoes, define their objective and figure out what action would lead them to fulfill their need. Let me give you a few examples. 

Example 1. E-commerce app

“As a buyer, I want to store my credit card information in the app so I make my next purchases fast.” 

Example 2. A mobile bank

“As a mobile bank customer, I want to log in to my app with biometrics, so I don’t have to type the password each time.”

Example 3. An mHealth app

“As a patient, I want to search for doctors by location so that I can choose the nearest specialist.”

As you can see, user stories are concise and don’t have many details. How exactly can they help your future product? Let’s find out.

The benefits of writing user stories for your product development

After you’ve spent time on a target audience and market research and tied it all together into a project plan and a technical specification, it may be hard to see value in writing user stories. After all, you already know what features your product will have.

User stories, however, are an invaluable tool that helps you create a truly remarkable product and keep al your team members on the same page and focused on the outcome rather than the mere process of feature development. 

Let’s talk about the benefits of creating user stories in detail.

• Main focus on users. User-centric products win the game, and user stories are the tool that can keep each team member focused on customers. This determination to solve problems will pay off in greater engagement, loyalty, satisfaction, and, consequently — greater revenue for your business.
• Improved collaboration. User stories give a team a clear goal, and they can work together to find the best solution.
• Creative problem-solving. Stories present an issue that has multiple ways of solving it. This drives critical thinking and creativity.
• Enthusiastic development process. The main element of motivation is a clear, manageable challenge. Each time a team overcomes it, they become more enthusiastic about solving the next one.

User stories have many benefits, but do they have any disadvantages? Let’s take a look.

Challenges in writing user stories

User stories seem very easy to write, but are they really? How do you write a user story correctly? When writing them, you must look for a few things to benefit your project rather than confuse your team. 

• Lack of clarity. User stories are short and informal, often making them pretty vague, especially if the feature is complex. 
• Narrow focus. Each story represents a single requirement, and this narrow focus can cause the team to overlook the bigger picture. 
• Time-consuming. Writing a good user story requires research and communication with all the stakeholders, so it may seem like too much of a time investment, especially in a fast-pacing development environment. 

All these challenges can be overcome by the involvement of an experienced product manager who keeps the team focused on delivering a coherent product and handles communication between the technical specialists and the stakeholders.

Who writes user stories

Before we dive into the process of writing user stories, let’s discuss who’s responsible for it. 

In the agile team, anyone can and should write user stories, participate in discussions, and provide feedback. The product owner role is to take ownership of this process. They don’t necessarily write all stories. Still, they keep track of the backlog and ensure they’re written in each sprint.

Let’s now talk about how to write a user story and go through the step-by-step process of creating user stories.

How to write compelling user stories: step-by-step guide

Step 1. Create user personas

The first step is to understand your end-user. For this, you can use several product management techniques. One of them is the user persona. 

A user persona is a general representation of your typical user. It includes their lifestyle, needs, desires, pains, and passions. You can make it as detailed as giving this persona a name and a face so that you can empathize with them better. 

If you have several personas, make sure to create separate chains for each.

Step 2. Define the acceptance criteria

Everyone on your team should know the criteria for a completed story. Usually, it’s finalized when the customer fully reaches the goal through some actions. Learn how to write acceptance criteria in software development to get a clearer idea of what they look like.

Step 3. Divide epics into smaller stories

To not lose sight of the big picture, start your project with epics. To make them manageable, you need to divide them into user stories.

Step 4. Write tasks in strings

One feature usually has multiple user stories if you write them correctly and dedicate one story to a single action. 

That’s why it’s important to write user stories in order. For example, in an ecommerce app, a large action like “buying a product” consists of small actions like searching, using filters, comparing, adding a product to the cart, adding credit card information, and checking out.

Step 5. Gather feedback

After your stories are ready, run them through your team members, stakeholders, and even end-users, who can give you ideas through reviews or during focus group sessions. 

Discuss your user stories with your development team to come up with the best technical solutions for each task.

Step 6. Plan your user stories across sprints

Each story should be completed in one sprint, so it’s important to estimate your user stories realistically and split them into smaller bits if they’re too large or dedicate a separate epic for them. 

How to incorporate user stories into your development process

So, you’ve written the user stories for your product. How do you integrate them into your current workflow? 

Usually, after the stories are reviewed and finalized, a project manager gets together with the team. They decide what stories will be covered in the next sprint and discuss the required requirements and functionality. 

Once it’s settled, a product manager or another team member adds requirements to the story. This procedure repeats before each sprint, so everyone knows the sprint goals.

Because each story should be completed in only one sprint, it’s necessary to estimate the stories and categorize them by complexity, urgency, and time required for their completion. 

What makes a user story effective

According to best practices of product management, an effective user story has several criteria that can be described by the acronym INVEST. This means:

• Independent — although stories can be grouped and put in order, each should be independent of others. A team should be able to work on each story in no particular order.
• Negotiable — good stories are always agreed upon and discussed and include the interests of both users and product owners
• Valuable — user stories should bring value to your customers and your team
• Estimable — your team should be able to estimate the time needed for each story accurately
• Small — each story should take no more time than one sprint
• Testable — you need concrete acceptance criteria for each story so that a QA team can test it and make sure it corresponds to the expectations of both users and stakeholders

We’ve talked about user stories creation. Let’s now find out how to write a good user story that really makes a difference to your product.

Extra tips for writing effective user stories

Focus on users first

It’s important to strike a balance between customer expectations, stakeholders’ interests, and other factors like resources available, technological possibilities, restrictions, etc. Product development is complex, and lots of things need consideration. 

However, in user stories, you need to focus on users and look at your product from their perspective.

Use cards

You can use paper cards with your team. This will help you keep them short and sweet and make collaborating easy. Just lay them out on the table or pin them to your board, and let the team add their ideas.

If you can’t use physical cards because you have a remote team or for any other reasons, use tools with virtual cards like Jira, Trello, etc.

Treat user stories as guides

User stories aren’t enough to build a product. They can’t replace requirements and specifications. Rather, they help you get in your customers’ mindset, guide your team, and ensure each feature you develop has a clear purpose that meets your users’ needs.

User stories are short and informal, so they don’t contain any technical details that also influence the product development process. You will still need technical requirements describing frameworks, architectural patterns, libraries, tools, databases, etc.

Final thoughts

User stories are an important part of agile user-centric product development and design. They help you to focus on users and make each feature purposeful and effective. In this article, you’ve learned how to write great user stories that positively impact your product. 

We at Mobindustry use them to ensure our client’s products are welcomed by users and bring success through higher engagement, satisfaction, and efficiency. 

If you’d like to build a product but are unsure where to start, don’t hesitate to contact us. We’ll immerse deeply into your target audience’s pains and needs to deliver the best product possible. All members of our team know how to write effective user stories and then turn them into a fully-fledged product.