User story é uma das ferramentas mais simples de produto. Um cartão com uma frase no formato "Como [usuário], quero [ação], para que [benefício]." Na teoria, é só isso. Na prática, é onde a qualidade do raciocínio de produto aparece — ou não aparece.

O formato e o que ele está tentando fazer

O formato de user story não é uma burocracia de processo ágil. É um lembrete de três perguntas que precisam estar respondidas antes de construir qualquer coisa: Quem é o usuário? O que eles querem fazer? Por que isso importa para eles?

Quando você escreve "Como usuário, quero um botão de exportar CSV, para que eu possa ter os dados", está respondendo as três perguntas de forma vaga. Quem é "usuário"? Por que CSV especificamente? Para fazer o que com os dados?

Uma story útil seria: "Como analista financeiro que precisa reportar para o CFO toda segunda, quero exportar o relatório de receita do mês anterior em formato compatível com Excel, para que eu possa incluí-lo direto na apresentação sem reformatação manual."

A segunda story guia o design, informa a engenharia sobre o contexto de uso e define o critério de sucesso de forma que pode ser verificada.

Critérios de aceite: onde as stories se tornam úteis (ou inúteis)

Os critérios de aceite são a lista de condições que precisam ser verdadeiras para a story ser considerada entregue. São o que o time usa para saber quando terminou — e o que o PM usa para verificar se o que foi construído resolve o problema.

Critérios de aceite fracos vs úteis

Critério fraco: "O botão de exportar deve funcionar." Isso é tautológico — claro que deve funcionar. Não informa nada sobre o que "funcionar" significa.

Critério útil: "Ao clicar em exportar, o sistema gera um arquivo .xlsx com as colunas [lista específica] e os dados do período selecionado, no máximo em 5 segundos para até 10.000 linhas, sem precisar de outra ação do usuário."

Esse critério pode ser verificado. Testa em cinco segundos se foi entregue. É isso que um bom critério de aceite faz.

Quantos critérios por story

Entre três e seis na maioria dos casos. Menos do que três provavelmente indica que a story está vaga. Mais do que seis provavelmente indica que a story está grande demais e deveria ser quebrada.

Quando user stories funcionam bem

Stories funcionam bem para funcionalidades com usuário final claro, interação definida e escopo delimitado. São especialmente úteis quando o time de engenharia e o PM estão alinhados sobre o problema mas precisam de clareza sobre o critério de entrega.

Quando a story está bem escrita, o time consegue estimar sem precisar de uma reunião de esclarecimento. Isso é o sinal mais claro de que ela está boa.

Quando user stories atrapalham

Stories atrapalham quando viram substituto para pensar o problema. Quando o PM escreve stories antes de entender o problema, produz uma lista de funcionalidades com contexto de usuário — o que parece ágil mas é feature factory com vocabulário diferente. A solução não é escrever stories mais detalhadas: é fazer discovery antes de escrever qualquer story, para que cada uma descreva um comportamento real do usuário, não uma funcionalidade escolhida sem base.

Stories também atrapalham quando são usadas para trabalho de infraestrutura ou de débito técnico que não tem usuário final direto. Nesses casos, o formato forçado gera histórias artificiais que ninguém acredita — e que treinam o time a ignorar o formato.

Quando usar épicos em vez de stories

Quando o escopo é grande demais para uma única story, use um épico: uma narrativa de nível mais alto que depois se quebra em stories menores. Épicos são úteis para planejamento de roadmap — onde você precisa de granularidade suficiente para comunicar intenção sem ter quebrado tudo em tarefas ainda.

Quem escreve as user stories

A resposta certa é: depende do time. Em alguns contextos, o PM escreve as stories e o time refina. Em outros, o time escreve e o PM revisa. O que não funciona é PM escrevendo stories em isolamento e entregando como especificação finalizada — sem refinamento com engenharia e design.

O refinamento de backlog existe justamente para isso: garantir que todo mundo entende o que está escrito, que os critérios de aceite fazem sentido técnico e que a story está no tamanho certo para ser desenvolvida numa sprint. Para entender como o PM participa desse processo, veja o artigo sobre o que faz um product manager no dia a dia.

O erro que torna as stories invisíveis

O erro mais comum não é de formato — é de contexto. Stories sem contexto do problema que motivou a feature são executadas mecanicamente. O time entrega o que foi pedido sem entender por quê. Quando surge uma decisão técnica no meio do desenvolvimento, não tem contexto para tomar a decisão certa.

A solução é simples: cada story ou épico deve ter uma linha explicando o problema que está sendo resolvido. "Por que estamos construindo isso? O que observamos que indica que esse é o problema certo?" Isso não é burocracia extra — é o contexto que transforma o time de executor em parceiro.