Modelo de User Story com critérios de aceitação (Grátis)

Um modelo de história de usuário cumpre duas funções. Ele faz com que cada história responda às mesmas três perguntas (quem, o quê, por quê) e oferece à equipe um local fixo para registrar como saberão que a história está concluída. Esta página fornece ambos: o formato de uma linha, um modelo de cartão completo que você pode copiar, critérios de aceitação em três formatos, definição de pronto e concluído, e exemplos práticos.

Se você é novo em histórias de usuário, comece pelo nosso guia sobre como escrever user stories, e depois volte aqui para o modelo.

O modelo de história de usuário de uma linha

A maioria das equipes usa o formato que surgiu da equipe Connextra em Londres em 2001 e foi popularizado pelo livro User Stories Applied de Mike Cohn (sua visão geral de histórias de usuário é uma boa introdução):

Como [tipo de usuário], eu quero [uma ação ou capacidade], para que [um benefício ou resultado].

Cada parte tem uma função específica:

• “Como” nomeia um tipo real de usuário, como um comprador de primeira vez, um administrador de conta ou um paciente recorrente. “Como usuário” não diz nada à equipe. Se você tiver personas, use seus nomes.
• “Eu quero” descreve o que o usuário faz ou obtém, em suas próprias palavras. Não deve descrever a solução (“um menu suspenso”, “um cache Redis”); deixe espaço para a equipe encontrar a melhor opção.
• “Para que” declara o valor. Esta é a parte mais frequentemente ignorada e a que mais importa: é assim que a equipe pode propor uma opção mais simples que entregue o mesmo resultado, e como o product owner decide a prioridade.

Lembre-se de que a frase não é o requisito. Ron Jeffries descreveu uma história como três coisas: o cartão, a conversa e a confirmação (os 3 Cs). Um modelo ajuda com o cartão e a confirmação (os critérios de aceitação); nada substitui a conversa.

O modelo completo de cartão de história de usuário

A frase de uma linha é suficiente para um post-it. Em uma ferramenta de backlog, geralmente são necessários alguns campos adicionais para que a história possa ser priorizada, estimada e testada. Estes são os campos que achamos úteis; remova qualquer um que sua equipe nunca leia.

Mantenha “Contexto e notas” curto: se se transformar em uma página de especificação, a história provavelmente é uma épica e precisa ser dividida (nosso guia de mapeamento de histórias mostra como).

Modelo de história de usuário pronto para copiar

Cole isso no campo de descrição de uma issue do Jira ou Linear, em um modelo de banco de dados do Notion ou na linha de cabeçalho de uma planilha. Substitua o texto entre colchetes e exclua as linhas que não usar.

• ID: [PROJETO-000]
• Título: [Verbo + objeto, por exemplo “Exportar faturas para CSV”]
• História: Como [tipo de usuário], eu quero [ação ou capacidade], para que [benefício].
• Contexto: [Por que isso é importante agora; link para pesquisa, tickets de suporte ou métricas]
• Critérios de aceitação: [3 a 7 condições testáveis, em formato de lista de verificação ou Dado/Quando/Então]
• Fora do escopo: [O que esta história deliberadamente não cobre]
• Designs: [Link para o frame ou protótipo]
• Dependências: [Outras histórias, serviços ou decisões]
• Prioridade: [Deve / Deveria / Poderia, ou posição no backlog]
• Estimativa: [Pontos ou tamanho, preenchido pela equipe]
• Perguntas em aberto: [Qualquer coisa que precise ser respondida antes do início do sprint]

A linha “Fora do escopo” evita discussões: escrever “não inclui redefinição por SMS” no cartão é melhor do que descobrir na revisão do sprint que alguém assumiu que incluía.

O que são critérios de aceitação e quem os escreve

Critérios de aceitação são as condições que uma história deve atender para ser aceita pelo product owner. Eles descrevem o comportamento observável do ponto de vista do usuário, não como o código funciona. Bons critérios são:

• Testáveis: alguém pode dizer sim ou não sem interpretar. “Rápido” não é testável; “resultados aparecem em até dois segundos” é.
• Específicos para esta história: regras que se aplicam a todas as histórias (código revisado, implantado em staging) pertencem à definição de pronto, não aqui.
• Livres de detalhes de implementação: diga o que acontece, não qual componente ou tabela faz isso acontecer.
• Honestos sobre falhas: pelo menos um critério deve cobrir entrada inválida, falta de rede ou permissões ausentes.
• Poucos: três a sete critérios é uma faixa saudável. Mais de dez geralmente significa que a história deve ser dividida.

O product owner é responsável pelos critérios, mas não deve escrevê-los sozinho. O padrão mais confiável é uma breve conversa de refinamento entre produto, um desenvolvedor e um testador (frequentemente chamado de “three amigos”): qual é o valor, como isso será construído, como poderia falhar.

Formato 1: critérios de aceitação em lista de verificação

Uma lista simples de condições. É o formato mais rápido de escrever e ler, e funciona bem para histórias simples e para equipes que testam manualmente.

História: Como cliente recorrente, eu quero redefinir minha senha por e-mail, para que eu possa acessar minha conta novamente sem contatar o suporte.

• A tela de login tem um link “Esqueceu a senha?” que abre o formulário de redefinição.
• Enviar um endereço de e-mail registrado envia um link de redefinição em até um minuto.
• O link de redefinição funciona uma vez e expira após 30 minutos.
• A nova senha deve atender às regras de senha existentes, e o formulário indica qual regra falhou.
• Após um redefinição bem-sucedida, todas as outras sessões para essa conta são encerradas.
• Enviar um endereço não registrado exibe a mesma mensagem de confirmação que um endereço registrado, para que o formulário não revele quem possui uma conta.

Use a lista de verificação quando o comportamento for direto. Sua desvantagem é que ela oculta o estado inicial e a ordem dos eventos, o que o próximo formato torna explícito.

Formato 2: Critérios de aceitação Dado/Quando/Então (Gherkin)

Dado/Quando/Então vem do desenvolvimento orientado a comportamento, que Dan North descreveu com Chris Matts em Introducing BDD. Cada cenário descreve um contexto inicial (Dado), uma ação (Quando) e um resultado esperado (Então). Gherkin é a versão estruturada dessa linguagem usada pelo Cucumber e ferramentas semelhantes, para que cenários escritos dessa forma possam se tornar testes automatizados com poucas alterações de redação.

Aqui está a mesma história de redefinição de senha como três cenários, incluindo dois caminhos de falha.

Cenário 1: redefinição com um link válido

• Dado que tenho uma conta registrada em anna@example.com
• E que solicitei uma redefinição de senha
• Quando abro o link de redefinição em até 30 minutos e insiro uma nova senha que atende às regras
• Então minha senha é alterada
• E estou conectado
• E minhas outras sessões são encerradas

Cenário 2: o link expirou

• Dado que solicitei uma redefinição de senha há mais de 30 minutos
• When eu abro o link de redefinição
• Then eu vejo uma mensagem de que o link expirou
• E que me é oferecido um botão para enviar um novo link

Cenário 3: o endereço de e-mail não está registrado

• Dado que não existe conta para sam@example.com
• Quando solicito uma redefinição de senha para sam@example.com
• Então vejo a mesma mensagem de confirmação que um usuário registrado vê
• E nenhum e-mail é enviado

Quando um cenário precisa ser executado com várias entradas (por exemplo, uma lista de senhas que devem ser rejeitadas), o Scenario Outline do Gherkin permite escrevê-lo uma vez e listar as entradas em uma tabela de exemplos.

Mantenha o Gherkin legível: um comportamento por cenário, e escreva de forma declarativa (“Quando solicito um link de redefinição”) em vez de passo a passo (“Quando clico no botão Enviar”), para que o cenário sobreviva a um redesenho.

Formato 3: Critérios de aceitação baseados em regras

Para histórias que são principalmente regras de negócio (preços, elegibilidade, validação, permissões), declare as regras diretamente e adicione cenários apenas para as combinações complexas.

História: Como comprador, quero aplicar um código de desconto no checkout, para que eu pague o preço promocional.

• Regra 1: um código por pedido.
• Regra 2: um código percentual se aplica apenas ao subtotal do produto, não ao frete ou imposto.
• Regra 3: um código com gasto mínimo se aplica apenas quando o subtotal, antes do desconto, atinge o mínimo.
• Regra 4: códigos expirados ou esgotados são rejeitados com uma mensagem que explica o motivo.
• Regra 5: remover itens para que o subtotal caia abaixo do mínimo remove o código e exibe um aviso.

Você pode misturar formatos em uma única história. Um padrão comum é usar regras para a lógica, mais dois ou três cenários Dado/Quando/Então para os casos que as pessoas têm mais probabilidade de interpretar incorretamente.

Definição de pronto vs. definição de concluído

Os critérios de aceite são específicos para uma história. A definição de pronto e a definição de concluído são acordos de equipe que se aplicam a todas as histórias.

O Guia Scrum define a definição de concluído como a descrição formal do estado do Incremento quando ele atende às medidas de qualidade exigidas para o produto. A definição de pronto não faz parte do Scrum; é uma prática adotada por muitas equipes para evitar que trabalho mal compreendido entre em uma sprint (veja o glossário da Agile Alliance sobre definição de pronto e definição de pronto).

Exemplo de definição de pronto

• A história segue o modelo e o campo “para que” está preenchido.
• Os critérios de aceite são escritos e revisados por produto, desenvolvimento e testes.
• Os designs estão vinculados, ou a equipe concordou que nenhum é necessário.
• As dependências estão concluídas ou agendadas.
• A equipe a estimou e ela cabe em uma sprint.

Exemplo de definição de concluído

• Todos os critérios de aceite são atendidos.
• O código é revisado e mesclado no branch principal.
• Os testes automatizados cobrem o novo comportamento e a suíte completa passa.
• As verificações básicas de acessibilidade são aprovadas (uso do teclado, rótulos, contraste).
• Está implantado no ambiente de staging e o product owner o aceitou.

Trate a definição de pronto como uma lista de verificação para refinamento, não como uma barreira. Se uma equipe rejeitar toda história que não marcar uma caixa, o trabalho desacelera e a conversa que a história deveria iniciar nunca acontece.

Exemplos práticos

Duas histórias mais de diferentes tipos de produto. Para mais quarenta, veja nosso exemplos de histórias de usuário.

SaaS: convidar um colega de equipe (checklist)

Como administrador de workspace, quero convidar um colega de equipe por e-mail, para que ele possa ver nossos projetos sem que eu compartilhe meu login.

• Administradores veem um botão “Convidar” na página de membros; outros papéis não veem.
• O administrador pode escolher o papel (Membro ou Administrador) antes de enviar.
• O e-mail de convite chega em até um minuto e o link é válido por sete dias.
• Convidar um endereço que já é membro exibe uma mensagem em vez de enviar um segundo convite.

E-commerce: salvar um item para depois (Given/When/Then)

Como um comprador que não está pronto para comprar, quero mover um item do meu carrinho para uma lista salva, para que eu possa encontrá-lo novamente sem que isso afete o total do meu pedido.

• Dado que estou autenticado e tenho dois itens no meu carrinho
• Quando eu escolho “Salvar para depois” em um item
• Então esse item se move para minha lista salva
• E o total do meu carrinho é recalculado sem ele
• Dado que não estou autenticado
• Quando eu escolho “Salvar para depois”
• Então sou solicitado a fazer login, e o item é salvo assim que eu o faço

Usando o modelo no Jira, Linear, Notion ou uma planilha

No Jira, use o tipo de problema Story e cole o modelo na descrição (ou mantenha os critérios de aceitação em um campo dedicado, se seu administrador tiver adicionado um). No Linear, salve-o como um modelo de problema. No Notion, coloque-o em um modelo de banco de dados para que novas páginas de backlog abram pré-preenchidas. Uma planilha com uma linha por história funciona para um primeiro backlog ou uma oficina, mas migre para um rastreador assim que várias pessoas o editarem. Independentemente da ferramenta, mantenha o modelo curto o suficiente para que as pessoas o preencham.

Redigindo histórias e critérios de aceitação com IA

Os modelos de linguagem são bons para um primeiro rascunho de histórias e critérios. Um prompt que funciona:

Você é um product manager. Para o recurso abaixo, escreva histórias de usuário no formato “Como [usuário], quero [ação], para que [benefício]”. Para cada história, adicione de 3 a 6 critérios de aceitação na forma Given/When/Then, incluindo pelo menos um caminho de erro. Liste quaisquer pressupostos e perguntas em aberto separadamente. Recurso: [descreva o recurso, os usuários e quaisquer restrições].

Depois, revise o rascunho como qualquer outra entrada:

• O usuário é um segmento real com o qual você conversou, ou um “usuário” genérico?
• O modelo inventou regras de negócio, limites ou números? Substitua-os pelos seus.
• Os caminhos de erro são aqueles que seus usuários realmente enfrentam? Um rascunho nunca substitui a conversa de refinamento.

Perguntas frequentes

Quer uma equipe para transformar suas histórias em software funcional? Traga seu backlog, ou apenas a ideia, e ajudaremos a moldá-la em histórias do tamanho de um sprint e a construí-la. Veja nossos planos de desenvolvimento mensais.