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 métricas de análise ou na sua 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 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 do tipo “copiar e colar”

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, com a descrição, os critérios, os limites e o tamanho adicionado por último:

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 isso quando
Clássico (Connextra)	Como [função], quero [objetivo], para que [benefício]	A configuração padrão para o trabalho voltado ao usuário
História profissional	Quando [situação], quero [motivação], para que eu possa [resultado]	O momento desencadeador explica mais do que a persona (a mesma pessoa em um trem deseja coisas diferentes das que deseja quando está sentada à mesa)
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 simples do problema	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 um 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; o formato da frase, por si só, não precisa ser mantido.

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 entre as sessões por 30 dias.
• 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 (em cinza) 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 mostram a você onde fazer o corte. Para uma abordagem completa (critérios x requisitos, critérios x definição de conclusão, quem os redige), consulte o capítulo sobre critérios de aceitação.

Exemplo prático: um andar, modelo para estimativa

Veja a seguir como se desenrola uma história real, usando a carta acima.

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

Como sou um comprador de primeira viagem, 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 aspectos 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 não registrado por meio do número do pedido e do e-mail.
• O checkout como convidado segue as mesmas verificações antifraude do 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 declarada, 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 é explicado da seguinte forma: 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 no cálculo. É 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 acaba 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 identifica 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 para 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 preencher com conteúdo desnecessário 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 “job story”?

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 de trabalho 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 plataforma, 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.

Leitura relacionada

• Estimativa ágil: o guia completo: o centro de informações sobre tudo o que há para saber sobre o assunto.
• O que é uma história de usuário?: a lógica 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 redigí-los: o capítulo completo sobre a etapa de confirmação.
• Definição de “pronto”: a etapa que uma tarefa baseada em modelo precisa superar para entrar no sprint.
• O que são pontos de história?: a unidade usada para dimensionar o cartão finalizado.