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:

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:

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:

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:

Developer/QA

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.

Designer

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:

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.

Outcome

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:

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:

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:

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:

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:

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

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.

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.

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)

Epic

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:

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.

Tasks/Subtasks

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

Description

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

Description

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

INVEST FRAMEWORK

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.

Independent

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.

Negotiable

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.

Valuable

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

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

Estimable

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.

Small

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.

Testable

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.

Conclusion

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.