Modelo de história de usuário e critérios de aceitação

O modelo de história de usuário consiste em uma frase com três espaços em branco:

Como [função], quero [objetivo], para que [benefício].

Copie, use, mas saiba para que serve: o modelo é um ponto de partida para uma conversa, não um formulário a ser preenchido. Uma frase preenchida é onde o refinamento começa. O que torna a história viável é o que vem a seguir — os critérios de aceitação que transformam uma intenção acordada em um teste de aprovação/reprovação, e a estimativa que a transforma em um trabalho planejável. Este capítulo acompanha uma história por todas as três etapas.

Preencher as lacunas sem inventar respostas

Cada slot apresenta uma falha comum, e cada uma dessas falhas pode ser verificada:

• [função] — uma pessoa específica, nunca “um usuário”. Se você não conseguisse identificar essa pessoa em suas análises ou na fila de suporte, a função é mera decoração. Teste: um designer poderia tomar uma decisão diferente por causa da função que você escolheu?
• [objetivo] — o que a pessoa faz, em seus próprios termos. “Quero redefinir minha senha” pertence ao usuário; “Quero um microsserviço de redefinição de senha” pertence ao diagrama de arquitetura. Teste: a pessoa realmente diria essa frase?
• [benefício] — o argumento a favor do agendamento do trabalho. Teste: exclua a cláusula. Se nada for perdido, o benefício ainda não foi identificado.

A explicação completa sobre o formato — incluindo os três Cs e a lista de verificação INVEST que uma história de usuário finalizada deve atender — está em O que é uma história de usuário?. Dezesseis exemplos práticos, bons e ruins, estão em Exemplos de histórias de usuário.

Um cartão de história copiado e colado

Essa frase por si só não é suficiente para dar início a um sprint. Aqui está o modelo completo do cartão que vale a pena adotar como padrão — história, critérios, limites e, por último, o tamanho:

Story
  As a [role], I want [goal], so that [benefit].

Acceptance criteria (3–5, each pass/fail)
  - [ ] …
  - [ ] …
  - [ ] …

Out of scope
  - What this story deliberately does NOT cover.

Notes & dependencies
  - Designs, decisions, other teams, open questions.

Size: [added by the team, after the conversation — never before]

Há duas escolhas deliberadas nesse cartão. “Fora do escopo” é fundamental: a maioria das discussões sobre estimativas ocorre quando duas pessoas avaliam escopos diferentes, e uma única linha aqui evita que isso aconteça. O tamanho vem por último: um número escrito no cartão antes que a equipe o discuta se torna uma âncora, o que é o primeiro dos clássicos erros do planning poker.

Variantes de modelo

O modelo clássico é a opção padrão correta, mas não é a única forma que funciona.

Variante	Forma	Recorra a ele quando
Clássico (Connextra)	Como [função], quero [objetivo], para que [benefício]	A abordagem padrão para o trabalho voltado para o usuário
História do trabalho	Quando [situação], quero [motivação], para que eu possa [resultado]	O momento decisivo explica mais do que a persona — a mesma pessoa, quando está no trem, deseja coisas diferentes das que deseja quando está sentada à mesa
O benefício em primeiro lugar	Para [beneficiar], na qualidade de [função], quero [objetivo]	A equipe continua redigindo benefícios circulares; colocar a cláusula no início torna impossível ignorá-la
Enunciado do problema em linguagem simples	Uma frase descrevendo o problema, outra descrevendo o resultado, além dos critérios de “conclusão”	Trabalho técnico e de plataforma em que a única figura honesta seria a própria equipe

A última linha é mais importante do que parece. Alguns itens do backlog não têm nenhum usuário na frase, e fingir o contrário gera frases de preenchimento como “como desenvolvedor, quero que a estrutura seja atualizada”. A disciplina do modelo — uma razão declarada mais critérios testáveis — se aplica a esse trabalho; a forma da frase, por sua vez, não precisa ser mantida.

Critérios de aceitação: a confirmação no cartão

Os critérios de aceitação são as condições de aprovação ou reprovação da história, definidas antes do início do trabalho. No cartão, eles cumprem duas funções: registram o que foi efetivamente acordado na conversa de refinamento e definem a meta final para a qual a estimativa será direcionada. Dois formatos abrangem praticamente todas as histórias:

Uma lista de verificação simples, para condições independentes:

• O conteúdo do carrinho é mantido por 30 dias, mesmo entre sessões.
• Um cliente recorrente pode visualizar o carrinho de compras a partir de qualquer dispositivo no qual tenha feito login.
• Um carrinho esvaziado permanece vazio (não há recuperação dos itens removidos).

Dado/Quando/Então, para comportamentos que dependem do estado:

• Suponha que um cliente tenha um carrinho salvo; quando um item fica sem estoque, então o carrinho exibe o item desativado, com a indicação “sem estoque”, em vez de removê-lo sem aviso prévio.

Use a lista de verificação como padrão; recorra ao modelo “Dado que/Quando/Então” quando a pré-condição estiver envolvendo trabalho efetivo. Mantenha a lista com três a cinco itens — uma lista mais longa geralmente significa que a história deve ser dividida, e os critérios indicam onde fazer o corte. Para uma abordagem completa (critérios x requisitos, critérios x definição de concluído, quem os redige), consulte o capítulo sobre critérios de aceitação.

Exemplo prático: um andar, modelo para estimativa

Veja a seguir o desenrolar de uma história real, com base na carta acima.

Passo 1 — a história. O proprietário do produto escreve:

Como estou comprando pela primeira vez, quero finalizar a compra sem criar uma conta, para poder concluir a transação antes de mudar de ideia.

Etapa 2 — a conversa, registrada como critérios. No aperfeiçoamento do backlog, a equipe identifica os detalhes que a frase não transmite e os anota:

• Um comprador pode concluir a compra apenas com o e-mail e os dados de entrega, sem precisar de senha.
• O e-mail de confirmação do pedido oferece a criação de conta com um clique (pedido já anexado).
• O suporte técnico pode localizar um pedido de cliente usando o número do pedido e o e-mail.
• O checkout como convidado segue as mesmas verificações antifraude que o checkout com conta.

Fora do escopo: conversão de pedidos históricos de hóspedes quando uma conta é criada posteriormente.

Etapa 3 — a verificação de prontidão. Quatro critérios, uma exclusão explicitada, nenhuma dependência não confirmada: a história atende à definição de prontidão e segue para a equipe para avaliação do escopo.

Etapa 4 — a estimativa. A equipe vota em uma rodada de planning poker. São reveladas as cartas 3, 5, 5, 8. O 8 se explica: o critério de verificação de fraudes implica mexer na integração com o provedor de pagamentos, algo que ninguém mais havia levado em conta na estimativa. É assim que os critérios cumprem sua verdadeira função — a discussão é sobre o escopo, não sobre qual número está certo. A equipe vota novamente e chega a um consenso em 5.

Observe a ordem: primeiro os critérios, depois os pontos. Uma história estimada antes que seus critérios existam gera variações amplas e irresolúveis que atrasam as sessões de dimensionamento — a equipe está votando em histórias diferentes que, por acaso, compartilham o mesmo título.

Perguntas frequentes

O que é o modelo de história de usuário?

“Como [função], quero [objetivo], para que [benefício].” A função indica quem recebe o valor, o objetivo define a capacidade nos termos dessa pessoa e o benefício é a razão pela qual o trabalho merece um lugar no backlog. O modelo serve como um ponto de partida para uma conversa, não como um formulário a ser preenchido — é ao preencher os espaços em branco que começa o refinamento.

Como se redigem os critérios de aceitação de uma história de usuário?

Escreva de três a cinco condições testáveis que indiquem, com “aprovado” ou “reprovado”, se a história cumpriu o que foi acordado. Use uma lista de verificação simples quando as condições forem independentes e o padrão “Dado que/Quando/Então” quando o comportamento depender do estado. Cada critério deve poder ser verificado por um testador que nunca tenha participado da conversa de refinamento.

Os critérios de aceitação devem seguir o formato “Dado que/Quando/Então” ou uma lista de verificação?

Adapte o formato ao comportamento. O padrão “Dado que/Quando/Então” mostra seu valor quando o resultado depende de um estado inicial, pois obriga você a definir a pré-condição, o gatilho e o resultado. Uma lista de verificação é mais rápida de ler e mais difícil de inflar quando a história se resume a “essas quatro coisas devem ser verdadeiras”. A maioria das histórias precisa apenas da lista de verificação.

O que é uma história de trabalho?

Uma variante que substitui a persona por uma situação: “Quando [situação], eu quero [motivação], para que eu possa [resultado].” As histórias de tarefas têm origem na escola dos “trabalhos a serem realizados” e funcionam bem quando o momento desencadeador explica a necessidade melhor do que uma persona — a mesma pessoa quer coisas diferentes quando está em sua mesa e quando está no trem.

Todos os itens do backlog precisam do modelo de história de usuário?

Não. O modelo descreve o valor para o usuário, e aplicá-lo à força ao trabalho em plataformas, a bugs conhecidos ou a picos de pesquisa resulta em frases que acrescentam formalidades sem trazer informações. Mantenha os dois elementos que sempre se aplicam — uma justificativa clara e critérios de aceitação testáveis — e deixe que a estrutura da frase se adapte ao trabalho.

Leituras relacionadas

• Estimativa ágil: o guia completo — o ponto central para tudo o que diz respeito a esse assunto.
• O que é uma história de usuário? — o raciocínio por trás do modelo: os três Cs e o INVEST.
• Exemplos de histórias de usuário — dezesseis histórias comentadas para servir de referência.
• Critérios de aceitação: como redigi-los — o capítulo completo sobre a etapa de confirmação.
• Definição de “pronto” — o estágio que uma tarefa baseada em modelo deve superar para entrar no sprint.
• O que são pontos de história? — a unidade usada para dimensionar o cartão concluído.