It has been long since men have been telling stories. From the cave paintings, since they started gathering around bonfires, Pablo Sánchez told us that men were interested in stories. “Telling stories connect us along time, going through different cultures”. And this is something we apply to our software projects today. Perhaps because it is the way to understand that what the client eventually wants is to keep on telling stories. Maybe it is the oldest way to communicate, we believe it is the best way to understand what is the value the user of the product we are building wants to get. For that reason, Pablo, agile coach in intive-FDV, decided to explain everything about user stories in a talk.
Stories were first used in software development within a methodological framework called Extreme Programming. In this work approach the premise lies on the possibility of changing the requirements as the product goes evolving. The same happens with user stories that today apply to our agile approach: they evolve as the project develops.
How can we elaborate a user story properly?
To have a well-written story you should resort to a mnemonic rule known as “I.N.V.E.S.T.” Let’s see what the acronym actually stands for:
I: Independent. Each user story should be able to develop this way, independently from other parameters.
N: Negotiable. If the story is too long or has few or too many objects, negotiation should be allowed. The idea is for it to develop dynamically through constant negotiation with the people involved.
V: Valuable. This acronym remembers us the question regarding: why? The answer is the value we are providing users with.
E: Estimate. The ideal is that the story is clear enough to know its reach and estimate efforts.
S: Small. So we can work on a story in sprint mode. The challenge is to achieve the minimum story possible.
T: Test. Basically, that the story can be proven
A user story notation
Mike Cohn wrote a book which Pablo deems as “almost a bible” on a topic. “User Stories Applied for Agile Software Development”. He also mentions a notation named after him and that works as a model or template to elaborate the description of any story. This modality is greatly useful when having to prioritize stories, since not only does it describe the functionality itself, but it also explains perfectly the value of each of them and who it gives this value to.
Another option is templates, which represent an evolution of the previous while including the agreement criteria or group of conditions where the story has to be tested to make sure it is developed in the correct way, and that is as follows:
Templates are great when you need to automate or standardize the job of the person writing.
And who are they written by?
When you work according to the Scrum framework, it is normally indicated that user stories belong to Product Owner. They actually belong to everyone involved in the product development, affirms Pablo. The “PO” is the one that has to prioritize or approve them, but stories are constantly modified under the influence of those in the development team: everyone is responsible for asking and asking themselves about the story. Part of the story nature also aims at the client validating it, many times through the “PO”.
Eventually, user stories could be considered guides to make clear what we needed, to prioritize and redefine tasks. As Cristina very well said towards the end of our conversation, we can see them as an excuse to have powerful conversations within the team about the functionality and value which is being delivered. Many times, when we lose sight of the business value, user stories end up remembering it for us.