User stories are the requirement specifications in their simplest form. Methodologies like Scrum use User story format to express the functional requirements of the software to be developed as –

As a <user persona>, I want to <do the action> so that <need of function>

This creates a deeper understanding of the behavior from a user’s perspective along with the business need and reason for the function, thus making the development of software easier.

But writing effective user stories isn’t as easy as it sounds. There are a lot of questions to be answered, like which functionality is one user story and which is too big and needs splitting up; what is the true sense of the user story; how to best express the functionality in words; which user personas are to be considered etc.

Getting the user stories right is an essential step to success of the sprints in agile, and for the teams struggling with it we have the INVEST principal as a guideline to be followed. This principal gives the attributes of a user story to be considered when writing and defining them so that they can make a robust foundation to our product backlog. Let us look at the principle in depth –

I – Independent

Means that each user story must be Independent as a functionality and be deliverable

N – Negotiable

Means that the user story be negotiable in terms of implementation, which necessarily means that the implementation details or ‘how’ to do the functionality must not be specified in the user story. User story must be business need and customer experience story.

V – Valuable

Means that the user story must create value for the customer. We should be able to see the reason and way the function will be valuable to the customer and this can be gauged by direct communication with the stakeholders, and can also be quantified in terms of ‘business value’ that we can associate with each story.

E – Estimable

Means that the User story must be clear and concise enough so that we can estimate the amount of work required to achieve it with accuracy. Any unclear parts, missing information or discrepancies must be clarified before we can finalise a user story to be taken up for development.

S – Small

Means that each user story must be a small chunk or slice of work. The development of one user story must be doable within one sprint and hence anything bigger than that would need to be further split down.

T – Testable

Means that each user story must be testable as a feature and have a unique new function get added to the product.

Letter	Meaning	Description
I	Independent	The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N	Negotiable	User stories, up until they are part of an iteration, can always be changed and rewritten.
V	Valuable	A user story must deliver value to the end user.
E	Estimable	You must always be able to estimate the size of a user story.
S	Small	User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T	Testable	The user story or its related description must provide the necessary information to make test development possible.

Keeping these points in mind when designing and formalising our team’s user stories will ensure that the sprint runs smoothly without unforeseen scenarios, glitches in implementation due to unclear requirements and re-work due to frequent changes.

Have more questions? How to achieve this?

Stay tuned for the next article where we will look at the steps to achieve the best user stories.

Happy Testing!
Nishi