User is the center of universe for each and every product that is built and designed. They will use, rate and promote the product. User centric approach shifts the focus from just coding and designing to delivering real value to your end user, stakeholders and business in general.
User stories are an essential component of this ideology that lets you define what benefits your products will bring to your target audience. User stories will allow you to connect your North star metrics with user expectations.
Now, there could be millions of users and these users can have different thoughts on how the product should function and how specific tasks are performed. Well, one thing is clear, million stories are neither feasible, practical nor will provide any valuable feedback. To solve this problem, during the market segmentation stage we need to map users to different market segments and create user stories based on these segments. For example, Airbnb will have various market segments where they want to put their products in. An example of how Airbnb categorizes its travelers would be: price conscious travelers (looking for low price accommodation), business travelers (looking for fortnightly or monthly accommodation), luxurious (willing to pay for 5-star experience). All these market segments should have separate and distinct user stories because travelers in each of these categories have different goals for staying while traveling.
Now we are in a position to define what we mean by a user story. I really liked how Aha! defined user story in one of their blogs as the following:
A user story is an agile development term that describes a product feature from the perspective of the end-user. User stories help product managers clearly define software requirements so the development team understands the desired outcome of the new functionality.
A good user story template captures the “who,” the “what,” and the “why” of a feature in a simple and concise way. This sentence is often written in the everyday or business language of the end user to convey what they want or need to do.
Aha!, User story template – Link
Let us get to back to business and really understand the three basic steps that go into creating and writing the user stories. To make sure that user stories impart the right information, get answers to these 3 very important questions below.
- What is the user doing?
- What does the user want to achieve?
- Why do they want to achieve this?
Table of Contents
As a user, I want a <feature> so that I can <satisfy a need>
The goal is to communicate the context around what you want built so that devs can make decisions about how to implement it. To help you visualize this, let us take some Airbnb examples –
- As a traveller, I want to search for a destination so that I book accommodation in a foreign city.
- As a home owner, I want a online marketplace so that I can advertise my property for rent.
Once you have created the user story, do not forget to add acceptance criteria.
An acceptance criteria is a set of conditions that are used to confirm when a Story is completed
Acceptance criteria will ensure that user stories are completed correctly and accommodate the client’s demands. Often it is just a bulleted list of things such as “User can see x” or “User can enter y.” Essentially the acceptance criteria allow someone to test and confirm whether the user story is working as expected. We can also define acceptance criteria as following:
Acceptance criteria are a set of statements, each with a clear pass/fail result, that can be measured and specifies both functional and non-functional requirements.
Let us look at an example of from the above Airbnb user story with acceptance criteria.
User story: As a traveller, I want to search for a destination so that I book accommodation in a foreign city.
Acceptance Criterion:
- User should be able to browse through the catalog of houses, check-in/out dates and filter for price, location and ratings.
- After browsing and selecting the property, user should be able to pay online though e-banking or credit/debit card
- User should be able to communicate with the property owner to check for specific details such as internet speed, places to visit etc.
Now that we have defined user stories and understood the criteria to create them, let me share the template that I use for writing user stories. It is nothing fancy just a simple table. This template is generally available over internet. The best part of using this template is its simplicity and how it captures all critical information from investment size to acceptance criteria.
Although user stories are independent and totally a separate unit of work, sometimes they are grouped together. In this scenario, you are more than likely to use the concept of an epic.
What is an epic? An Epic is a high level body of work that bands together with a group of related stories. I have tried to show a distinction between an epic and user stories.
| A Story 📃 | An Epic 📒 |
|---|---|
| The smallest unit of work; can’t be split | Can be broken down into more specific and smaller elements – User Stories |
| Fit a shippable product increment that should be delivered during 1 sprint | Implemented during a few sprints |
| Represents some value that user will get after implementation | Indicates a more general task (for example, implementation of a whole user-flow) |
| Quite easy to estimate | Harder to estimate since the scope is flexible |
Oh, and one more thing!
A good user stories should follow the INVEST criterion created by Bill Wake:
- Independent – they can be developed in any sequence and changes to one User Story don’t affect the others.
- Negotiable – it’s up for the team to decide how to implement them; there is no rigidly fixed workflow.
- Valuable – each User Story delivers a detached unit of value to end users.
- Estimable – it’s quite easy to guess how much time the development of a User Story will take.
- Small – it should go through the whole cycle (designing, coding, testing) during one sprint.
- Testable – there should be clear acceptance criteria to check whether a User Story is implemented appropriately
In Kanban, teams accumulate Stories in a Backlog and then run them one by one to support the work-in-progress flow. This helps to constantly stay on track and improve development team KPIs. Scrum teams also love User Stories. In the projects that I have worked on, we have also used these stories to estimate, prioritize and plan sprints which helps us stay agile and flexible to any change. To summarize, here are the benefits of creative user stories:
- Keep the team focused on the business value
- Enable creativity
- Makes projects more manageable
- INSPIRE THE TEAM!
User Stories can help you to constantly improve the value of your product, estimate development efforts in an appropriate way and prioritize feature development during the MVP and post-MVP stages
If you are liking this series and want to receive my future articles in your inbox, then please subscribe to my blog channel ‘Thinking Pot’. Let me know your thoughts, challenges and personal stories about how you created your user stories.
