Menu

Histórias de Usuário (User Stories)

Short Tip: Lembrete de um requisito necessário ao produto.

O que é?

Uma história de usuário (user story) é uma técnica utilizada para capturar uma necessidade do produto. Diferentemente de outros métodos de especificação pormenorizada de requisitos (ex. use case), uma história contém apenas as informações necessárias para gerar uma conversa entre a equipe de desenvolvimento e o Product Owner acerca da necessidade do usuário.

As user stories costumam seguir os 3C’s indicados por Ron Jeffries:

  • Cartão: as histórias devem ser escritas em cartões, onde não cabe uma especificação detalhada;
  • Conversa: o requerimento deve ser comunicado para o time por uma conversa, não um documento formal;
  • Confirmação: deve existir um método para verificar se a história foi elaborada conforme discutido, normalmente critérios de aceitação.

Por que Aplicar?

Por ser simples e rápida, a user story mostra-se adequada para capturar uma necessidade sem desperdiçar tempo em detalhamentos excessivos. Essa abordagem é alinhada com o princípio “indivíduos e interações sobre processos e ferramentas” do Manifesto Ágil.

Como Aplicar?

Apesar de não ser obrigatório, o padrão mais comum para a escrita de uma user story é baseada no template “Como/eu quero/para”, conforme abaixo.

Como ______________________________ (tipo de usuário do produto)

Eu quero ___________________________  (requisito)

Para _______________________________ (necessidade a ser atendida)

Para orientar a equipe de desenvolvimento sobre como uma história será avaliada pelo Product Owner, é comum escrever no verso do cartão da história os critérios de aceitação. Recomenda-se o uso do seguinte template para a sua elaboração:

Dado que  ____________________________ (a pré-condição da ação)

Quando ______________________________ (ação junto ao produto)

Então  _______________________________ (comportamento esperado do produto)

Uma boa user story deve também passar pelo teste INVEST elaborado por Bill Wake.

  • I (Independente): a história deve ser o máximo independente de outras, a ponto de ser possível modificar sua posição no Backlog sem outros impactos;
  • N (Negociáveis): a história não deve rígida, mas sim deve gerar uma discussão aberta e flexível;
  • V (Valorosa): a entrega indicada na história deve gerar valor para o usuário do produto;
  • E (Estimável): a história deve ser possível de ser estimada pelos Developers;
  • S (Pequena / Small): a história deve ser pequena o suficiente para caber em uma Sprint;
  • T (Testável): deve haver um acordo sobre como a história será avaliada, com base em testes. Normalmente critérios de aceitação são utilizados para esse fim.