How to Write a User Story

How to Write a User Story

User stories are small pieces of a large puzzle just like the 1000 piece Naruto puzzle featured above.(It took my wife and I six months to complete!). They are an integral part of the software development process. If you work in Product management, Design or Development teams then user stories will become your constant companion 😀.  A good user story helps build a strong foundation for a successful release. It impacts the delivery of a product on time and on point.

You will find this article helpful if you are a:

1.Software developer who works on user stories
2.Engineering manager who leads the development team
3.Product designer who builds components that form part of the user story
4.Startup founder building the first iteration of your product
5.And of course, Product manager who will write ALL the user stories

You want to build out a product or a feature. Do you start writing out the user stories for the idea ? Not really!. For any idea to see the light of day there are a number of stages it needs to go through. It might seem cumbersome at times. But as your product grows and becomes more complex it will become increasingly important for you to have a system in place. The good news is that one already exists. In this blog we will learn how to get started on your user stories. You don’t jump from an idea to a user story. There is a lot going on in the middle. And we will help you build a path starting with:

1.Conducting user story sessions
2.Organising under the feature hierarchy
3.Using the user story template for writing consistent user stories
4.Applying the INVEST framework to do a sanity check on the user stories

Why do we need a user story

It’s a good question! Why can’t I just  go and start building software without a user story? Well, you actually can do that. In fact it happens way too often. But it doesn’t end well. Actually it doesn’t end at all.

In your head you might have an idea of the product or service that you want to build. As you spend more time building software you realise that there will always be more to build than what you can. It is true for software development as is for life.

A user story helps you take small concrete steps to achieve the vision of the product by helping you:

FOCUS on what’s important
AGREE on the scope of the product
PRIORITIZE the order of development
ALIGN  the different teams to achieve a common goal
ESTIMATE the effort required to implement the feature
TRACK  how close you are to completing your product goals
COLLABORATE with cross-functional teams on what it would take to complete the story
FIT all the moving parts of the puzzle together

You start with what is most important. Then move up to build layers of feature and functionality which enhance the user experience.

Who is the user story for

Product Manager

It enables the product manager to translate their thoughts into a living document. It is an important way for them to:

1.Get feedback on what they think needs to happen
2.Communicate the final expectation with the team


A user story helps them understand the needs of the end user. It becomes the source of truth for them. At any time during development if they get confused they look at the user story. If that doesn’t clear their doubts then they talk to the product manager.

Engineering Manager

It helps them estimate and track projects based on the resources available to them.


They use the user story to build out how the user will interact with the product.

Who writes them

This one should be an easy enough question to answer. But alas! its not. I have seen different people write user stories in different organisations- Product Managers, Business Analysts, Software Architects, Engineering Managers and Developers .

I am not a big fan of titles. So instead of titles let’s instead define the skills required to write a user story. A person writing the user story should have:

1.Empathy for users
2.In depth understanding of user needs
3.Grasp of the product vision and strategy
4.Understanding of the needs of the business
5.Competitive landscape
6.Working knowledge of the existing product and all its relevant features

This is in most companies a short description of the role/title of a “Product Manager”.

Key Elements of User Stories

User Driven/Persona

Each user story is driven by a user’s need. A particular type of user is always the focus of every user story. The completion of the story helps the user in some way, big or small, directly or indirectly. If you ever come across a user story that  you can’t relate to a user then make sure to highlight it.

A user doesn’t necessarily need to be the end user of your product. It could be someone from your internal team like sales, marketing or customer service.


As discussed above each user story has a purpose. At the completion of the user story that purpose should be fulfilled. If the user story does not achieve the desired outcome then it needs to be reworked. This can happen if performing the action does not result in the desired result.

Acceptance Criteria

Achieving the desired outcome is one aspect of a user story. It is critical . There will be many ways of  achieving this outcome. But only one way that is considered acceptable. These details have to be documented as part of writing up the user story and form the acceptance criteria.

Definition of Done   

When is a user story complete? Different people will give you different answers. Done could mean:

1.The developer has completed the story
2.The QA has tested the story
3.Designer has reviewed the story
4.Product Manager has reviewed the story
5.Regression is complete for the release that the user story is part of

It is important that everyone is clear on what DONE means. A common definition of done is:

The product manager has tested the user story along with the developer, QA and designer. The user story passes all the acceptance criteria. It satisfies both functional and design requirements.

Open/Subject to change

One of the goals of writing a user story is to provide the development team clarity on what needs to be done. But things might change. And that might impact the user story. Some common and acceptable reasons are:

1.The development teams finds that the user story is not technically feasible anymore
2.The current implementation will take much longer than expected
3.The needs of the business have changed.

While these are acceptable reasons you should always try and learn from them. If a similar project comes along in the future then you can apply your learnings to avoid the same situation again.

User Story Mapping

It is a method used by product teams to find ways to solve problems faced by users. You start with a blank canvas/board and map out their:

1.Journey through your product or service
2.Key actions and interaction
3.Challenges, bottlenecks that they face
4.Things that are nice to have vs. must have for them

You should do this exercise before building a new product and at regular intervals after the initial release. This will help you keep users needs front and center as the product grows and becomes more complicated.

Who do you invite for user story sessions?

Well the short answer is anyone who thinks they can help improve the user experience should be in these sessions. But doing a company wide user story mapping session is not practical. The following teams should be represented in these sessions:

2.Customer Success

We will discuss the user story mapping session in details in another blog in the future. In that we will go through a live example of how to set one up and run it like a pro.

User Story Mapping Example

Let’s forget about technology for a minute. What if you were asked to draw a user story map for a buying a shirt the old school way. Yes, the old school way. Ordering online is not an option here…hehe🤣 🤣 . How will you go about it? Here are some steps that come to mind:

1.Find a store that sells shirts
2.Go to store
3.Pick up shirt
4.Pay for it

Now this is just one way of doing it. This leads to the following questions.

1.Does the user have a car?
2.Can they use public transport?
3.What type of shirt do they want?
4.What is their price range?
5.Is there a particular brand they like?
6.Can they go to the store anytime?
7.How will they pay for it

We can go on and on with the barrage of questions. What will really help is if we knew WHO is going to buy the shirt. What their needs and wants are. What challenges they face. In short wouldn’t it be great if you had an in-depth understanding of your target user persona. That would really make your life easier, wouldn’t it 😜 ?

Let’s assume you have a spocifc user/s and can make informed decisions on the above questions.

Now lets map this user’s journey.

User Story Map for buying a shirt at a store

It has three levels.

Level 1 At the top is the overall goal/theme - in this example, it is to get a shirt from a brick and mortar store

Level 2 This goal is then broken down into three parts that chart the user’s journey, i.e.

1.Going to the store
2.Finding the shirt
3.Paying for it 3. This is usually called an Epic.

Each part is then further divided into their own smaller journey. Each part becomes a user story and describes the user action and its effect.

The cumulative effect leads to achieving the users goal.

Feature Hierarchy

Now that you have completed your user story mapping exercise, what’s the next step? You need to organize your work into Epics, User Stories, Tasks and Subtasks which is a great way of building products. Let’s look at each of them in detail below.(Learn more about this here)


It is a collection of user stories and tasks.

It is a way of organising large projects (new products, feature updates, etc) in a logical way. It enables us to:

1.Get a high level view of the entire project or a part of it
2.Identify gaps in requirements early on
3.Track development
4.Find issues with delivery

User Story

It is the most important part of an epic and spells out specific information on what needs to be done. We will look at user stories in more detail in later sections.


Sometimes in order to complete a user story additional things need to be done. For example- setting up a new server, upgrading an old library. These things are essential to the completion of the project. And therefore tracked as part of the Epic. In most cases you will discover them when you start discussing user stories with your development team.

User Story Template


As a user, I want to so that

Acceptance Criteria


This is by far the most popular format for writing a user story. It’s popular because it’s simple, everyone gets it, it takes the fluff out of the story and helps the team focus.

Lets try writing a user story for the user story map we created above


As a user, I want to be able to find the section of the store where shirts are kept so that I can choose the one I want to take

Acceptance Criteria

1.Shirt Section should be marked clearly so that the user can find it
2.Shirts of different sizes should be available
3.Shirts of different brands should be available
4.Shirts of different colours and patterns should be available


One of the biggest challenges I faced early on in my career while writing user stories was figuring out where it started and where it ended. Whether one user story that I had written was actually two user stories?And does it matter? In these situations I found the INVEST framework very helpful. INVEST helps you to do a sanity check on the user story you have written.

INVEST stands for Independent, Negotiable, Valuable, Estimable, Small and Testable.  Let’s look at what each part means.


The user story should be complete within itself. You should be able to perform actions in the story by themselves.  It should be complete within itself.


Software development can be confusing. On one hand you want to provide clarity and consistency to all teams. On the other you want to be flexible and pragmatic to the needs of the business. The following phrase sums up the product conundrum” Subject to Change”. If you have ever attended a product roadmap presentation you know what i’m talking about:). You should be able to change the scope of the user story based on your discussions with the team.


The user story should have a positive impact on the user and the business. Some example of value/impact are:

1.Time saving
2.Ease of use
3.Solving a problem
4.Improvement in user experience
5.Increasing revenue for the company
6.Reducing Churn

Value can be direct or indirect. A user story is generally part of a theme that relates to the larger goals of the organisation.


The development team should be able to look at the user story and tell you how much effort it would take to deliver. Sometimes this might require them to undertake technical analysis. If your user story has incomplete information or leaves certain things open to interpretation then you will not get a fair estimate. In such cases the user story is considered incomplete and needs to be reworked by the product manager.

This does not mean that as a product manager you will have all the answers from get go. That will not be the case nine out of ten times. In most cases your user story will be a starting point for you to discuss with the team what the desired outcome is. Based on that discussion you will update the user story to its final form.


Smaller stories are easier to track, test and manage. They also mitigate risk in case things need to change. So whenever you write a user story ask yourself this question. Can I break down the user story further while adhering to the INVEST framework.


Once complete you should be able to test a user story. Sometimes it might not be possible to test it in its entirety but your team can build test cases to validate it to the extent possible. You can test whether the feature works as expected. The desired impact can only be validated by the market with time.


I hope your user stories end up being shorter than this post 🤣 🤣 .  Whenever in doubt go back to your user story maps, talk to your users and teammates. You don’t have to get it right the first time. What matters is that your user story is helping make those incremental improvements to your users.

You may also like