Quando falamos de Histórias de Usuário, estamos falando de um meio simples e prático para descrevermos as necessidades das pessoas que utilizam nosso produto / serviço. Em diversos treinamentos as pessoas perguntam qual a melhor forma de escrever uma história. Então, digo que é a forma como seu time e stakeholders entendem. Todavia há algumas boas práticas que eu gostaria de colocar aqui.
Tl;dr;
| Nº | Título | Critério | ❌ Mau Exemplo | ✅ Bom Exemplo |
|---|---|---|---|---|
| 1 | Estrutura recomendada da História de Usuário | Utilizar o formato: Eu, enquanto <personagem> desejo <necessidade> para <propósito>. | Enviar e-mail de alerta de turma lotada. | Eu, enquanto Paula PO, desejo me inscrever no treinamento de Product AI porque preciso aprimorar a minha forma de trabalhar. |
| 2 | Histórias PARA o usuário | A história deve ser escrita da perspectiva do usuário, não de soluções técnicas. | Eu, enquanto Alvin Aluno, desejo acessar a API do meio de pagamento para pagar com meu cartão de crédito. | Eu, enquanto Alvin Aluno, desejo pagar os cursos em que me inscrevi com meu cartão de crédito para que eu possa efetuar a matrícula. |
| 3 | Toda História tem um personagem | Sempre indicar um personagem real (persona), não termos genéricos como “usuário” ou “departamento”. | Criar um relatório detalhado de vendas na região Sul para avaliarmos se precisamos abrir uma nova filial. | Eu, enquanto Sérgio Expansão Segura, desejo avaliar as vendas da região Sul para decidir se abriremos mais filiais naquela região. |
| 4 | Personagem específico | Personagem deve ter nome e características específicas para gerar empatia. | Eu, enquanto usuário, preciso de um relatório de alunos inscritos para saber se preciso abrir outra turma. | Eu, enquanto Valdir Detalhista, desejo verificar se a turma ficará lotada para saber se preciso abrir uma nova turma. |
| 5 | Necessidade não é solução | A necessidade deve ser descrita sem antecipar a solução técnica. | Eu, enquanto Diego Desligado, desejo receber um e-mail informando o início das aulas para que eu não perca o conteúdo da matéria. | Eu, enquanto Diego Desligado, desejo receber um aviso sobre o início das aulas para que eu não perca o conteúdo da matéria. |
| 6 | A história só tem 1 necessidade | A história deve abordar apenas uma necessidade, sem conjunções (“e”, “ou”, “mas”, etc.). | Eu, enquanto Alvin Aluno, desejo me inscrever em um curso E pagar para que eu possa reservar a vaga E efetuar a matrícula. | História 1: Eu, enquanto Alvin Aluno, desejo me inscrever em um curso para que eu possa reservar a vaga. História 2: Eu, enquanto Alvin Aluno, desejo pagar os cursos em que me inscrevi para que eu possa efetuar a matrícula. |
| 7 | Necessidade objetiva | A necessidade deve ser clara, específica e mensurável. | Eu, enquanto Sérgio Seguro, desejo acessar o sistema facilmente para poder utilizar as funcionalidades disponíveis para mim. | Eu, enquanto Sérgio Seguro, desejo acessar o sistema com a minha conta e senha para poder utilizar as funcionalidades disponíveis para mim. |
| 8 | Propósito obrigatório | Toda história deve conter um propósito claro e verificável. | Eu, enquanto Amanda Administrativo preciso das informações das pessoas inscritas nas turmas. | Eu, enquanto Amanda Administrativo preciso das informações de contato das pessoas inscritas nas turmas para comunicar o início das aulas. |
| 9 | Propósito objetivo | O propósito deve ser específico, sem ambiguidades. | Fernanda Financeira precisa das informações de custo das turmas para tomada de decisão. | Eu, enquanto Fernanda Financeiro desejo receber as informações de custo do serviço de catering e locação para escolher a melhor data para pagamento de ambos. |
CCC da História de Usuário
Antes de mais nada gostaria de relembrar alguns atributos importantes que a História de Usuário deve ter. Esses são bem descritos pelo acrônimo CCC.
Cartão: O primeiro C é cartão. Essa ideia veio do Mike Cohn quando criou o conceito. A história deveria ser tão pequena que coubesse em um cartão pautado. A ideia é que textos técnicos muito longos são chatos e dificilmente as pessoas leem.
Conversa: Já que o cartão tem pouco espaço para a escrita, a conversa entre o pessoal de negócio e o pessoal técnico é inevitável. Isso deve ser estimulado.
Confirmação: Uma vez que conversamos sobre porque, como, o quê deve ser feito, agora temos que confirmar que todos estão com a mesma compreensão. Tradicionalmente utilizamos os critérios de aceitação para isso. Nesse texto aqui falamos até sobre como você pode utilizar um Agente de IA para gerar critérios de aceitação.
O INVEST das Histórias de Usuário
Agora que sabemos os atributos básicos, podemos ver o que descreveria uma boa história de usuário. Muitos gostam de um outro acrônimo chamado INVEST.
I – Independente: A história deve ser o mais independente possível das outras.
N – Negociável: Tanto o conteúdo quanto a prioridade da história devem ser negociáveis, pois não há um contrato rígido.
V – Valiosa: Deve entregar valor ao usuário.
E – Estimável: Deve ser possível estimar o esforço necessário para implementá-la.
S – Small (Pequena): Deve ser pequena o suficiente para ser concluída dentro de um ciclo (sprint, por exemplo).
T – Testável: Deve haver uma maneira clara de verificar se a história foi implementada corretamente.
Critérios Objetivos para avaliar uma história de Usuário
O INVEST nos dá características interessantes que a História de Usuário deve ter, porém não servem tão bem para avaliar se uma história está bem escrita, pois são subjetivos. Por exemplo, o que definiria uma história pequena? Para um time inexperiente uma história pode ser um épico enquanto para outro time mais experiente pode ser uma tirinha de jornal.
Precisamos de algo um pouco mais objetivo e que possa ser avaliado. Eu dividi as sugestões em 4 grandes blocos conforme podemos ver a seguir
A estrutura da História de usuário
Imagine um livro ou um filme que você assistiu. A história não foi jogada de qualquer jeito. Há uma estrutura para que ela chegue até você. A mesma coisa com o nosso backlog.
1) A estrutura recomendada da História de Usuário
Você já se deparou com um backlog escrito de qualquer forma:
- Enviar e-mail de alerta de turma lotada
- Como aluno, eu gostaria de acessar meu histórico.
- Para me inscrever na disciplina, eu desejo consultar aquelas em que eu possa me inscrever.
Uma boa história de usuário deve ter a seguinte estrutura: Eu, enquanto <personagem> quero | gostaria | preciso | necessito <necessidade> para | pois | porque <propósito>. Repare que é uma divisão de três pontos que responderem 3 das 5 perguntas fundamentais:
- Personagem: quem?
- Necessidade: o quê?
- Propósito: por quê?
Um exemplo seria: Eu, enquanto Paula PO, desejo me inscrever no treinamento de Product AI porque preciso aprimorar a minha forma de trabalhar.
2) Histórias PARA o usuário
Muito comum quando o Product Owner vem da área técnica. Bem, o nome História de USUÁRIO deve dizer alguma coisa. A história é do usuário e não do time técnico.
❌ Mau exemplo: Eu, enquanto Alvin Aluno, desejo acessar a API do meio de pagamento para pagar com meu cartão de crédito.
❌❌ Pior ainda: Eu, enquanto desenvolvedor, desejo acessar a API do meio de pagamento para permitir que os alunos utilizem o cartão de crédito para pagamento.
Perceba que elas ferem o princípio do negociável. Apenas um cliente com profundo conhecimento técnico conseguiria discutir acesso de API a meio de pagamento e atribuir um valor a isso.
✅ Bom exemplo: Eu, enquanto Alvin Aluno, desejo pagar os cursos em que me inscrevi com meu cartão de crédito para que eu possa efetuar a matrícula.
Muitas das vezes há certa preguiça em “traduzir” um item técnico para a visão do usuário. É muito comum encontrarmos histórias como:
❌ Mau exemplo: Eu, enquanto Bruno Banco de Dados, desejo fazer o tunning das consultas para que a listagem de cursos não fique lenta.
Descrevemos uma solução do ponto de vista técnico quando o problema (lentidão de uma função) é perceptível também pelo usuário.
✅ Bom exemplo: Eu, enquanto Alvin Aluno, desejo escolher rapidamente os cursos disponíveis para que eu faça minha inscrição sem perder muito tempo.
Ressalva para alguns casos de história técnica
Nem sempre conseguimos evitar histórias técnicas no backlog. Quando o time faz uma solução provisória — a famosa gambiarra — surgem as chamadas Dívidas Técnicas. Se não forem resolvidas logo, essas dívidas crescem, impactam outras partes do sistema e, em casos extremos, levam à necessidade de reescrever tudo do zero.
Nesses casos, faz sentido criar histórias técnicas, mesmo que o usuário final não perceba a mudança. Um exemplo seria:
“Eu, enquanto Denis Dev, desejo alterar a solução X para evitar que ela torne o software difícil de manter no futuro.”
Outro motivo comum para histórias técnicas são atualizações de componentes ou bibliotecas, que também precisam ser priorizadas para manter a saúde do sistema. No artigo “Como tratar e priorizar itens técnicos?” escrevi sobre como equilibrar histórias técnicas com histórias de usuário.
O personagem da história de usuário
Toda história deve ter um personagem e ele responde a pergunta sobre quem é o público-alvo que focamos nela.
3) Toda História tem um personagem
Tradicionalmente esse personagem é descrito através da técnica de persona. A ideia é que exista empatia entre o time e os possíveis clientes que utilizarão o produto. No nosso exemplo utilizei a Paula PO. Você consegue imaginar uma mulher que trabalha como product owner de um time. Claro se tudo foi feito direitinho você terá a descrição dessa persona com mais detalhes.
❌ Mau exemplo: Criar um relatório detalhado de vendas na região Sul para avaliarmos se precisamos abrir uma nova filial.
✅ Bom exemplo: Eu, enquanto Sérgio Expansão Segura, desejo avaliar as vendas da região Sul para decidir se abriremos mais filiais naquela região.
4) Personagem específico
Imagine se uma história tem um pedindo chegando herói. Não sabemos nada sobre ele, suas características ou nome são desconhecidos. Você torce por esse herói? Terá empatia com ele?
Muitas das vezes, as pessoas para criar uma história com a estrutura padrão acabam colocando um personagem qualquer na história só para constar. Por exemplo: usuário, cliente, Departamento X, Setor Y, Time Z. Ninguém tem empatia com o Departamento X. Pode ter com uma pessoa que trabalha ali, mas com o “ser” abstrato departamento não. A mesma coisa com o usuário. Quem é esse cara? Usuário de transporte público? Usuário de um software? Um camarada com problemas toxicológicos?
Toda vez que criar um personagem, dê uma personalidade para ele. Isso ajuda a criar empatia e com o tempo ajuda o time a entender o problema que estão enfrentando.
Um caso breve. Uma vez meu time esteve desenvolvendo um software e um dos clientes era muito, muito detalhista (estou sendo educado, na verdade o achávamos chato pra burro). Ele usava um bigodinho fininho e lembrava o ex-jogador de futebol Valdir Bigode que jogou no Vasco. Logo nasceu a persona Valdir. O time entendia que as histórias do Valdir representavam funcionalidades extremamente detalhadas e passo-a-passos. Na menor possibilidade de dúvida, o Valdir não ficaria satisfeito. Inclusive o filme, quando percebia o excesso de dados ou passos, já recordava: “essa é uma história do Valdir”.
❌ Mau exemplo: Eu, enquanto usuário, preciso de um relatório de alunos inscritos para saber se preciso abrir outra turma.
✅ Bom exemplo: Eu, enquanto Valdir Detalhista, desejo verificar se a turma ficará lotada para saber se preciso abrir uma nova turma.
A necessidade
O que queremos fazer? A necessidade deve escrever o que é necessário utilizando o pingo de vista do usuário
5) Necessidade não é solução
Muitas das vezes vemos exemplos de histórias que não trazem a necessidade do cliente e sim a solução técnica para o problema. Isso atrapalha muito porque enquanto uma necessidade pode ser resolvida de diversas formas, a solução técnica coloca o time em uma situação de implantar o que foi pedido. Com isso, não aproveitamos a inteligência coletiva que pode pensar em soluções muito melhores. Vou dar um exemplo:
❌ Mau exemplo: Eu, enquanto Diego Desligado, desejo receber um e-mail informando o início das aulas para que eu não perca o conteúdo da matéria.
A princípio parece interessante, porém percebe que a necessidade real não está no texto. Quando escrevemos: “desejo receber um e-mail informando o início das aulas” demos ao time uma única solução: implementar um sistema de envio de e-mails. Entretanto, essa pode não ser a melhor solução. Alunos da Geração Z, por exemplo, leem pouco e-mail. Os de outras gerações recebem tantos e-mails que o nosso poderia ser só mais um no meio da multidão. Vamos reescrever a história com uma pequena alteração:
✅ Bom exemplo: Eu, enquanto Diego Desligado, desejo receber um aviso sobre o início das aulas para que eu não perca o conteúdo da matéria.
De quantas formas podemos fazer isso agora?
- Telefonema
- Mensagem Direta nas redes sociais
- Broadcast nas redes sociais
- Banner na página principal
Uma história com 1 necessidade pode ter diferentes soluções. Já aquela que tem 1 solução, só terá aquela solução.
6) A história só tem 1 necessidade
Uma história para ser pequena não deve ter conjunções. Então toda vez que tiver um: e, ou, mas, nem, entretanto ou coisa parecida é um indicativo de que essa história deve ser fatiada.
❌ Mau exemplo: Eu, enquanto Alvin Aluno, desejo me inscrever em um curso E pagar para que eu possa reservar a vaga E efetuar a matrícula.
✅ Bom exemplo:
- História 1 → Eu, enquanto Alvin Aluno, desejo me inscrever em um curso para que eu possa reservar a vaga.
- História 2 → Eu, enquanto Alvin Aluno, desejo pagar os cursos em que me inscrevi para que eu possa efetuar a matrícula.
7) Necessidade objetiva
Já vimos que toda história tem 1 necessidade. Entretanto, temos que tomar cuidado para que essa necessidade não seja ambígua. Algo tão abrangente ou tão abstrato que o time e os clientes sejam incapazes de compreender.
❌ Mau exemplo: Eu, enquanto Sérgio Seguro, desejo acessar o sistema facilmente para poder utilizar as funcionalidades disponíveis para mim.
O que é facilmente? Como podemos avaliar ou estimar uma abstração? A história está aberta e cabe diversas interpretações para ela.
✅ Bom exemplo: Eu, enquanto Sérgio Seguro, desejo acessar o sistema com a minha conta e senha para poder utilizar as funcionalidades disponíveis para mim.
O propósito
Nessa categoria avaliamos o que vem (ou deveria vir) após o “para” da história do usuário.
Você verá que muitos dos critérios que utilizamos para avaliar a necessidade também se aplicam ao propósito.
8) Propósito obrigatório
Toda história tem um propósito que descreve por que o personagem precisa dela.
❌ Mau exemplo: Eu, enquanto Amanda Administrativo preciso das informações das pessoas inscritas nas turmas.
Justamente por não haver um propósito claro, eu não sei quais informações ela realmente precisa. Algumas possibilidades
- Avisar sobre o início das aulas: e-mail e telefone
- Avaliar se será necessário abrir mais turmas: quantitativo de alunos inscritos
- Verificar se todos os alunos realizaram pagamento: dados de pagamento
Sem um porque, é muito difícil saber o que faremos.
✅ Bom exemplo: Eu, enquanto Amanda Administrativo preciso das informações de contato das pessoas inscritas nas turmas para comunicar o início das aulas.
9) Propósito objetivo
Semelhante à necessidade, o propósito também deve ser objetivo.
❌ Mau exemplo: Fernanda Financeira precisa das informações de custo das turmas para tomada de decisão.
Que decisão: cancelar uma turma? Avaliar inadimplência? Saber o valor de serviços de catering e locação? São tantos propósitos que cabem em “tomar decisão”. Você pode usar essa expressão como “justificativa” seja para vender uma multinacional ou para tomar o próximo ônibus.
✅ Bom exemplo: Eu, enquanto Fernanda Financeiro desejo receber as informações de custo do serviço de catering e locação para escolher a melhor data para pagamento de ambos.
Usando IA para validar
É claro que você não precisa ficar lembrando de cada ponto que escrevi aqui. Você pode utilizar a IA para te ajudar nessa verificação
- Copie o link deste artigo.
- Cole no prompt da sua IAG favorita (ChatGPT, Copilot, Grok, Gemini…).
- Escreva: Utilize esses critérios para avaliar as histórias de usuário que escreverei em seguida.
- Copie e cole suas histórias de usuário.
Se preferir, crie um agente para você não ter que fazer isso o tempo todo.
Conclusão
Reafirmo: se as suas histórias de usuário não seguirem exatamente todos os pontos que vimos, mas seu time e seus stakeholders compreendem e conseguem trabalhar bem com elas, isso já é um ótimo sinal!
O objetivo destas boas práticas é ajudar a criar histórias mais claras, objetivas e valiosas — não engessar o processo. Pense nos critérios como guias para melhorar continuamente a comunicação e a colaboração, não como regras absolutas.
Quando estruturamos bem as histórias, focando no personagem, na necessidade real e no propósito, conseguimos maximizar o entendimento, estimular soluções criativas e aumentar a chance de sucesso das entregas.
No fim, o mais importante é lembrar: uma boa história de usuário é aquela que gera conversas de qualidade e entrega valor real para quem importa — o usuário.
