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.
