A user story is a representation of a writing requirement in one or two sentences using the common language of the user. That is the definition of wikipedia for a user story. Its origin dates back to Extreme programming and have matured over time, thanks to large Agilists as Mike Cohn.
The user stories are understood as a contract. But from my point of view, a story mature over time, just like and agile projects evolves in the cone of uncertainty over time, history also. Therefore, the "contract" evolves and changes, adapts to customer needs during agile project life.
Unlike the epics or features, user stories should be small, to be performed in a short time (days or a few weeks at most). In this way they add value quickly, fast and specific for the customer.
If the history is big, more than two weeks is an indication that is not a user story, is more, several even, or do not have enough knowledge of the problem.
We are used to reading and hearing that a story must be independent, negotiable, valuable, small, estimable, and verifiable, but that's all that?
Independent: In agile we are used to working in teams, but applying common sense, trying to avoid blockages, dependencies between team members to work "flow" along the sprint. If we can separate stories, both among themselves as independent of team members and explicit knowledge of people will be doing more robust stories. Dependent stories lead to prioritize and plan based on these units, not the value they provide to the customer. Dependencies between stories can make it difficult to estimate. How many times we found ourselves before the client "No, it is that if you do this story first, or while this other first estimation is lower".
Before dependencies we can make a grouping of both stories in a big story, which becomes independent from the rest (whenever available to do it in a sprint) or otherwise try to find a different way to divide the stories to break the dependencies. Always try to perform these actions, and as the last two estimates based on the order of resolution for the stories. But this option should be the last to see when the above have failed us or have not been able to solve the problem of division.
Negotiable: The stories are negotiable, are brief descriptions of the functionality desired by the customer. The details must be negotiated in a conversation between the client and the team. All very detailed requirements are not included, but if reminders and essential details. An extra detail about a story can make us think erroneously on additional precision. But these initial specifications we will only create more complications at the future work. The correct operation of a user story should be:
· A phrase or two that act as a reminder to keep a conversation between team and customer.
· Notes on issues to be resolved in this conversation.
Here arise details on issues to consider, and these details become after talks in testing of the user story. These tests are functional tests to show if it works as expected customer.
Valuable: The term valuable poses many problems, Why?, Because we have different values, history can be valuable for the team and not for the customer, or can be valuable for the customer but not to the end user. We must always try to avoid stories that are only valued for the team, since the ultimate goal is to give value to the customer.
We must try not to have technical stories as I show in the following example:
· All connections to the database are through a connection pull.
· Up to 40 users should be able to use the application simultaneously.
They have to be more abstract, non-technical, so that the user can properly consider the value it brings him. We must try to make the customer who write these stories, because you will write in the language that he would add value. Guests will feel uncomfortable with this new circumstance because they may think that they turn against situations like, "well, the requirement did not say..". We must make the clients begins to feel comfortable with the concept that the stories are a reminder that talk later, rather than formal commitments or specific functionality.
Estimable: It is important that the team be able to estimate or at least have a hint of the complexity of each story. But problems can arise when:
· The team lacks domain knowledge.
· The team lacks technical knowledge.
· The story is too big.
If the team lacks knowledge of the domain, you should discuss with the customer who wrote the story, learn with the customer. It is not necessary to know all the details, but if a general knowledge of what the customer wants and why the customer wants that story.
Second, a story may have trouble estimating a technology not known. One way to estimate these stories is split in two, with the first part of the story that is of time box, to learn and understand the technology and facilitate the estimation of the next or following stories involving such technology. The first stories serves to gather information quickly and the second story serves to really work.
Finally, the computer may not be able to estimate too great history. To reach the team estimate this story, it must be broken down into smaller.
Small: The size of the story matter, stories too large or too small can not be used in planning. Great stories and epics are difficult to work. The final determination of size is based on the team, capabilities and technologies used to perform it A story can be composite or complex. The story made comprises several stories that are visible.
Complex: The complex history, unlike composite, is very large, and can not easily be broken. If there is much uncertainty it creates complexity. In this case these stories can be split into a research and development.
Combinable: Sometimes the stories are too small. When the team says a story need not be written or estimated to be very small there is a problem. You can create further problems and not be documented. Whereupon these little stories should be combined into big to keep track of these stories.
Verifiable: It is important that the results of the tests show that the story was done successfully. If the story can not be verified, how can the team define when the story is end? Stories that can not be checked cater to non-functional, such as "The software should be easy to use" requirements. "The user does not have to wait long to display the login screen". We must try, moreover, that such tests be automated. You can automate more of what i was created. When a product is developed incrementally, things change very quickly, and something made yesterday may not work today. With these automated tests find that ruling as soon as possible.
There is a very small part of the evidence that can not be automated, you let perform, but possibly we will have covered more than 90% of the functionality automatically.
In conclusion, do not always make this possible, but it is a goal to read, to try to achieve, but above all the stories are negotiable between user and team, and as such must be written. They should be written by the client with the help of the team. In the story itself can be documented test cases that demonstrate its proper performance. If they are too large, divided both stories composite and complex, however, if too small, group then to give value to the customer. The stories are promises to speak, no detailed specifications. Technical infrastructure or stories, we must describe as provided needs in terms of customer value.
