User stories were first introduced in late 1990 with Extreme Programming (XP). Since then, they have become the most used requirement strategy with any agile development process.

User stories are very simple- just specify what the user wants in a system. But they do many things-

• Stories solve communication challenges between users and development teams
• They are tools for tracking and scheduling works
• Stories are tools for discovering what users want and what products need to do in order to meet clients’ needs.

In this post, we’ll look at-

• What is a user story
• What are the core elements of a user story
• Why we need a user story
• How to discover user stories
• How to split user stories

What is User Story?

A user story is a short simple requirement statement that is told from the perspective of a user.

Example

Assume we are developing an E-commerce website that allows its users to

• Browse the website
• Search products,
• View product details
• Add products to the shopping basket,
• Place order
• Pay for that order etc.

So, all our stories will be relevant to shopping carts. Also, officials can see the inventory, accounts, daily sales, delivery status, etc. So, let’s see some examples-

As a shopper, I want to search the site.

As an admin, I want to block suspicious users.

As a manager, I want to see daily sales and delivery status.

All these are short and simple statements of some features that a user wants to do into the software. All these statements are told from the perspective of the users. Here we have three types of users they are-

• Shopper: Who will shop by using this site
• Admin: Site Administrator
• Manager: Manager of the company

These user stories are not complete. Anyone can ask questions like “I know the shopper need to search but why they need to search.”

To answer those questions, we’ll improve our user stories by using “so that” statement as follows-

• As a shopper, I want to search products, so that I can find all my desired products.
• As an admin, I want to block suspicious users, so that we can prevent any types of fraud in our site.
• As a manager, I want to see daily sales and delivery status, so that I can report my seniors.

So, we can simplify the definition as follows-

A user story is a short and simple requirement statement that tells by a user. The statement specifies what the user wants and why he/she wants it.

Template of a user story

In above user story examples we saw that each user story follows a common template which is-

As a [role], I [want/can/need/require] [some feature], so that [some reason]

We can define the template in even simpler manner as follows-

As a [who], I [want/can/need/require] [what], so that [why]

So according to above template we found there are three elements of a user story. They are-

• Role (Who) = tells the type of user
• Some feature (What) = tells the goal of user that he wants to achieve
• Some reason (Why) = tells why the user wants to achieve that goal

In other words, we can say that – each user story answers three questions- they are-

• Role (Who) = who needs the feature
• Some feature (What) = what the feature is
• Some reason (Why) = what the feature needs

According to the above template

• Anything comes after phrase “As a” is WHO
• Anything comes after phrase “I want/can/need/require” is WHAT
• Anything comes after phrase “So that” is WHY

Importance of Who-What-Why in a user story

We know that a user story has three elements. They are –

• Role (Who) = who needs the feature
• Some feature (What) = what the feature is
• Some reason (Why) = what the feature needs

Now we’ll discuss about why these three elements are so important to exist in any used story.

Importance of WHO

Agile user story represents user’s expectation from the software in the perspective of a user. In user story “WHO” is an essential element. Let’s see what’s are the benefits that we’ll get from the element “WHO”-

• WHO describes the user or role of user who will use the feature or functionality
• WHO gives us guideline about how we will implement a functionality for different users in different ways.

Example:

Login is a common feature for Shopper, Admin and Manager. But after successful login all three types of users will redirect to different pages e.g. – shopper will redirect to his/her account page. On the other hand, admin will redirect to Admin dashboard.

Importance of WHAT

• WHAT describes the required feature or functionality that need to build. Without knowing about WHAT the development team will not know what the feature they must build inside the software to meet client need.

Example:

We have following user story-

As a shopper, I want to search products, so that I can find all my desired products quickly.

Here Search Products is the “WHAT” part of the story- it specifies that the user need the feature of searching the product.

Importance of WHY

• WHY describes the reason behind the user wants any feature
• WHY allows product development team to realize whether the feature is valuable enough to worth building or not

Example-

As a shopper, I want to search products, so that I can find all my desired products quickly.

Inside the user story “So that …” part is the WHY part. Here

• The reason behind the search functionality is search will allow shopper to find his/her desired products quickly.
• The development of search feature worth value because it allows user to find his desired products quickly. This will save time and effort of any shopper. So it worth values to develop.

3C’s of User Story

Ron Jeffries developed the formula of 3C’s for clarify the user story in details. The meaning of the 3C’s are-

• First C stands for Card
• Second C stands for Conversation
• Third C stands for Confirmation

Let us discuss details about them-

Card

• Card means 3X5 inch card index card
• This card will contain the user story
• Format of the story will be same as we discussed above

Example-

As a shopper, I want to add product into the cart, so that I can place order

Conversation

User story is a simple statement. So, details must emerge before start work. So before start work businesspeople and technical team will discuss together about the details of the story.

Who will discuss about the story?

By following Three Amigos pattern we can select people from three perspectives to discuss about the story. They are-

• Peoples from business perspective:

People who knows the desired outcomes of the user story

• Peoples from development perspective:

People who knows how the team work and deliver the outcomes of the story

• Peoples from testing perspective:

Someone who is good at thinking up all of those “what if…” type scenarios i.e. different type of test scenarios e.g.- QA people

When will have the conversation?

• Good time of conversation is during Backlog Grooming aka Backlog Refinement. At this time product owner will prioritize user stories. Can have deeper discussion on those items who have highest priority for next sprint.
• Another good time is before start work

How will discuss?

• Brainstorming is one of the great ways of discussion on anything. So it is suggesting to conduct a brainstorming session for continuing the conversation
• According to me the best way of conversation is
  • Sketch a Conceptual Mockup
  • Then Identify all active elements of that mockup
  • Then provide example for all those active elements

Later I’ll provide a hands-on example of this discussion.

Confirmation

After conversation team have a shared understanding about the feature/product. They now know what they need to achieve i.e., what those criteria they need to fulfill to make the story done. Then they document all those conditions behind the card.  This is also known as Acceptance criteria or conditions of satisfaction.

Acceptance Criteria of user story

User stories are vague. It’s not possible to build a feature only based on the user story. So, we need acceptance criteria. Acceptance criteria provides guidance on the behavior of the feature.

• Developer’s uses acceptance criteria to determine what they need to do to make the feature workable.
• Tester’s uses acceptance criteria to determine what tests they need to perform in order to ensure that right feature is developed.

Now we’ll see an example of acceptance criteria-

We have a user story as follows-

As a shopper, I want to search product, so that I can get all my desired products quickly.

Acceptance Criteria-

• Product must be search by brand and /or category
• If found matching products on search conditions then list of products including their name, price and picture will show to shopper
• If no matching product found, then following message will display-

“Sorry! No matching product found”

Assumptions & Dependencies

Assumption

Assumptions are conditions that need to be true to make the user story effective.

Example- we have a user story-

As a shopper, I want to search product, So that I can get all my desired products quickly.

Here our assumptions are-

• Large number of users will use this feature. If we have couple of users then it’s not necessary to develop this feature just for couple of users. So we’ll assume that this feature will uses by a large number of users.
• This feature is more easy and faster to use than the search feature of all other competitors’ website. If the feature is same or lower grade than competitor’s website then why user will use this feature from our site. Rather they will go another site to purchase items.

Assumptions helps development team to make sure whether the story is effective or not. If find not effective enough then- what modification needs to make the story more effective.

Dependencies

Sometime some user stories are closely dependent on other user stories. In that case those user stories need to implement before implementing dependent user stories. Dependency refers to other user stories that must implement before implement the given user story because given user stories feature is dependent on that user story.

Example-

We have a user story like-

As a Shopper, I want to check out my cart so that I can confirm my purchase.

This user story is dependent on another user story which is Add to Cart user story which is as follows-

As a shopper I want to add product into cart, so that I can purchase those products.

Without adding product into cart, it is not possible to checkout. So that before implement Checkout feature, we must implement Add to cart feature.

Later we’ll show how easily we can identify the dependencies of user stories for smooth execution of their development process.

INVEST Model of user story

The acronym of INVEST is Independent, Negotiable, Valuable, Estimable, Small & Testable. Let’s see them one by one-

Independent:

A user story shouldn’t depend on other user story. It should be independent.

Example-

• As a shopper I want to search products so that I can easily get my desired product.
• This is the example of an independent story. This story doesn’t dependent on any other story.
• But it’s easy to say that user story should be independent but in real world for many cases it’s hard to avoid dependencies between user stories.

Example-

• As a Shopper, I want to sort search results, so that I can more easily find my desired items within the search result.
• Look this user story is dependent on search user story. First, we’ll need to search then we’ll sort the search results.
• In such dependency case we must determine the order of implementing those user stories i.e., we’ll first implement the Search user story and then we’ll implement the Sorting user story.

For a project we can create a dependency chart for manage the order of implementation of all available user stories so that we don’t fall into trouble. The sample of a chart can be as follows-

Story in backlog	Story dependent on	Order of implementation
Search Product	None	1- Search Product
Sorting Search Result	Search	2- Sorting Search Result
Product Details	Search	3- Product Details
Add to Cart	Shopping Cart	4- Shopping Cart
Shopping Cart	None	5- Add to Cart
Checkout	Shopping Cart and Login	6- Registration
Login	Registration	7- Login
Registration	None	8- Checkout

This is one of the simplest way to identify dependencies of user stories that we discussed in Assumptions and Dependencies section located here

Negotiable

A story should have the option for conversation i.e. the user story should allow team to further conversation with business team on the feature and if needed can update the user story as per discussion.

Consider following user story-

As a Shopper, I want to sort search results, so that I can more easily find my desired within the search result.

Look at the story. When you will see the story this story will allow you further discussion like-

• What will be the sorting criteria?
• In which order it will sort Ascending or Descending or both?
• And many more

So, we can say that the story meets the condition of Negotiable.

Valuable

A user story should provide some value to the business.

Consider following example-

As a Shopper I would like to view details for a product.

What the story is saying?

It’s saying that customer wants to view the details of a product.

Is the story saying-

• Why the customer wants to see the product details?
• What will he/she do by seeing the product details?
• What the business value he/she wants to achieve?

No. The story doesn’t say anything that is related to the business value.

So, we can say this story is not complete.

To complete the story, we also need to mention the business value that the customer will achieve after implementing the story. So, we’ll also include the so that part of the story as follows-

As a Shopper I would like to view details for a product, so that I can see the details of the product.

Now the story is complete. It is saying what the customer wants and why he/she wants it.

Estimable

During planning session developer and tester estimate the required effort to implement the user story. It is very important and required for each story that we’re going to implement.

If during planning meeting developer and tester fail to estimate any user story by seeing the story and its acceptance criteria, then that is not a good user story. It means one of the following two things-

• User story is too big
• User story is vague
• In case of big user story-

Break down it into smaller logical chunks so that each user story provide some values to its user. We will break each user story in such a way so that it provides functionality to its user. Better way to single user story will provide single functionality.

Example-

For CRUD application we will have 5 user stories like for Save functionality one user story, for Update functionality another, similarly for Delete, for GetAll and GetById functionalities we’ll separate the user story. It will be easy to maintainable and short enough.

• In case of vague user story need further clarification until have a shared understanding to all i.e. developers, testers, business peoples etc. all. Resulting of the clarification may help the team to-
• Add certain acceptance criteria
• Clarify certain acceptance criteria
• Rewrite certain acceptance criteria
• Modify certain acceptance criteria
• Add any assumption
• Modify any assumption

These are the options that will help us to make user story more clear, concise, and estimable.

Small

User story should be as smaller so that it fit within the sprint duration. What it means- let’s see-

If any user story requires more time than sprint duration, then obviously that user story is not small. That user story needs to break into smaller logical chunks. As I said earlier better way to breaking user story in such a way so that one story can serve for single functionality as like as the example of CRUD.

Testable

Generally, most of the story implementation has three parts-

• Designed by designers
• Coded by developers
• Then tested by testers & users.

By testing user story testers and users verify that the story

• Implemented correctly
• Properly meet the client’s needs
• Done successfully

This testing process is done by creating test cases using acceptance criteria. Then running those tests as per test cases.

For example, we have a user story as follows-

As a shopper I want to search products so that I can easily get my desired product.

And the acceptance criteria of this user story are-

• Must ensure that products can be search by Brand and/or category
• Search performs only on Active products
• If no stock balance is available for a product then it will show “No stock available now” below to the product information

Testers will write test cases according to these acceptance criteria and will test and check whether the implementation of the user story meets all those acceptance criteria or not. If find successfully meets all those criteria, then the user story implemented successfully otherwise need to rework.

Definition of Done

Finally, we will set up the checkpoints that will confirm whether the work of the story is done or not. For this user story we will use the following checkpoints as the Definition of Done of the user story.

• Must meet all acceptance criteria of the user story
• The product owner will approve the story
• All unit tests were written, executed, and passed
• Every acceptance criterion has at least one test case associated with it and that case is passed
• Code Review done
• Feature works as expected in Staging environment.

In next post I’ll discuss about how to breakdown a story into several executable tasks.

Md. Mojammel Haque

Sr. Technical Lead at Insightin Technology

About Author:

Md. Mojammel Haque is a passionate software engineer with more  than  10  years  of  software  development  experience  in  using  different  .NET technologies like ASP.NET MVC, ASP.NET Web API,  ASP.NET Web Forms, C#, Entity Framework,  SQL  Server,  Unity  IOC  etc.

He has a depth knowledge of Agile methodology, Scrum Framework, Object Oriented Analysis &  Design,  Domain  Driven  Design,  Unit  Testing,  Acceptance  Testing,  Integration Testing, GOF Design Patterns, Enterprise Patterns & Refactoring of existing code.

He  has  successfully  completed  Certified  ScrumMaster®  (CSM),  Certified  Scrum Product  Owner®  (CSPO),  and  Certified  Scrum  Developer®  (CSD),  Certified  Scrum Professional-Product Owner® (CSP-PO), Certified Scrum Professional-ScrumMaster® (CSP-SM) certifications from Scrum Alliance Inc.