What is a User Story? 

We can define a user story as the short and simple description of a functionality used in Agile practice. Basically, they are written to capture the requirement from the customer or the end user perspective. It will simply say What type of users, What they want and Why they want it. The user stories should be written in a language where it is very clear to both customer and the scrum team “as to what the customer wants and why they want it and what kind of customer wants it”. 

Scrum teams should understand the customer needs and they should take care of how to cater the requirement from technical perspective.To take care of the technicality or back end functionalities they sometimes have technical user stories as well. 

Basic Functionality 

Now will look into the user story structure and understand what are the important things we should include in it. 

User Story 

This is the sample template that we are widely using when it comes to user stories.Use the template when it is helpful, but don’t feel obliged to always apply it. Experiment with different ways to write your stories to understand what works best for you and your team. 

As a <<CUSTOMER TYPE>> 

I want <<WHAT CUSTOMER WANTS>> 

So that <<WHY CUSTOMER WANTS IT>> 

Acceptance Criteria 

Also as a PO or Proxy PO you need to make sure to write the acceptance criteria in order to accept the story. This is something very important and this will help your QA team a lot when they write test scenarios and test cases. 

Definition of Done 

Many organizations use this method in different ways. Some have DOD user story wise and some have DOD by release wise. It’s up to you to select the best method which suits your company but I prefer this using release wise rather story wise because ideally DOD cannot change story to story. But in a nutshell here you have to mention what are the important items to be completed before sending it for the UAT (User Acceptance Testing)or Customer demonstration. 

Now will take an example scenario and see how we can develop a user story around it. 

Assume that a customer with an online web-store wants their buyers to use credit card options to buy items. In this case I have treated the“Buyer” as the end user/customer but you can write this treating “Web-store owner” as the end user/customer. 

User Story 

As an online buyer  
I want to use my credit card to purchase an item  
So that I can immediately purchase my item from the web-store 

If you want to write this treating “Web-store owner” as the endures then most probably the user story will look like this 

As a web-store owner 
I want my buyers to use their credit card option to purchase items 
So that I can immediately do the transaction 

Acceptance Criteria 

· Accept Visa and Master cards 

· Validate customer card details (Card Number, Name, CVV, and Expiration Date) 

· Amount confirmation from the buyer 

· Generate success or error messages 

Definition of Done 

· Unit test case completion 100% 

· Test coverage completion 100% 

· QA sign-off 

· PO/BA sign-off 

That’s a simple example of how to write a user story.Based on my experience of working with user stories for nearly 6 years I can say, Its very easy to write them but we should know the correct methods and tips to write an effective user stories. 

Tips for writing effective and good user stories 

A very well written user story will meet the criteria of Bill Wake’s INVEST acronym 

Bill Wake’s INVEST acronym 

Also remember the below points which I am sure will come in handy when writing user stories 

• Think from user perspective 

Rule #1 and the very important one. 

As the name implies user story has to explain in ‘end user’ perspective. If you don’t understand the user requirement as to what they want and why they want, then you have to do your homework first. 

• Make your story Simple and Concise 

This is one of the important things which you have to understand. User story should be short and concise and should not have any ambiguity in it. 

• Acceptance Criteria 

Always remember to write acceptance criteria so that team is aware of your expectations 

• Discuss your stories with the teams 

This is one of the methods which I personally prefer. You have to make the stories visible to the team and you should always make it as a practice to discuss it with the technical team. Before going into grooming sessions make sure that the team is aware the depth of the user stories. In this way you can save more time in your grooming sessions. 

• Don’t hesitate to add NOTES 

If you have more information which you want the team to know, always make a note in there so that the teams can understand the user story in more detailed way. 

• Keep the UIs aligned with user stories 

If you are doing a requirement related to a front-end functionality then it’s better to have the relevant UI attached to it. That way the teams can easily understand what should be the outcome. 

These are the few steps you have to keep in mind when you want to write a effective user story.😎