In Agile Software development, a user story is the artifact that specifies the software need to fulfill a very specific business goal or benefit.
Some authors say (and I subscribe) that a user story is the promise to allow a future conversation between the development team and the Product Owner. To me, the story text that is written on cards is less important than the conversation the user story allows to have.
“Working software over comprehensive documentation”from agile manifest
A user story should be concise but not vague with the purpose of transmitting the business needs correctly. And should always be clear and complete in a non-technical language, to be understandable for all parties, It needs to be sufficient enough so that:
In essence, the question is: How can we allow good communication between all parties to get a shared understanding of what is required?
There are some basic ideas worth keeping in mind
1. Balance: Please, avoid stories with too little or too much detail. In my experience, bringing a story into a sprint before it is sufficiently understood, will result in many open issues. On the other hand, trying to add every little detail to a story will result in delays adding the story to the sprint backlog.
2. Product planning: In an agile framework the planned work is the heart of an iteration, well defined and organized user stories work as a good tool to have visibility of the opportunities and challenges within the project to facilitate the decision of which stories should be included.
3. Estimation: Planning and estimating software is one of the most complicated tasks I have faced. Well defined user stories, with a clear scope, are key elements in the process to estimate the effort needed to accomplish the required work.
Well structured user stories usually include the following three sections:
An usual template of a card could be: As a <Role/(who?)> I want <Goal/(what?)> So that <Benefit/(why?)>.
A good characteristic in a good user story is that it should follow the INVEST acronym. My recommendation about it, do not see the INVEST acronym as rule but as a useful set of principles for creating user stories. All in all, a story should be: Independent, Negotiable, Valuable, Estimable, Small, Testable.
In my opinion and from my experience in agile frameworks, good user stories are key part of the success of a project and succeeding on writing user stories requires a balance between knowledge and practice as what is required is going to depend on many variables.
User stories are good artifacts to encourage yourself to dice in the process to get better understanding and create good documentation for your project. Remember, you need to have a clear understanding of your story before you finish it not before you start it.
To make a point on this idea, I would like to use a quote that came to my mind as I was writing this, and I reckon fits perfectly:
“Those who are in love with practice without knowledge are like the sailor who gets into a ship without rudder or compass and who never can be certain whether he is going. Practice must always be founded on sound theory, and to this perspective is the guide and the gateway and without this nothing can be done well in the matter of drawing.
The painter who draws merely by practice and by eye, without any reason, is like a mirror which copies everything placed in the front of it without being conscious of their existence.“
Leonardo da Vinci.From the book The Notebooks of Leonardo Da Vinci, Volumen1