Guia BA
Primeira User Story? Guia completo: da solicitação vaga até o Jira
Como transformar uma solicitação vaga em uma User Story que o time consegue construir e testar de verdade.
Surya · 15 de agosto de 2026 · 8 min de leitura · 17 práticas
Para BAs iniciantes escrevendo sua primeira User Story, BAs juniores ainda ajustando o próprio processo, Product Owners escrevendo suas próprias User Stories e Membros do time de entrega aprendendo como requisitos são escritos.
Alguém diz: "Você consegue criar uma story no Jira pra isso?" Você diz que sim. Aí você abre o Jira. Caixa de descrição em branco. E uma pergunta muito simples fica surpreendentemente difícil: o que exatamente eu devo escrever aqui? Se essa é sua primeira User Story, comece por aqui. Porque o maior erro é achar que você precisa inventar algo brilhante. Você não precisa. Aqui vai a única coisa que você precisa lembrar antes de tudo: uma story está pronta quando outra pessoa consegue entendê-la sem você sentado do lado explicando. Tudo o que vem a seguir existe para te levar até esse ponto — é o teste que você está construindo, não só mais um item de checklist no final. E a parte mecânica — "Como... eu quero... para que..." — leva vinte segundos para escrever. Tudo o resto é o trabalho de verdade: descobrir o que essa frase deveria dizer. Uma User Story não é algo que você inventa. É algo que você descobre. Vamos fazer uma juntos, de uma solicitação vaga até uma story completa que um desenvolvedor e um testador conseguem colocar em prática.
01Passo 01
A solicitação que já parece uma story
"Precisamos de um botão de download para os extratos mensais" é fácil de reescrever como story. Essa é a armadilha.
Passo 01
A solicitação que já parece uma story
"Precisamos de um botão de download para os extratos mensais" é fácil de reescrever como story. Essa é a armadilha.
O fluxo
Comparação
O que você poderia escrever de imediato
Como cliente, eu quero um botão de download, para que eu possa baixar meu extrato.
O que é verdade, na prática
Ainda não entendemos o requisito — trate a solicitação como uma pista, não como uma especificação.
Por que isso ajuda
Tecnicamente, essa primeira versão até parece uma User Story. Só que ainda não é uma. Não escreva isso antes de fazer algumas perguntas.
02Passo 02
Separe o problema da solução
Um botão é uma solução proposta. Pergunte qual problema ele resolve antes de perguntar como ele deve funcionar.
Passo 02
Separe o problema da solução
Um botão é uma solução proposta. Pergunte qual problema ele resolve antes de perguntar como ele deve funcionar.
A mudança
Por que isso ajuda
Stakeholders propõem soluções porque é a linguagem que eles conhecem — "precisamos de um botão" é mais fácil de dizer do que "precisamos de um processo". Seu trabalho é encontrar o problema por trás da proposta.
03Passo 03
Nomeie o usuário específico
"Clientes" ainda é genérico demais para desenhar a solução. Não é sobre "usuários" — é sobre quais usuários.
Passo 03
Nomeie o usuário específico
"Clientes" ainda é genérico demais para desenhar a solução. Não é sobre "usuários" — é sobre quais usuários.
Resumo
- Clientes de varejo?
- Clientes corporativos?
- Assessores de investimento?
- Usuários internos de operações?
Por que isso ajuda
Um cliente de varejo consultando o próprio extrato tem necessidades diferentes de um atendente de suporte consultando em nome de outra pessoa. Usuários mal definidos geram stories vagas — suponha que a resposta seja "clientes de varejo usando o internet banking": agora você sabe para quem está desenhando.
04Passo 04
Defina o resultado real
O que o usuário ganha quando isso funciona?
Passo 04
Defina o resultado real
O que o usuário ganha quando isso funciona?
No caso do botão de download, não é "um download" — é "uma cópia do meu extrato para os meus registros". Essa diferença define o formato, a retenção e as regras de acesso mais adiante. Talvez a resposta completa seja: "Eles precisam guardar cópias dos extratos mensais para declarar imposto de renda, solicitar empréstimos e manter como registro pessoal". Agora você tem o valor — e a User Story básica praticamente se escreve sozinha.
Por que isso ajuda
Uma story sem um resultado real por trás dela é só uma solicitação de funcionalidade reescrita. É essa peça que torna a linha "para que" verdadeira, e não apenas decorativa.
05Passo 05
Escreva a primeira versão — e saiba que ainda não terminou
A story de três linhas é a manchete. O requisito útil mora por baixo dela.
Passo 05
Escreva a primeira versão — e saiba que ainda não terminou
A story de três linhas é a manchete. O requisito útil mora por baixo dela.
Por que isso ajuda
Essa é uma User Story perfeitamente razoável. Só que ainda não está pronta. Tudo a partir daqui é o que transforma uma manchete em algo que o time realmente consegue construir e testar.
Como cliente de banco de varejo, eu quero baixar os extratos mensais da minha conta, para que eu possa guardar cópias para meus registros pessoais.
06Passo 06
Adicione o contexto suficiente
Alguém que abrir esse card daqui a três meses deve entender por que ele existe.
Passo 06
Adicione o contexto suficiente
Alguém que abrir esse card daqui a três meses deve entender por que ele existe.
Por que isso ajuda
Você não precisa escrever um ensaio. Só dê à próxima pessoa o suficiente para que ela não precise te procurar e perguntar "por que estamos fazendo isso mesmo?"
Atualmente, os clientes conseguem ver a movimentação recente da conta online, mas extratos mais antigos precisam ser solicitados via atendimento ao cliente. Isso gera chamados de suporte desnecessários e atrasa clientes que precisam dos extratos para guardar registros.
07Passo 07
Registre as regras de negócio
As restrições operacionais que moldam a funcionalidade — independentes de qualquer critério de aceitação isolado.
Passo 07
Registre as regras de negócio
As restrições operacionais que moldam a funcionalidade — independentes de qualquer critério de aceitação isolado.
Resumo
- Clientes podem acessar extratos dos últimos 24 meses.
- Extratos são gerados mensalmente.
- Somente extratos do cliente logado podem ser acessados.
- Extratos ficam disponíveis em arquivos PDF.
Por que isso ajuda
Nada disso apareceu em "precisamos de um botão de download". É por isso que a conversa importa mais do que o formulário — um formulário só captura aquilo que você lembrou de perguntar.
08Passo 08
Escreva critérios de aceitação que realmente se sustentam
É aqui que a maioria das stories falha na prática, então trate isso como uma disciplina própria, não como uma formalidade.
Passo 08
Escreva critérios de aceitação que realmente se sustentam
É aqui que a maioria das stories falha na prática, então trate isso como uma disciplina própria, não como uma formalidade.
Resumo
- CA1 — Dado que o cliente está logado no internet banking, quando ele abre a seção de Extratos, então os extratos mensais disponíveis dos últimos 24 meses são exibidos.
- CA2 — Dado que um extrato está disponível, quando o cliente seleciona Baixar, então o extrato correspondente é baixado em PDF.
- CA3 — Dado que um cliente solicita um extrato que não pertence à sua conta, quando a solicitação é feita, então o acesso é negado.
Checklist
- Uma afirmação por critério — se o "Então" junta dois resultados diferentes com um "e", divida em dois CAs
- Torne o "Então" observável e testável, não aspiracional
- Escreva os casos negativos e de limite, não só o fluxo principal
- Evite transformar decisões de interface em critério de aceitação, a menos que a própria interação seja o requisito
Por que isso ajuda
Agora o time de desenvolvimento tem algo concreto, o QA tem algo testável, e você tem algo que realmente consegue validar.
09Passo 09
Escreva os cenários de exceção
É aqui que stories de iniciantes costumam parar cedo demais.
Passo 09
Escreva os cenários de exceção
É aqui que stories de iniciantes costumam parar cedo demais.
Checklist
- E se o extrato ainda não tiver sido gerado?
- E se o serviço de PDF estiver indisponível?
- E se não houver extratos para aquele mês?
- E se o cliente tiver múltiplas contas?
- E se o download do extrato falhar?
Por que isso ajuda
Você não vai precisar de um requisito para cada cenário imaginável. Mas você deve pelo menos saber quais importam antes que o desenvolvimento comece a chutar.
10Passo 10
Documente os requisitos de dados
Qual informação essa funcionalidade realmente precisa?
Passo 10
Documente os requisitos de dados
Qual informação essa funcionalidade realmente precisa?
Resumo
- ID do Cliente
- ID da Conta
- Mês do extrato
- Ano do extrato
- ID do Documento
- Formato do arquivo
- Status de disponibilidade do extrato
Por que isso ajuda
Você não está tentando desenhar o banco de dados. Você está garantindo que todo mundo concorde sobre quais informações a funcionalidade realmente precisa.
11Passo 11
Deixe as dependências visíveis
A tela pode ser simples. A funcionalidade pode não ser.
Passo 11
Deixe as dependências visíveis
A tela pode ser simples. A funcionalidade pode não ser.
Resumo
- Serviço de Gestão de Documentos
- Serviço de Autenticação
- Processo de geração de extratos
- API de recuperação de extratos
Por que isso ajuda
Você não precisa resolver todas elas dentro da sua story. Mas precisa saber que elas existem antes que alguém se comprometa com uma data de entrega.
12Passo 12
Deixe claro o limite de escopo
Isso leva trinta segundos e evita uma quantidade surpreendente de confusão depois.
Passo 12
Deixe claro o limite de escopo
Isso leva trinta segundos e evita uma quantidade surpreendente de confusão depois.
Resumo
- Envio de extratos por e-mail
- Extratos com mais de 24 meses
- Redesenho do PDF do extrato
- Geração de extratos avulsa
Por que isso ajuda
Agora, se alguém disser depois "eu achei que também íamos enviar por e-mail", você sabe exatamente para onde apontar.
13Passo 13
Saiba quando dividir a story
Uma story que não consegue ser entregue como uma única unidade de trabalho não é uma story só — são várias disfarçadas de uma.
Passo 13
Saiba quando dividir a story
Uma story que não consegue ser entregue como uma única unidade de trabalho não é uma story só — são várias disfarçadas de uma.
Comparação
Uma story
Clientes podem baixar extratos, visualizá-los no celular, e a equipe interna pode gerá-los sob demanda — tudo no mesmo card.
Várias stories disfarçadas de uma só
Um fluxo web, um fluxo mobile e um processo de exceção para a equipe interna são três interfaces diferentes e três conversas diferentes.
Checklist
- Por variação de regra — a mesma ação se comporta de forma diferente conforme a regra de negócio?
- Por fonte de dados — se parte da story depende de um dado ou sistema que ainda não está pronto, essa parte é uma story separada
- Por interface — um fluxo web e um fluxo mobile para o mesmo resultado geralmente são duas stories
- Por fluxo principal vs. tratamento de exceção — tratamento de exceção complexo que precisa da sua própria conversa de design deveria ser separado
Por que isso ajuda
O teste rápido: se você não consegue descrever os critérios de aceitação em menos de um minuto, ou a story tem mais de sete CAs, é bem provável que sejam duas stories.
14Passo 14
Mantenha suas questões em aberto visíveis
Não esconda questões não resolvidas no seu caderno. Escreva-as em vez de chutar.
Passo 14
Mantenha suas questões em aberto visíveis
Não esconda questões não resolvidas no seu caderno. Escreva-as em vez de chutar.
Resumo
- Extratos de contas encerradas devem continuar acessíveis?
- Contas conjuntas estão incluídas?
- O período de retenção de 24 meses é configurável?
Por que isso ajuda
Um requisito com questões visíveis é muito mais seguro do que um requisito fingindo que tudo já está resolvido.
15Passo 15
A story completa no Jira
Veja no que "precisamos de um botão de download" se transformou.
Passo 15
A story completa no Jira
Veja no que "precisamos de um botão de download" se transformou.
A parte mais difícil não foi escrever Como... eu quero... para que... — isso levou uns vinte segundos. O trabalho de verdade foi entender tudo em volta disso.
Por que isso ajuda
O modelo ajuda. Mas são as perguntas que criam o requisito — essa é a diferença entre reescrever uma solicitação e realmente entendê-la.
TÍTULO Permitir que clientes baixem extratos mensais da conta CONTEXTO Atualmente, os clientes conseguem ver a movimentação recente da conta online, mas extratos mais antigos precisam ser solicitados via atendimento ao cliente. PROBLEMA DE NEGÓCIO Clientes não conseguem acessar extratos anteriores sozinhos, gerando chamados de suporte desnecessários e atrasos. USER STORY Como cliente de banco de varejo, eu quero baixar os extratos mensais da minha conta, para que eu possa guardar cópias para meus registros pessoais. REGRAS DE NEGÓCIO 1. Extratos ficam disponíveis pelos últimos 24 meses. 2. Somente extratos pertencentes ao cliente autenticado podem ser acessados. 3. Extratos são disponibilizados em formato PDF. 4. Extratos são gerados mensalmente. CRITÉRIOS DE ACEITAÇÃO CA1 Dado que o cliente está autenticado Quando ele abre a seção de Extratos Então os extratos mensais disponíveis dos últimos 24 meses são exibidos. CA2 Dado que um extrato está disponível Quando o cliente seleciona Baixar Então o PDF correspondente é baixado. CA3 Dado que o extrato solicitado não pertence ao cliente autenticado Quando a solicitação é feita Então o acesso é negado. REQUISITOS DE DADOS ID do Cliente ID da Conta Período do extrato ID do Documento Status do extrato DEPENDÊNCIAS Serviço de Gestão de Documentos Serviço de Autenticação API de recuperação de extratos Processo de geração de extratos FORA DE ESCOPO Envio por e-mail Extratos com mais de 24 meses Redesenho do PDF Geração de extratos avulsa QUESTÕES EM ABERTO Contas conjuntas estão incluídas? O extrato deve continuar acessível após o encerramento da conta? O período de 24 meses é configurável?
16Passo 16
Seis erros comuns numa primeira User Story
Todos os seis aparecem o tempo todo, e todos os seis são fáceis de pegar antes de ir para produção.
Passo 16
Seis erros comuns numa primeira User Story
Todos os seis aparecem o tempo todo, e todos os seis são fáceis de pegar antes de ir para produção.
Resumo
- Escrever a solução como se fosse o requisito — pare e pergunte o que eles realmente estão tentando alcançar.
- Deixar a story enorme — se ela não pode ser razoavelmente construída, testada e entendida como uma única mudança, divida.
- Escrever a implementação técnica cedo demais — descreva o comportamento de negócio, deixe a conversa de implementação acontecer com quem vai construir.
- Esquecer os cenários de exceção — uma story que só descreve o sucesso ainda não descreveu a funcionalidade.
- Assumir que todo mundo entende sua story — entregue para alguém que não estava na reunião e veja se a interpretação bate com a sua.
- Escrever critérios de aceitação que descrevem uma sensação — "intuitivo" ou "fácil" não é testável; descreva o resultado observável em vez disso.
Por que isso ajuda
A maioria desses erros não é difícil de corrigir. Eles só são fáceis de passar despercebidos nas suas primeiras stories, até que identificá-los vire hábito.
17Passo 17
Monte seu próprio checklist de prontidão
Antes de considerar uma story pronta, confira essa lista.
Passo 17
Monte seu próprio checklist de prontidão
Antes de considerar uma story pronta, confira essa lista.
Checklist
- Eu entendo o problema real, não só a solução pedida
- Eu sei exatamente quem é o usuário
- Eu entendo o resultado que ele precisa
- A story descreve valor, não só uma funcionalidade
- As regras de negócio estão registradas
- Os critérios de aceitação são testáveis, com uma afirmação por critério, e incluem casos negativos
- Caminhos de falha e exceções foram considerados
- As expectativas de dados estão claras
- As dependências estão visíveis
- Os limites de escopo estão explícitos
- As questões em aberto estão visíveis, não só na minha cabeça
- Alguém consegue entender essa story sem mim na sala
Por que isso ajuda
Uma story que passa por essa lista é uma story que qualquer pessoa consegue pegar, construir e testar sem precisar de você na sala.
MEU PRIMEIRO CHECKLIST DE USER STORY [ ] Eu entendo o problema real, não só a solução pedida [ ] Eu sei exatamente quem é o usuário [ ] Eu entendo o resultado que ele precisa [ ] A story descreve valor, não só uma funcionalidade [ ] As regras de negócio estão registradas [ ] Os critérios de aceitação são testáveis, com uma afirmação por critério, e incluem casos negativos [ ] Caminhos de falha e exceções foram considerados [ ] As expectativas de dados estão claras [ ] As dependências estão visíveis [ ] Os limites de escopo estão explícitos [ ] As questões em aberto estão visíveis, não só na minha cabeça [ ] Alguém consegue entender essa story sem mim na sala
A caixa em branco do Jira fica mais fácil quando você para de perguntar "o que eu devo escrever?"
e passa a perguntar "o que eu ainda preciso entender?"
Uma User Story não é algo que você inventa. É algo que você descobre. Escrever "Como... eu quero... para que..." leva vinte segundos. Tudo antes disso é o trabalho de verdade.
Leve isso com você
Modelo inicial de User Story
CONTEXTO O que acontece hoje? Por que essa mudança existe? PROBLEMA DE NEGÓCIO Qual problema estamos resolvendo? USER STORY Como... Eu quero... Para que... REGRAS DE NEGÓCIO 1. 2. 3. CRITÉRIOS DE ACEITAÇÃO Dado... Quando... Então... (inclua pelo menos um caso negativo ou de limite) EXCEÇÕES O que acontece quando o fluxo normal falha? REQUISITOS DE DADOS Qual informação é necessária? DEPENDÊNCIAS Quais sistemas, times ou serviços estão envolvidos? FORA DE ESCOPO O que estamos deliberadamente não fazendo? QUESTÕES EM ABERTO O que ainda precisa de resposta?
Receba novos guias em primeira mão.