What is a User Story?
User Story is a concise description / requirement of a user’s need for the product from that user’s point of view.
User Story seeks to describe this requirement in a simple and light way.
User Story is just a promise of a conversation, a reminder that more details will be needed, and it should not be considered sufficient to get the job done.
User Story will be useful for product development if it is followed by a series of conversations between business (in general, the Product Owner) and members of the Development Team.
These conversations aim to define and capture the business details necessary to develop the functionality that will meet this user’s need.
Business details can be documented in different ways and attached to the User Story. However, it is believed that User Story Criteria and Acceptance Tests already represent sufficient documentation, as they must cover all business aspects of the requirement.
How to deal with Technical requirements
In practice, technical issues (such as code refactoring or database population, for example), research, or problem correction can hardly be described from the user’s perspective.
Although they belong to the Product Backlog, they should not, therefore, be represented by User Stories.
The technical issues are, however, difficult for the Product Owner to understand and consequently, he will face difficulties in prioritizing them. Therefore, it is recommended that, whenever possible, they are embedded as part of the User Stories for which they are needed.
Applying INVEST model in writing a User Story
To prevent a user story from being made in an unpretentious way, Bill Wake created the INVEST mnemonic.
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimateable
- S – Small
- T – Testable
Remember it and most likely your user stories will be of good quality.
I – Independent – A good user story must not depend on another. Dependent user stories are difficult to estimate
and prioritize, and removing a dependent user story causes several problems in others.
N – Negotiable – A user story is not “just” a text detailing the features that the Product Owner expects or a piece
of functionality that will be implemented. See a user story as a starting point for a conversation or an opening for the team to suggest solutions.
V – Valuable – If you don’t describe the value the customer will have with this user story, it will be useless.
E – Estimable – If there is not enough information or definition to allow the team to estimate the user story, it
cannot be initiated.
S – Small – A user story cannot take more than one sprint to complete. Any user story larger than that will
be difficult to plan or estimate with confidence.
T – Testable – If you cannot test a user story, you cannot know whether it will work well or not. So? Test, if the user story in question cannot be tested due to lack of information, do not put it in your backlog.