An introduction to user stories for product managers
By: Vikram Goyal
Tags: User Experience, User Stories, Agile Development, Project Management, Product Management

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

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 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