Skip to main content

User Stories Simplified!

User story writing guide

When I was introduced to the world of Agile, I kept on hearing the words  “User Story”. I couldn’t apprehend what it meant and how it possibly could be a fit for requirements management.
This was all due to the traditional waterfall methodology which was omnipresent in most of the software projects. Early in my career we totally relied on creating massive amount of documentation which included but not limited to
* Business requirements document
Software requirements document
High level design document
Low level design document
Use cases

 You can clearly see where the problem lies if you are planning on to maintain all these documents. On top of that, if you are working on mammoth projects, good luck with that!

How does user story  might prove to be user full?

First of all, User story is not a Silver Bullet but a convenient way to represent requirements. More precisely what a user intends to do.

In my case study, I am going to use example of “loremipsum” which is a social networking site similar to Facebook.

Parameters for a neat user story


A user story should be self supporting and self ruling. They should be simple to understand and should not be dependent on other user stories. If you come across a user story which is dependent on other try breaking it down into small autonomous chunks.
Stories which are dependent are hard to estimate and priorities.  
Example : For our social media website “Loremipsum” the user has various options of signing up.  
Registering with email address
Using Facebook login
Using Google login
Or registering with a phone number

We could write a user several user stories like
As a user, I should be able to register using Facebook login credentials (oAuth)
As a user, I should be able to register using google login credentials (openid)

Now  the above stories can be estimated in a different way by the developer.  The developers might say that both of the stories are social media logins and for the 1st one it might take 3 days but the 2nd one might take 1 day since they would be comfortable working on it as they already know the details for the 1st one implemented. Now the question is which one should be given 3 days estimate and which one should be given 1 day. The best way is to combine these 2 stories and make sure that they do not go above the max estimate point size. Example : As a user I should be able to register on the system using Google credential or a Facebook credential.


A user story should be easy to understand so developers can estimate the time required to complete/code the story. The estimates are approximate guesses but serve as a time box. There are 3 major reasons why developers are not able to estimate the story properly

A) They do not have the domain understanding. Early in my career, I was working on a Banking project where the story was related to calculation of Simple Interest given that you already have the “Sum borrowed, interest rate and the number of months”. Acceptance criteria was defined unambiguously and we also had test data for unit test preparation. 
This made us realise that every developer working on this project needs to have some basic domain knowledge and could always get in touch with Business Analysts/SME’s for any domain knowledge

B) Lack of technical knowledge. On a major banking project one of the major module was to get certain credit details of a customer. This customer data was actually created in another application. For this we had to make sure that we connect these 2 different applications so that we get the end result for reporting purpose. API’s were considered easy to implement but none of the developers had the knowledge apart from the technical architect of the project. Developers had a hard to estimate it but fortunately they got trained since this was mentioned in the retrospective meeting that they were new to the API’s

C) Stories which are huge. Often the stories might seem simple but they are epics in nature. Due to this Developers cant really estimate the story. An example  from one of my project  : As a customer of  I should be able to login. Now this can be feature came in directly from the management stakeholders and were part of Roadmap features. This feature some how made its way to the product backlog. when we were doing pre sprint planning with the technical architects, we came to various conclusions and realised that this particular feature can anything from
As a customer I should be able to login by using my credentials
As a customer I should be able use my Facebook login
As a customer I should be able to use One Time Password “OTP” for logging in
Separating /breaking these stories out and getting an approval from the Stakeholders made it easy for the developers to estimate it easily


Have you ever devoured a pizza and eaten the whole in one single  bite. Answer is probably not. A user story  no matter what, should always be small and easy to understand. People often mistake user stories for Epics or use cases at times and churn out multiple pages in just one document. If you feel that the user story is trying to point at multiple requirements, break it down. This has advantages and can be monitored with ease. 
Example for and ecommerce app where they are working on checkout module. As a user I should be able to buy items. Now this is definitely going to increase the meeting time and confusion.
How about this
“As a user I should be able to buy items using Credit card”
Acceptance criteria : Visa, MasterCard should pass
Diner card should fail
Cards which are expired


A user story should be testable. If the user story is not testable the developer wont understand what to deliver. Example : Putting in lot of non functional requirements like “User should not have to wait for long time on XYZ screen”
Developers will never understand when to stop f the tests don't pass


The stories written always have some value associated with it. Like points, codes etc. But they are mostly valued by the developers in conjunction with the product owners who have somewhat understanding about the customers. 
Where it goes wrong? - Example : The team member writes a story “ The application should run on IE 7.XX and above”
Now if this application is being used by a large user base who don't necessarily have IE 7 or above version might face some errors when viewing the application in browser. Had the customer and customers customer valued the story it would have been a different case. Generally this type of requirements are extracted from various sessions like brainstorming, focus groups, brainstorming etc 


User stories written are more of what needs to be achieved and it gives a basic understanding. They are short sentences and at times not give the whole picture. The solution is derived or negotiated in conversations with the customers. 
Example for and Ecommerce app while shopping

As a user I should be able to select the they type of card 

Note : Accept Master , Visa and Diner only.

At the time of discussion with the customers, we can implement a solution where you dont need to select a card, simply enter the number and based on the 1st 2 numbers the processor will be identified

Popular posts from this blog

Do you really need a Business Analyst in your project ?

Do you really need a BA or a similar fulfilling role in your project?

My Aunt has been in a Real estate and construction business for long time. When I was a kid, I used to visit her to every now and then to spend some time. As a part of the visit, I was often told by my cousins that she is at the construction site. 
Building a small house over a chronological period I got to experience how the house was built from scratch. I saw how the construction workers did the job as they were guided by the contractor. 
I also experienced that when it comes to big buildings, there is always an architect who creates the blueprint of how the house is going to be, what dimensions the rooms are going to be.
Notice how this is an analogy for any system we build. Our systems can be small where you don’t really need a Product owner/Business Analyst or we need somebody exclusively who is just for gathering/writing the requirements.

 If you are building a mid to large-scale system, you do need to have a dedi…

Product Management

Product Management

Once I had a conversation with one on my friends who just happened to join a startup. He said he worked as a Product Manager and was talking in general about roles and responsibilities .
What surprised me was that his roles and responsibilities differed from what I have seen in the market. Nothing wrong with it, this happens with other roles also. 
Product management roles vary depending on organisation to organisation. It is hard to define the roles and responsibilities. Though all have a common goal to making the product successful but vary depending in what department you are in or what phase part you are working on. Example : Some folks work in the analytics are Product Manager.

Talking about my friend, he was more into forecasting for the application, looking at the revenue growth. When asked about who builds the road map, his answer was that the tech team and the business decide.  A fairly common scenario. 
So what are the Roles and Responsibilities of a Product Ma…