Podemos definir e organizar os requisitos de um sistema utilizando User Stories (histórias de usuário). User Stories são artefatos de desenvolvimento utilizados em sistemas geridos segundo metodologias ágeis.

Muitas perguntas são levantadas na hora de escrever User Stories, por exemplo:

     * User Stories são iguais Casos  de Uso?

     * Como descrevo minhas User Stories?

     * Que tipo de informações podemos inserir nas User Stories?

     * De quem e pra quem são feitas?

As respostas para essas perguntas são amplamente discutidas na comunidade Scrum e vamos tentar analisá-las abaixo.

Casos de Uso e User Stories são similares, como é apresentado por Martin Fowler em seu texto Use Cases and User Stories. Ambos são utilizados para organizar requisitos. Porém, enquanto Casos de Uso descrevem ações de interação segundo uma narrativa impessoal entre o usuário e o sistema, User Stories focam nos objetivos do usuário e como o sistema alcança esses objetivos.

User Stories fracionam os requisitos para que seja possível (e mais fácil) estimar o esforço para realizar aquele objetivo. Resumindo, User Stories são descrições simples que descrevem uma funcionalidade e é recomendável que sejam escritas segundo o ponto de vista do usuário.

User Stories devem ser curtas, simples e claras. Devemos conseguir escrevê-las em um simples e pequeno cartão (conhecidos como User Index Cards). Se não há espaço para escrevê-la em um cartão é porquê devemos refiná-la mais, e as dividir em outras User Stories.

Podemos construir User Stories como mostrado na figura abaixo. Especificando o ator, a ação e a funcionalidade desejada.

Ator – O proprietário da User Story. De forma simplista é o usuário, o interessado naquela funcionalidade. Mas é recomendado descrever de forma específica quem é o ator para ser mais fácil identificar o contexto da história dentro do sistema.

Ação – É o que o ator quer fazer. Utilizando aquela ação ele espera alcançar seu objetivo dentro do sistema.

Funcionalidade – É o que o ator espera que aconteça ao realizar a ação. Ou seja, é o resultado de executar a ação segundo a ótica do ator. Também pode ser visto como justificativa.


Alguns aspectos importantes podem ser notados no uso de User Stories:

  • Validar se a funcionalidade é realmente necessária antes de incluí-la
  • Análise das necessidades reais do usuário
  • Ajuda a priorizar o que deve ser feito
  • É mais fácil estimar o esforço que será necessário para implementar a funcionalidade

O interessante no uso de User Stories é o foco nas necessidades reais e práticas do usuário.

Imagine um sistema de aluguel de filmes pela internet, onde uma das funcionalidades do sistema é visualizar os filmes disponíveis para locação. Então a User Story para esse caso seria:

Agora, imagine o seguinte: além de visualizar os filmes disponíveis para locação, seria interessante que o cliente pudesse reservar também o filme desejado. Nesse caso a User Story seria:

A pergunta é: será que essa User Story é realmente útil agora de forma a atender ao que os usuários desejam mais nesse momento?

Perguntas como essa surgem constantemente no processo de planejamento das sprints e cabe ao PO pensar sobre a necessidade de implementar ou não tal funcionalidade nesse momento.

O cenário descrito acima apresentou como criar User Stories, mas quais são as vantagens em utilizar User Stories? No próximo post daremos continuidade ao assunto – “User Story”- falando também sobre como escrever os critérios de aceitação das User Stories.