AAA Toolbox: User Stories

05 Feb 2012

Esse é um post de uma série que eu compartilhei internamente na ThoughtWorks uns anos atrás. Eu escrevi em inglês, então republico assim, mas se a série acabar sendo bem popular, eu prometo traduzir tudo.

User stories are a staple of agile business analysis. Each one represents a unit of work that should be developed. Since in most healthy projects all the work that is done should contribute to achieving a greater goal, the story must have some value (commonly called "business value") to whoever it will be implemented for. Stories are commonly used to represent units of work as they progress trough the the many steps of an agile development process.

In its most basic form a user story is a one line description of a task at hand written in a card, for instance:

• Process a reservation for a given category on a given date
• Export the questionnaire data in Excel format
• The logout story

Stories are frequently context sensitive, i.e.: a story depends on some shared knowledge. In the examples above, the reader don't know what is being reserved, how big is the questionnaire, or what its logging out of. In fact, these can have wildly different interpretations (and maybe not even be stories) depending on the particular situation. That is because stories, in essence are "promises to converse", according to Mike Cohn. This means that stories are not supposed to describe all that needs to be done, but only enough to set the stage for a conversation between people involved. They must "represent rather than document".

Ron Jeffries lists three critical aspects of a story with an easy-to-remember alliteration: Card, Conversation and Confirmation. The "card" purpose is to make sure that stories are short and can be moved around, so it is easy to bring it to a conversation and it can represent that unit of work across the project. The "conversation" aspect is that a story shouldn't be considered a complete document. Finally, by "confirmation" is about the fact that a story implies a set of success criteria. In most agile projects (or at least the ones that do TDD), it means that for any given story, a number of acceptance tests must be implemented to confirm that the resulting code does what it is supposed to do. Those acceptance criteria are usually recorded against a story so it is possible to relate application behavior with an underlying business value.