An introduction to user stories for product managers

Published in

Agile Insider

6 min readSep 22, 2020

A sticky note showing an example of a user story — Introduction to User stories: Image by smaato

Good relationship are always a two way street.

The same holds true for the relationship between the customer and the product manager. The PM must care deeply about their customer, understand their needs and patiently listen to them. Only then can they expect to receive customer love in return.

To make this romance flourish, you have a handy tool called user stories at your disposal. In the coming paragraphs we will see how user stories can be leveraged to make your life easier and solidify your relationship with the customer.

User Story is an informal and simple explanation of a feature written from the end-user’s perspective. — Atlassian.com

Every feature in the product is the means to an end for the user. It exists to fulfill certain needs and achieve a specific goal. A user story is an articulation of this fact.

For example, user story for the ‘like’ feature of Facebook could be:

As a user, I want to be able to react to my friend’s status so that I can show appreciation for them.

Importance of User Stories

User stories are not just a fancy way of specifying something. In fact, it is the perfect way of specifying what the user wants and why do they want it.

They have the obvious benefit of providing a nice and structured way of articulating the user needs & goals. However, the benefits go far beyond this. They help in the following ways:

Promote user centricity by putting the user at the center of the conversation. Features become the means to end and not an end in themselves. When you make it about the customer, nobody can disagree unless they have a very strong reason.
Prevents communication gap by capturing the user need precisely. They ensure that the stakeholders — design, engineering, management and sales are on the same page. Otherwise, lack of clarity on the problem being solved leads to a lot of rework and unnecessary iterations.
Boost creativity by providing clarity on the problems being solved. When we focus on solving a problem rather than building a feature, it gives us much more room to maneuver.
Helps in prioritization by ensuring that unecessary feature requests are weeded out. Anything which won’t help the user in a tangible way won’t pass through the user story test. Additionally, the strength of the user need can help in understanding its relative importance for the user.
Provide context to the engineering on why a certain feature is being built. User Stories represent a single unit work when broken down appropriately. This can benefit the team in planning and prioritization. It is thus considered a crucial component of agile software development.

Format of a User Story

A meme showing an example of an Agile family using a user story — Good User stories should be phrased correctly: Image by geek&poke

The most popular template for structuring a user story is the following sentence:

As a <User X>, I want <functionality Y> so that I <achieve goal Z>

The three variables can be understood as follows:

User X — signifies the user persona that is requesting the functionality.

Functionality Y — signifies the behaviour/functionality the user needs.

Goal Z — Signifies the need the user wants to get fulfilled through the specific functionality.

Examples of User Stories

Let us write some user stories for a passenger using a ride hailing app such as Uber.

As a passenger, I want to know the estimated arrival time for a cab so that I have an idea of how long do I need to wait.
As a passenger, I want to know the total fare so that I know how much the trip is going to cost me.
As a passenger, I want to be able to call the driver so that I can co-ordinate with them if required.

Using User Stories for building new features

A meme showing how user stories could be an EPIC as well — User Story for a feature should be treated as an EPIC

A User story usually represents a single unit of work. Sometimes, developers may not have the luxury of shipping individual user stories in isolation. The unit of work for development is usually in terms of features.

A feature can be seen as a group of user stories packaged together to deliver a functionality.

For example, you want to build a “payments” feature for your mobile app. This can be articulated using the following user story: As a user I want the ability to pay so that I can buy stuff using the app. Clearly, this user story does not represent a single unit of work.

It is comprised of multiple smaller user stories. Some examples of this would include—ability to enter payment details, different payment methods, allowing cash on delivery, saving of card details for future use etc.

In this case, it would make sense to treat the payments feature as an EPIC. All the user needs that have to be satisfied to deliver an MVP for the payments feature will be specified as separate user stories under that EPIC.

User Stories act as the building blocks of Epics (Image by Atlassian)

While coming up with user stories for a particular feature, the following approach can be used:

Using insights from the customers and the internal team identify the user needs that MUST be satisfied for the version 1 of the feature to be valuable for the end user.
Articulate these user needs in the form of user stories. Depending on the scope of the first version, the number of user stories could vary.
These user stories come together as a separate section in the PRD (product requirements document). Acceptance criteria in the PRD should capture the criteria for validating the correct implementation of user stories.
The stories and the wireframe is then shared with the design team to develop the UI for the feature.
Once design is done and the feature is prioritized, the PRD is shared with the engineering team. They can now begun to identify how to build this and provide overall estimates (using individual stories).

Using user stories in feature development makes it easier to 1)scope out version one 2) build a great User experience for the feature) 3) provide time estimates.

Some tips to write better user stories

Constantly stay in touch with the customer. This way, you will always know what their top of the mind concerns are.
When feature requests comes in from support/sales/marketing teams or your boss, articulate the asks in terms of user stories. Then, get their sign-off on these. This will bring structure to the feature requests.
User Stories should be made a mandatory section of the PRD. No feature development should occur without the articulation of user stories first.
Make it a collaborative process. Use inputs from the different stakeholders to refine your user stories.
Keep it simple: Use a standard format for writing them.
Describe what the user wants do with a product and not how a functionality is implemented (The Tech/UI details should not be a part of the user story).

User Stories are a critical part of the feature development process. They help bring the focus back to the customer and offer a variety of benefits for the entire team. Every product manager should strive to make these a mandatory part of their workflow.

Additional Reading