A good User Story

A software development requirement for a customer is a product value he/she has asked for. A development team views the same software requirement as work needed to deliver the product value to the customer.

User story in software development addresses the mis-communication between those who uses (user) the software and those who build (developers) it about what (value) the user wants.

3 C’s of User Story

Card - A physical representation of what a user wants in few simple plane statements.

Conversation – Details of story emerges when the developers talk with product owner and customer/customer proxies about who, what & why of the user story.

Confirmation - Objective of story identified after conversation in terms of resolved & agreed acceptance criteria.

INVEST in User Story

Independent

While conceptualizing an independent user story we should think of breaking the story into smaller vertical layers keeping the required development work in mind. This helps in prioritizing the user story in backlog queue. A dependent valuable user story can’t be implemented without implementing lesser valuable stories.

Example:

1. In a report screen, report download feature in excel and pdf should be created as two independent user stories – one for excel report and one for pdf report.

2. User validation and forgot password features in a login screen can be created as two independent user stories.

Negotiable

A user story is not a requirement. It leads to a requirement through a collaborative conversation between development team and product owner and, customer or customer proxies. Negotiation evolves the customer’s need.

Example:

1. “ I want to search an item” of user story will lead to - “I want to search an item by typing first 3 character of the item name” or - “I want to search an item by typing any 3 character of the item name” after a collaborative conversation.

2. “I want to print the letter” of user story will lead to - “I want to print the letter in a blank A4 paper” or - “I want to print the letter in a pre-printed A4 size letterhead” after a collaborative conversation.

Valuable

A user story should be of value to the user, otherwise, these is no reason for the user story to have a place in a backlog and development team to work on the user story. Value also includes something called “non-functional requirements”.

Example:

1. “As a admin user I want to create other users so that I’ll not be dependent on application support team” has a value for the user of creating login ID's independently.

2. “I want to pay by credit card” part of user story has a value of transaction to be secured as per the required regulation.

Estimable

We can’t size the user story without estimating it. If we can’t size it, development team can’t commit the story into a time-boxed sprint. Sometimes, we face an issue in estimating a user story due to its big size. The user story should be broken into smaller stories. Lack of domain & technical knowledge are the other main reasons which hinder a user story estimation. We should research in the respective areas till we are able estimate the user story.

Example:

1. “I want to purchase a product item by paying online” should be broken down into “I want to purchase a product item by paying online using net banking”, “I want to purchase a product item by paying online using credit card” and “I want to purchase a product item by paying online using COD(cash on delivery)”

2. “I want my website to be compatible with all types of mobile devices” requires a technical research spike if development team has not done this kind of the work earlier.

Small

A user story should be small enough to be delivered in one sprint depending on the size of the sprint. “Delivered” means the story gets the “done” state. Team’s capability, technology involved and methodology being used play significant role in deciding how small a story should be.

Example:

1. “I want to use touch id identification in the system” needs to be broken down into multiple user stories depending on the new functionality impact.

2. “I want to use new optional rule to submit the custom clearance application digitally” needs to be broken into multiple user stories.

Testable

Each user story must be testable in order to get it done. Testable acceptance criteria are the key aspect of making a use story testable.

Example:

1. “The application should open in IOS devices quickly” should be “The application should open in IOS mobile devices with 3G/4G connectivity in 1 second with 95% of probability under a full network strength”.

2. “The batch process of the application should complete in two hour of time between 12:00 AM to 4:00 AM” is a testable user story.