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



Independent


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.

Measurable

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

Small

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


Testable

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

Valuable

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 

Negotiable


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

Agile Workflow process for Software development

In one of my project we experienced instances of  “Push vs Pull”. Confused?  Teammates had to tell other teammates that they have done certain tasks or they had to ask for certain tasks.This creates a lot of confusion when you are working on medium to large size projects. These tasks are more like “I have pushed the code, please review it” or “You got some support tickets, and as a manager, you have to assign it to  developer”

For smaller projects “Excel/Spreadsheet” worked fine. Issues can be tracked properly and is maintainable. But on medium to large size projects there are some set processes which need to be followed. These can be Linear processes where things mostly move in 1 direction or multidirectional.

You need some basic processes to make the project successful. Well begun is half done! The way you lay down your foundation, database structures, Infrastructure, the team and the development process gives solid direction to the project . I have been using JIRA since its early day…

AGILE - NOT AGILE

Many people in the software industry have heard about Agile. It is ubiquitous and can't deny the fact that it is redefining the way of how software is developed.
But most of the people do not know what Agile is not. Software developers who have worked in AGILE have their own definitions. Rather, every company / organisation has their own definition for AGILE [which is good and bad at times].
Looking at the last two decades when the software industry had begun its maturity, there were few methodologies for developing softwares. These methodologies were based on Process and Principles. A lot of focus was given to documentation which led to excess and result in efforts as well as maintenance. In Agile focus is more on delivering smaller piece of software which requires very less documentation. This means AGILE is not an excuse to producing documentation. It can be in various forms such as user stories, Epics, meeting notes etc.
Software professionals often mistake Agile as a process dri…