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