How to Write a User Story in Agile?

Wondering how to write a user story in Agile? Many entrepreneurs and project managers need help with creating user stories in the course of Agile software development.

Let’s talk about the steps to create user stories.

1. Understand what a user story is

Gain a thorough understanding of what an Agile user story is.

1a. A practical definition of user stories in Agile

In its essence, an Agile user story is a piece of work in a project. This piece of work should represent value to the real users of the product. A product development team should be able to deliver this piece of work in one “sprint”, and a “sprint” is one iteration in the “scrum” framework.

1b. A user story is not a functional requirement

Before you write user stories, you should also understand what they are not. A user story isn’t a functional requirement in a software development project.

Furthermore, a user story isn’t the description of a product feature. Effective user stories don’t contain the details of product features.

1c. Why create a user story at all?

Why do Agile user stories exist? The answer lies in the first of the twelve principles behind the Agile manifesto. This principle is as follows:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.

You can create functional requirements for your software development projects. You would capture the product functionality in them, and these requirements would describe the product features.

Get a complimentary discovery call and a free ballpark estimate for your project

Get Started

Trusted by 100x of startups and companies like

Software developers in your team are the primary users of these documents. If you ask end-users to read them, they might find too many confusing and ambiguous terms in them. After all, end-users aren’t software developers.

Agile is a user-focused framework. User stories serve to bring the focus squarely back to your target group of end-users. They define the value from the end-users perspective. User stories will remind developers in your team what the end-user needs are.

1d. Who writes Agile user stories?

Agile teams commonly follow a practice where the “product owner” writes user stories while other team members collaborate. That’s because product owners write the “product backlog”.

You need to ensure that the product owner doesn’t write them in a silo. Effective user stories need inputs from as many relevant people as possible.

Therefore, encourage others in the team to provide ideas. Team members from the business side should certainly provide input.

1e. How does a user story help in your Agile project?

In addition to keeping the team focused on the needs of end-users, user stories offer the following advantages:

• They help teams to collaborate. A key principle behind Agile frameworks is the collaboration between business stakeholders and software developers. Both developers and users can easily understand good user stories, which creates a shared understanding. This facilitates collaboration.
• User stories foster creativity. When team members think in terms of delivering tangible value to users instead of the technology, they are unshackled! They can come up with more creative solutions.
• Team members get the taste of “small wins” by delivering user stories. Each Agile user story represents a value delivered to users via a functional product. Teams achieve milestones even if they deliver smaller user stories. This builds momentum, and nothing works like success!

Refer to the Atlassian guide to user stories for more information.

2. Understand the Criteria to Write Good User Stories

What makes a great user story different from a passing story that “also-ran”? A great user story requires the following attributes:

• “Independent”: You can develop this user story independently, and it doesn’t depend on other user stories.
• “Negotiable”: The team decides the implementation details. You don’t insist on a rigid style of working or workflow. The best Agile teams are empowered.
• “Valuable”: You deliver tangible value to end-users by delivering a user story. It should translate to real-life value for users.
• “Estimable”: Your team should be able to estimate the work required to deliver a user story, i.e., it should be able to estimate the number of story points. In other words, a user story shouldn’t describe the work vaguely.
• “Small”: You should be able to deliver an Agile user story entirely within the duration of one sprint.
• “Testable”: Great user stories must have clearly defined acceptance criteria. You should be able to test the product against these acceptance criteria.

Bill Wake had proposed these criteria in an article written in 2003. The acronym “INVEST” is used for describing these criteria. Product owners ensure that user stories meet these criteria.

3. Study the established user story template before writing user stories

Many Agile development teams use a common user story format known as the “Connextra format”. The user story format looks like the following:

“As a type of user I want to perform an action so that a benefit occurs”.

In this simple user stories template, you need to replace the words in bold letters with the specific details of your project.

Take the example of a dating app. Let’s assume that a user story describes why users want a profile picture. The user story can be the following:

“As a dating-app user I want to upload my profile picture so that people know that I am a genuine person”.

Notice how the user story uses non-technical language. Also, notice how the user story leaves out all the technical details.

4. Understand why you might need to group multiple Agile user stories together

A product manager might want the team to take a large chunk of work in the course of an Agile development process. The team can use a concept called the “Epic” in that case.

An Agile epic is a large volume of work, and you can break it down into smaller stories. A single story is the smallest unit of work, and an epic is a logical grouping of stories.

An epic has a strategic objective. It meets a set of high-level requirements of customers. User stories within an epic share the same strategic objective and high-level requirements.

You might have multiple teams working on different user stories within an epic. Often, you deliver an epic in multiple sprints. An Epic might even span across different projects.

Refer to the Productboard guide to Agile epics for more information.

5. Review user story examples

So, how do the right stories look like? Review the following user story examples to understand this:

• User stories from “Enable Quiz (Startup)”: Alex Brown, an entrepreneur, and advisor has published user stories from “Enable Quiz”. It’s a great example of how a user story describes what the end-user needs.
• User stories from “HVAC in a Hurry (IT Project)”: Alex Brown has published this user story. It’s an example of stories users can relate to. It uses an active voice. You can associate tasks with the needs of the user if you follow this standard.
• User stories published by ProductPlan: ProductPlan has published good examples of user stories where tasks bring important context for the developers. Developers can understand why a particular user role needs certain capabilities/features.
• User stories examples by Upgrad: Upgrad has published user stories examples that show how capabilities requested by users will help with their day-to-day work.

6. How to write a user story in Agile: The key steps

What are the building blocks of great user stories? How do you ensure your user stories provide sufficient inputs for sprint planning? What can you do to put users in the center of the project instead of being bogged down by the details of a software feature?

Take the following steps to write great new user stories in agile:

6a. Visualize the real users of your product

Writing a good user story must start with an in-depth understanding of the end-user. Study and understand the following:

• Who are the end-users?
• What do they need to achieve?
• Why will they use your product?

I recommend you develop a “buyer persona” for your end-users. A buyer persona is a fictitious person created using real insights about the market, demography, etc. Refer to the HubSpot guide to buyer persona for more details.

6b. Define the user action

The next step in writing user stories is to define the action end-users will take. How will end-users interact with your product?

You should concentrate on one action when writing stories. If you consider multiple actions, then you should write multiple Agile user stories.

You should write about the intention of the user, and you should avoid confusing and ambiguous terms. You should leave out all the technical details at this stage.

6c. Define the “value” to end-users

User stories serve to define the “value” from the users’ perspective. You should define what the end-user gets by using your product.

If you can’t clearly define the value for a user story, then you need to go back to the drawing board. You need to gain a deeper understanding of what your users need.

The value of a user story should also correlate to one or more of your business goals. You should see improvement in one of the important product management KPIs like retention rate.

6d. Conduct a Q&A session to discuss the user story

You should conduct a Q&A session to discuss user stories. The product owner should explain a user story in detail and answer questions. You should use this session for defining acceptance criteria too.

This step directly leads to a brainstorming session with the development team. You should discuss and finalize the implementation details in this session.

Note: Refer to the Easy Agile guide to user stories for more details.

7. Follow the relevant best practices to write a good user story in Agile

Writing a great user story requires you to consistently follow a few best practices. These are as follows:

• Focus on the end-user: Agile is a user-focused framework. Make the end-user your first priority.
• Use “User persona”: The use of “user personas” helps you to understand your users better. You can then write better user stories.
• Collaborate: The product owner and the developers should discuss user stories together instead of working in silos. Use drawing boards and sticky notes to enable team members to collaborate.
• Write simple user stories: I can’t overstate the importance of simplicity. Avoid confusing and ambiguous terms.
• Analyze user feedback on earlier prototypes: You might have done a prototype earlier. What did the users say about it? Take that into account.
• Review and refine user stories: Ensure that one user story isn’t too big. You should be able to deliver it in one sprint.
• Define the acceptance criteria: Spell out clear and measurable acceptance criteria.
• Provide visibility to user stories: Put up user stories on the wall so that your entire team can see them.

Refer to the tips to write user stories from Roman Pichler.

Planning to Write a User Story in Agile?

Want help with your Agile development project? Contact DevTeam.Space, and a dedicated account manager will contact you to explain how we can help.

FAQs on How to Write a User Story in Agile