Barking up the RIGHT tree: user stories basics
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:
- Stakeholders can verify the desired functionalities to accept the story as ready to be included in the sprint backlog.
- The development of the story can be started and finished.
- The developed code can be tested and checked to know if it satisfies the business need.
Challenges
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.
Let’s dig on some concepts about user stories structure
Well structured user stories usually include the following three sections:
- Cards: Each story is represented with a “note card” and the card’s statement represents the wish for the future conversion to the right understanding of the story. It will be defined as part of the identification phase and its responsibility is to communicate the objectives and processes from the business side and the issues they want to tackle with this story. The goal of the user story card is to be used for planning and as a reminder.
An usual template of a card could be: As a <Role/(who?)> I want <Goal/(what?)> So that <Benefit/(why?)>.
- Conversation: Details behind a user story are defined as part of the conversation between who writes the story and who needs to understand it, this doesn’t mean that the story should not be complete and contain the correct information when is created, the conversation could be seen as the technical specification, and its result should be the correct understanding for who will be in charge of it.
- Confirmation: Represented as acceptance criteria and defined as a list of checks that will be performed once the story is completed to ensure correct implementation, It’s the representation of how to check the final result against the expected result. The acceptance criteria are not only useful to validate the final result but are also really important to understand how the implementation will be tested and allows the team to decide if the implementation is ready or not.
Always keep in mind:
- Present from end user’s point of view.
- Write in non-technical terms.
- Focus in the business goal.
- Manage a little scope and brief descriptions.
- Engage the users in the process.
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.
Final thoughts
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
