User Stories vs Use Cases: Definições, Templates e Como Escolher Entre Elas

Uma equipe de fintech com a qual trabalhei no ano passado gastou três sprints construindo uma funcionalidade de transferência de depósito com um único toque. A user story ficou no board por semanas: Como titular de conta, quero mover dinheiro entre contas rapidamente, para não precisar navegar por menus. Foi estimada, refinada, quebrada em subtarefas e entregue no prazo. Dois dias depois do release, o time de compliance rejeitou o fluxo inteiro. O use case que a equipe nunca escreveu teria trazido o problema à tona no primeiro dia: uma transferência entre contas de tipos de titularidade diferentes dispara um caminho de KYC separado que o design ignorou completamente. A story capturou a intenção do usuário. Não capturou o que o sistema de fato precisava fazer, e a equipe pagou por essa lacuna com um rollback, uma conversa com o regulador e um trimestre de confiança que precisaram reconstruir. A lição ficou no post-mortem em uma frase:

• As definições claras e funcionais de cada formato e os templates canônicos por trás deles

• Exemplos lado a lado para a mesma funcionalidade, mais 14 padrões e armadilhas

• Quando usar stories, use cases, os dois juntos, e como a análise de sessões com IA fundamenta ambos

Uma user story é uma descrição curta e conversacional de uma funcionalidade na perspectiva do usuário usando o formato "Como [papel], quero [ação], para [resultado]." Um use case é um artefato mais longo e estruturado descrevendo os passos que o usuário e o sistema executam para atingir um objetivo, incluindo pré-condições, fluxo principal, fluxos alternativos e pós-condições. Ambos descrevem o que o sistema faz pelo usuário; a diferença está na granularidade, na durabilidade e na intenção. Equipes de produto maduras tratam os dois como complementares, não concorrentes, e as equipes mais fortes fundamentam os dois no comportamento real do usuário capturado por ferramentas como o UXCam e sua camada de análise por IA, a Tara AI, em vez de em opinião.

O que é uma user story?

Uma user story é uma declaração curta de intenção escrita na perspectiva da pessoa que vai usar a funcionalidade. O formato foi popularizado por Mike Cohn em User Stories Applied, refinado dentro da equipe Connextra que deu a ele o template canônico "Como, quero, para", e absorvido pelo Scrum e pelo movimento ágil mais amplo no início dos anos 2000. A intenção do formato era deliberada: a story foi pensada como um placeholder para uma conversa, não uma especificação. A equipe leria o cartão, sentaria junta e resolveria os detalhes verbalmente antes de escrever o código.

Esse detalhe importa porque explica por que uma boa user story é curta. Se você consegue escrever uma story de cinco parágrafos, você escreveu um use case fantasiado de story, e a equipe vai tratar as palavras no cartão como o contrato em vez de ter a conversa que produz um contrato de verdade. Cohn foi explícito sobre isso. O enquadramento dos três Cs dele, Card, Conversation, Confirmation, definia uma story como um cartão que disparava uma conversa e terminava em uma confirmação por meio de critérios de aceitação. O cartão era o menor dos três.

As stories ficam dentro do ritmo de trabalho da equipe ágil. Vivem no backlog, são refinadas durante grooming, são estimadas usando story points ou tamanhos de camiseta, e atravessam o board conforme engenheiros e designers as transformam em comportamento entregue. São quebradas quando ficam grandes demais (um product manager chama isso de épicos) e devolvidas ao backlog quando suposições se revelam erradas. O artefato é pensado para ser barato de escrever e barato de jogar fora.

A razão de as stories terem sobrevivido aos últimos vinte anos de oscilação no processo de produto é que elas se encaixam em como equipes distribuídas de fato se comunicam. Engenheiros não leem especificações de 12 páginas antes de escrever código. Eles escaneiam um cartão, perguntam três coisas para o product manager no Slack, constroem um rascunho, fazem uma demo e iteram. As stories formalizam esse ciclo. Não são a única maneira de planejar trabalho, e como o resto deste artigo vai argumentar, nem sempre são a maneira certa, mas para a maioria das funcionalidades modernas em ciclos ágeis são a ferramenta mais leve que produz bons resultados.

Algumas observações práticas sobre stories que a literatura subestima. Primeiro, stories funcionam melhor quando a equipe tem um product manager forte que internalizou o usuário. O cartão é curto porque o resto do contexto vive na conversa, e a conversa exige uma pessoa que consiga responder perguntas na hora. Segundo, stories são mais fracas quando a equipe é genuinamente distribuída entre fusos sem sobreposição, porque a conversa colapsa em comentários assíncronos que acabam parecendo um use case ruim mesmo. Terceiro, stories são mais fracas quando especificações de compliance, segurança ou contratuais importam, porque a ausência de um fluxo estruturado vira passivo em qualquer auditoria.

O que é um use case?

Um use case é uma descrição estruturada de como um usuário (ou outro ator) interage com um sistema para atingir um objetivo. O formato foi popularizado por Alistair Cockburn em Writing Effective Use Cases e antes por Ivar Jacobson nas eras Objectory e Rational Unified Process. Use cases antecedem user stories em uma década e foram o artefato dominante de requisitos no software corporativo durante os anos 1990. Eles não desapareceram. Se especializaram nos contextos em que sua estrutura justifica seu peso.

Um use case tem partes: um título, um ator primário (e quaisquer atores secundários), um conjunto de pré-condições que precisam ser verdadeiras antes do use case rodar, um fluxo principal descrevendo o caminho feliz, fluxos alternativos descrevendo cada divergência significativa e pós-condições descrevendo o que é verdade depois que o use case se completa. O formato força você a ser explícito sobre o comportamento do sistema em modos de falha, que é a parte de uma funcionalidade que user stories sistematicamente subestimam.

O enquadramento de Cockburn envelheceu bem. Ele argumentava que um use case deveria "caber no verso de um cartão postal" no nível breve e crescer só conforme o detalhe exigisse, o que está mais perto em espírito das user stories do que assume a versão caricata dos use cases. Ele também argumentava que o valor de um use case estava nos fluxos alternativos, não no fluxo principal. O fluxo principal descreve o que você já sabe. Os fluxos alternativos descrevem o que a equipe ainda não pensou direito, e o ato de escrevê-los é o trabalho que o formato faz por você.

Use cases são mais pesados de escrever que stories. Um use case razoável leva uma ou duas horas de um product manager para uma funcionalidade de complexidade moderada, contra dez minutos para a story equivalente. Esse custo é o que faz com que use cases não sejam adequados como artefato padrão para todo item de backlog. É também o que os faz indispensáveis quando o custo de um fluxo alternativo perdido é maior que o custo de escrevê-lo.

As equipes que perderam o hábito de use case durante a transição ágil estão reaprendendo agora sob outros nomes. Especificações de behavior-driven development, RFCs técnicas, documentos de design com diagramas de sequência e o moderno product requirements document reabsorveram pedaços do formato de use case. A forma é a mesma: título, atores, pré-condições, fluxo, alternativos, pós-condições. O que mudou foi o nome e o público.

O formato de user story em detalhe

O template Connextra tem três linhas:

Como [papel] Quero [ação ou funcionalidade] Para [resultado ou valor]

Cada linha está fazendo trabalho real. O papel ancora a story em um usuário específico, não "o usuário" no abstrato. A ação descreve o que o usuário quer fazer, na linguagem dele, não na sua. O resultado descreve o valor que ele está tirando da ação, que é o que a equipe vai usar para decidir se a implementação de fato entrega a story ou se tecnicamente entregou a funcionalidade sem entregar o valor.

Aqui vai um exemplo trabalhado para um app de banco mobile:

Como titular de conta corrente Quero receber uma notificação quando um depósito for processado Para conseguir verificar rapidamente se há fundos disponíveis antes de fazer uma compra

O papel é específico (titular de conta corrente, não "usuário"), a ação é observável (receber uma notificação quando um depósito for processado) e o resultado é uma razão real pela qual o usuário se importa (verificar fundos antes de fazer uma compra). Uma versão mais fraca da mesma story poderia ser "Como usuário, quero notificações push, para ficar informado." Essa story é inconstruível porque não tem nenhuma restrição sobre o que conta como pronto.

Stories se pareiam com critérios de aceitação, que são condições específicas e testáveis que precisam ser verdadeiras para a story ser considerada entregue. Eles ficam assim no exemplo da notificação de depósito:

• A notificação é enviada em até 30 segundos após o depósito ser marcado como liquidado no sistema central de banking

• A notificação inclui o valor, a conta de origem ou originador, e o novo saldo após o depósito

• A notificação respeita as preferências de notificação do usuário, incluindo horários de silêncio

• A notificação funciona em modo offline, enfileirada para entrega ao reconectar

• A notificação é registrada no feed de atividades dentro do app mesmo quando a entrega push falha

• A notificação é suprimida para depósitos abaixo de um limite configurável pelo usuário

Critérios de aceitação são o que converte uma story de uma frase em um contrato contra o qual a equipe de engenharia pode construir. Eles não são a implementação, são o comportamento observável. Uma boa regra prática é que você deveria conseguir entregar os critérios para um engenheiro de QA que nunca viu a funcionalidade e fazê-lo escrever um plano de teste só pela lista.

Os princípios INVEST, atribuídos a Bill Wake, são a heurística canônica para saber se uma story está pronta para entrar em um sprint. INVEST significa Independent, Negotiable, Valuable, Estimable, Small, Testable (Independente, Negociável, Valiosa, Estimável, Pequena, Testável). Uma story deve ser independente de outras stories, para poder ser sequenciada livremente. Negociável, para a conversa moldar a implementação. Valiosa, para o usuário tirar algo dela. Estimável, para a equipe conseguir dimensioná-la. Pequena, para caber em um sprint. Testável, para a equipe conseguir provar que entregou. Stories que falham em duas ou mais dessas geralmente são épicos que precisam ser quebrados ou use cases escondidos dentro de uma forma de story.

Alguns padrões que separam stories que entregam de stories que ficam no board. Escreva o papel especificamente (cliente recorrente com pelo menos uma compra anterior, não "usuário"). Escreva o resultado na linguagem do usuário (para eu não precisar redigitar meu endereço toda vez, não para melhorarmos a experiência do usuário). Pareie com critérios de aceitação que a equipe concorde antes de a estimativa começar. Resista à tentação de especificar a implementação na story; a implementação é trabalho da conversa. E mantenha o cartão curto. Se não cabe em um cartão postal, não pertence a uma story.

O formato de use case em detalhe

Um use case é estruturado. Aqui vai a forma canônica, com cada seção fazendo um trabalho específico:

Título. Uma frase imperativa curta que nomeia o objetivo, escrita na perspectiva do ator. Processar Notificação de Depósito, não Sistema de Notificação de Depósito.

Ator primário. A pessoa ou sistema cujo objetivo o use case satisfaz. A maioria dos use cases tem um ator primário.

Atores secundários. Outros sistemas ou pessoas envolvidos no fluxo. Para uma notificação de depósito, o sistema central de banking e o provedor de push notification são atores secundários.

Pré-condições. O que precisa ser verdade antes do use case poder rodar. O usuário está logado. O usuário tem permissões de notificação concedidas. O depósito foi processado. Pré-condições são o contrato para a entrada no fluxo.

Fluxo principal. A sequência numerada de passos que os atores executam para alcançar o objetivo. Esse é o caminho feliz. Cada passo é uma ação, escrita no presente, descrevendo o que um ator faz ou o que o sistema faz em resposta.

Fluxos alternativos. Ramos numerados ou identificados por letras saindo do fluxo principal descrevendo divergências significativas. Falhas, casos de borda, caminhos secundários. Cada fluxo alternativo especifica de qual passo do fluxo principal ele se ramifica, o que dispara o ramo e o que acontece em seguida.

Pós-condições. O que é verdade depois que o use case se completa. Os fundos estão disponíveis, a notificação está registrada, a trilha de auditoria registra o evento.

Aqui vai um use case trabalhado para a notificação de depósito:

Título: Processar Notificação de Depósito

Ator primário: Titular de conta

Atores secundários: Sistema central de banking, provedor de push notification, serviço de notificação

Pré-condições:

• O titular de conta está logado no app de banco mobile ou tem o app instalado com tokens de push válidos

• O titular de conta tem permissões de notificação concedidas no nível do SO

• Um depósito foi iniciado e está pendente de processamento no sistema central de banking

Fluxo principal:

1. O sistema central de banking processa o depósito e o marca como liquidado

2. O sistema central de banking emite um evento de depósito-concluído para o serviço de notificação

3. O serviço de notificação recebe o evento e consulta as preferências de notificação do usuário

4. O serviço de notificação formata uma mensagem legível pelo usuário incluindo o valor, a origem e o saldo atualizado

5. O serviço de notificação entrega a mensagem ao provedor de push notification

6. O provedor de push notification entrega a mensagem ao dispositivo do usuário

7. O usuário recebe a notificação na tela de bloqueio ou na bandeja de notificações

8. A notificação é registrada no feed de atividades dentro do app para referência posterior

Fluxos alternativos:

A1. O usuário tem notificações desativadas nas preferências do app.

• Ramo a partir do passo 3.

• O serviço de notificação suprime a push notification mas ainda escreve o evento no feed de atividades dentro do app.

• Pós-condição para A1: o usuário consegue ver o depósito no feed de atividades na próxima abertura do app.

A2. O dispositivo do usuário está offline no momento da entrega.

• Ramo a partir do passo 6.

• O provedor de push notification enfileira a mensagem para retry, respeitando o TTL configurado.

• Se o dispositivo reconectar dentro do TTL, a notificação é entregue. Caso contrário, é silenciosamente descartada após o TTL expirar.

A3. O depósito falha em ser processado.

• Ramo a partir do passo 1.

• O sistema central de banking emite um evento de depósito-falhou em vez disso.

• O serviço de notificação usa um template de mensagem diferente explicando a falha e quaisquer próximos passos.

• Pós-condição para A3: o usuário é informado da falha e o feed de atividades reflete o status de falha.

A4. O usuário está em uma janela configurada de horário de silêncio.

• Ramo a partir do passo 5.

• O serviço de notificação retém a mensagem até o fim da janela de silêncio, depois entrega como notificação de baixa prioridade.

A5. O valor do depósito está abaixo do limite de notificação configurado pelo usuário.

• Ramo a partir do passo 3.

• O serviço de notificação suprime a push notification mas ainda escreve o evento no feed de atividades dentro do app.

Pós-condições:

• O usuário foi informado do status do depósito por meio de pelo menos um dentre push notification, feed de atividades dentro do app ou entrega agendada

• O evento está registrado na trilha de auditoria para fins de relatório de compliance

• As preferências de notificação do usuário e a lógica de limite do depósito foram respeitadas

Repare no que o formato de use case forçou para fora. Horário de silêncio. Depósitos abaixo do limite. Janelas de retry offline. Depósitos falhos com seu próprio template. Nenhum desses teria emergido de "Como titular de conta, quero uma notificação, para saber que meu dinheiro chegou." A story é verdadeira, útil e entregável, mas não é suficiente sozinha quando o custo de errar qualquer um desses fluxos alternativos é uma ligação de regulador ou um evento de confiança do cliente.

Exemplo lado a lado para a mesma funcionalidade

A mesma funcionalidade, expressa nos dois formatos, torna a diferença concreta. Aqui vai uma funcionalidade de app de pagamentos: notificar um cliente quando uma transferência peer-to-peer que ele enviou foi recebida pelo destinatário.

Versão user story.

Como cliente que enviou uma transferência peer-to-peer, quero ser notificado quando o destinatário receber os fundos, para saber que a transferência foi concluída com sucesso.

Critérios de aceitação:

• A notificação dispara em até 60 segundos depois de a conta do destinatário mostrar o crédito

• A notificação inclui o nome do destinatário, o valor e o ID da transferência

• A notificação respeita as preferências de notificação do usuário e horários de silêncio

• A notificação é registrada no feed de atividades

• Transferências falhas disparam um template de notificação diferente

Versão use case.

Título: Notificar Remetente sobre Recebimento de Transferência P2P Ator primário: Cliente remetente Atores secundários: Destinatário, serviço de processamento de pagamentos, serviço de notificação, serviço de detecção de fraude

Pré-condições:

• O cliente remetente iniciou uma transferência P2P que passou pela validação inicial

• O cliente remetente tem permissões de notificação concedidas

• O destinatário é um usuário registrado da plataforma ou tem uma conta bancária externa vinculada

Fluxo principal:

1. O serviço de processamento de pagamentos confirma que a transferência foi liquidada na conta do destinatário

2. O serviço de detecção de fraude liberou a transferência (sem holds pendentes)

3. O serviço de notificação recebe o evento de liquidação

4. O serviço de notificação formata uma mensagem incluindo o nome do destinatário, o valor e o ID da transferência

5. O serviço de notificação entrega a mensagem ao dispositivo do remetente

6. O remetente recebe a notificação

7. O status da transferência no feed de atividades é atualizado para "recebida"

Fluxos alternativos: A1. O serviço de detecção de fraude coloca um hold na transferência.

• Ramo a partir do passo 2. Nenhuma notificação é enviada. O feed de atividades mostra a transferência como "em revisão" e o remetente é notificado por um fluxo diferente.

A2. O destinatário está sem banco ou a conta externa rejeita o crédito.

• Ramo a partir do passo 1. A transferência é revertida. O template de notificação informa o remetente da reversão e de qualquer ação que ele precise tomar.

A3. O destinatário leva mais de 30 minutos para se registrar ou reivindicar a transferência.

• Ramo a partir do passo 1. Um lembrete é enviado ao destinatário em 30 minutos e em 24 horas, com o remetente notificado na marca de 24 horas.

A4. O remetente silenciou notificações deste destinatário específico.

• Ramo a partir do passo 4. A push notification é suprimida mas o feed de atividades ainda é atualizado.

Pós-condições:

• O remetente sabe o status da transferência por um dentre: push notification, atualização do feed de atividades ou fluxo de follow-up

• O estado da transferência no log de auditoria reflete o resultado final

• Qualquer processo de fraude, reversão ou escheatment foi disparado se aplicável

Os dois artefatos descrevem a mesma funcionalidade. A story é suficiente para uma equipe co-localizada em um ciclo apertado começar a construir. O use case é suficiente para uma equipe distribuída, um contexto regulado ou uma funcionalidade que toca em sistemas adjacentes suficientes para que os fluxos alternativos seriam descobertos em produção. A maioria das equipes com as quais trabalho acaba escrevendo a story primeiro para alinhar sobre valor para o usuário, depois escrevendo o use case durante o refinamento para trazer à tona os fluxos que a story perdeu.

Quando usar uma user story

User stories funcionam bem quando a conversa é barata e o custo de perder um detalhe é baixo. Especificamente:

Você está operando em um ciclo ágil apertado com conversas presenciais ou síncronas frequentes. A equipe é co-localizada ou perto disso, com um product manager forte que consegue responder perguntas dentro do horário de trabalho. A funcionalidade é pequena o suficiente para que a equipe segure todo o escopo na cabeça de uma vez. Você ainda está validando se a funcionalidade vale a pena ser construída, e escrever um use case completo para algo que talvez você corte semana que vem é trabalho desperdiçado. O risco de errar um fluxo alternativo é limitado, um caso de borda perdido vira um ticket de fast-follow, não um evento regulatório.

User stories são o formato dominante em equipes de produto modernas porque a maioria das funcionalidades modernas se encaixa nessas restrições. Um app de consumo entregando uma nova opção de ordenação, uma ferramenta SaaS adicionando um atalho de teclado, um site adicionando um novo filtro a uma lista, todos são problemas em formato de story. Escrever um use case para eles seria cerimônia pela cerimônia.

A outra razão pela qual stories dominam é que elas combinam com a cadência ágil. Um sprint de duas semanas com vinte stories é vinte conversas que a equipe consegue ter em uma semana de grooming. Vinte use cases é um livrinho que ninguém lê. Stories sobrevivem porque trocam especificação por conversa, e a conversa é o que produz software bom.

Um teste útil: se você consegue descrever a funcionalidade em uma frase e um engenheiro sênior consegue construir um rascunho dela sem fazer mais de três perguntas, a funcionalidade tem formato de story. Se a primeira resposta do engenheiro é "o que acontece quando X" e a resposta para X gera mais três perguntas, a funcionalidade tem um use case escondido lá dentro.

Quando usar um use case

Use cases ganham seu lugar quando a conversa é cara ou o custo de errar é alto. A funcionalidade tem muitos fluxos alternativos ou casos de borda, cinco ou mais divergências significativas do caminho feliz. Múltiplos atores interagem, incluindo serviços de terceiros, sistemas externos ou outras equipes cujo comportamento a equipe que está construindo a funcionalidade não controla. Documentação regulatória ou de compliance é exigida, e a equipe precisa de um artefato que vai sobreviver a uma auditoria. A equipe está distribuída entre fusos com sobreposição limitada, e a conversa degrada em comentários assíncronos que precisam de uma âncora estruturada.

Use cases são comuns em indústrias reguladas, fintech, saúde, seguros, governo, e em software corporativo complexo onde cláusulas contratuais dependem de comportamento do sistema que a equipe de procurement do comprador vai dissecar. Também são comuns em qualquer funcionalidade que toca em identidade, pagamentos ou privacidade de dados, porque os fluxos alternativos são onde o regulador vive.

A decisão não é religiosa. Escolha um use case quando a escrita dele traz à tona informação que a equipe perderia de outra forma. Se você se pega escrevendo um use case onde os fluxos alternativos são trivialmente óbvios e o fluxo principal tem quatro passos, está fazendo cerimônia. Se você se pega escrevendo uma story onde a equipe gastou três sprints descobrindo casos de borda que a story não nomeou, está usando o formato errado.

Um segundo teste: se um regulador, advogado ou compliance officer pode ler este artefato, escreva um use case. Se só a equipe vai ler, uma story provavelmente é suficiente.

Quando usar os dois juntos

O padrão mais maduro que vi é usar os dois, em sequência. A story dirige a conversa sobre valor para o usuário durante a descoberta do produto. O use case captura o resultado da conversa durante o refinamento, trazendo à tona os fluxos alternativos que a story não nomeou. Engenharia constrói contra o use case. QA testa contra os critérios de aceitação anexados à story. Equipes de compliance e auditoria referenciam o use case. A story fica leve o suficiente para refletir entendimento mutável do usuário; o use case fica detalhado o suficiente para sobreviver a uma auditoria.

O pareamento é especialmente comum em:

Fintech e saúde, onde a documentação de compliance é inegociável e os fluxos alternativos são onde o custo de errar se concentra.

SaaS corporativo com ciclos longos de venda, onde compradores pedem especificações antes de assinar e a equipe de procurement trata use cases como parte do contrato.

Apps mobile e web com casos de borda específicos por plataforma, divergência iOS versus Android, comportamento específico de navegador, tratamento offline, peculiaridades de push notification. O use case é onde essas divergências são nomeadas.

Qualquer funcionalidade onde a equipe já se queimou perdendo um fluxo alternativo. Depois que uma equipe faz um post-mortem de um fluxo perdido, ela tende a adotar o padrão de pareamento para funcionalidades similares dali pra frente.

O custo do pareamento é real. Escrever os dois leva mais tempo que escrever um. O benefício é que os artefatos fazem trabalhos diferentes: a story alinha a equipe em valor, o use case alinha a equipe em comportamento, e os dois juntos produzem funcionalidades que entregam de forma limpa na primeira vez.

14 padrões e armadilhas ao escrever stories ou use cases

Esses são os padrões que vejo repetidamente em equipes de produto, os que separam equipes que entregam de equipes que discutem sobre formato.

1. Stories que não são realmente focadas no usuário. "Como desenvolvedor, quero refatorar o módulo de auth" é um ticket de tech debt, não uma user story. Trate diferente e coloque em um backlog de engenharia separado. Misturar dilui os dois.

2. Stories sem critérios de aceitação. Sem critérios testáveis, "pronto" vira o que quer que o engenheiro tenha achado que a story significava. Pareie cada story com três a sete critérios que a equipe concorde antes da estimativa.

3. Use cases que se leem como stories. Se seu use case é um parágrafo e três passos, é uma story em traje formal. Use o formato de story e pare de gerar cerimônia.

4. Stories que deveriam ter sido use cases. Se a equipe fica descobrindo casos de borda na implementação que ninguém nomeou no grooming, o formato de story é fino demais. Promova a próxima funcionalidade similar a um use case.

5. O papel escrito genericamente. "Como usuário" não diz nada. "Como cliente recorrente com pelo menos uma compra anterior" diz quem é e restringe o design.

6. O resultado escrito para a empresa, não para o usuário. "Para melhorarmos o engajamento" é a razão de um product manager. "Para eu não precisar redigitar meu endereço toda vez" é a razão do usuário. Escreva a razão do usuário.

7. Implementação especificada dentro da story. "Como usuário, quero um botão no canto superior direito que abre um modal com três campos" não deixa nada para a conversa. Descreva o objetivo, não o design.

8. Use cases sem fluxos alternativos. O fluxo principal é a parte que você já sabe. Os fluxos alternativos são onde o formato justifica seu peso. Um use case sem fluxos alternativos é um diagrama de sequência disfarçado.

9. Pré-condições que escondem as suposições reais. "Usuário está logado" não é suficiente. "Usuário está logado E tem KYC concluído E tem pelo menos uma fonte de financiamento vinculada" é o que o sistema de fato exige. Escreva o conjunto completo.

10. Critérios de aceitação escritos por uma pessoa só. Critérios escritos pelo PM sozinho tendem a capturar o modelo mental do PM. Tenha o engenheiro e o lead de QA revisando antes do início do sprint, e veja com que frequência eles pegam condições faltando.

11. Tratar stories vs use cases como debate religioso. Escolha o formato que combina com a complexidade da funcionalidade e a maturidade da equipe. Os dois formatos são ferramentas. Ferramentas não são identidades.

12. Pular a fonte da story ou do use case. As stories e use cases mais fortes são escritos a partir de comportamento observado do usuário, não a partir de especulação. Se você não consegue apontar para o dado, o ticket de suporte ou a session replay que motivou a story, está adivinhando.

13. Esquecer de atualizar o artefato quando a funcionalidade muda. Uma story escrita seis meses atrás e iterada três vezes em produção não é a story entregue. Atualize o artefato ou mate; não deixe ficar como documentação que mente.

14. Escrever o use case depois que a funcionalidade é entregue. O use case é mais valioso antes da implementação, quando sua estrutura força você a pensar nos fluxos alternativos. Escrever depois como documentação para compliance está ok, mas você perdeu o valor de design do formato.

As equipes que lidam bem com esses padrões compartilham um hábito: tratam o artefato como um meio para um fim, não um fim. A story é um jeito de alinhar em valor. O use case é um jeito de trazer fluxos à tona. Os critérios são um jeito de definir pronto. Nenhum deles é produto de trabalho em si mesmo; a funcionalidade entregue é.

Orientação específica por indústria

Indústrias diferentes empurram formatos diferentes por razões geralmente fundamentadas em regulação, complexidade ou distribuição.

Fintech e pagamentos. Use cases são obrigatórios para qualquer fluxo que toca em movimentação de dinheiro, KYC ou triagem de sanções. Reguladores leem os use cases durante auditorias, e os fluxos alternativos são onde o compliance vive. User stories são apropriadas para superfícies não reguladas, telas de configurações, páginas de marketing, ferramentas internas de admin. O padrão de pareamento domina: story para valor do usuário, use case para detalhe do fluxo. Fundamentar os dois em comportamento real do usuário é direto quando você está rodando session replay no app autenticado, porque a Tara AI dentro do UXCam consegue mostrar os momentos específicos em que clientes têm dificuldade com o fluxo existente antes de você escrever a story para o novo. A equipe de customer experience da Recora usou exatamente esse padrão para identificar um gesto de pressionar-e-segurar que clientes não conseguiam descobrir, depois escreveu o redesign como um pareamento story-mais-use-case que cortou tickets de suporte em 142% (veja o estudo de caso da Recora).

Saúde e telessaúde. Compliance com HIPAA exige documentação de qualquer fluxo que toca em informação de saúde protegida, o que significa use cases para superfícies clínicas, fluxos de prescrição e qualquer funcionalidade lidando com identificadores de paciente. Stories funcionam para o site de marketing, a página pública de agendamento e outras superfícies que não tocam PHI. O custo de um fluxo alternativo perdido em saúde é dano ao paciente, o que eleva a régua para o rigor de use case comparado a apps de consumo.

SaaS B2B. O formato de story combina com os ciclos rápidos de iteração que equipes de SaaS B2B rodam. Use cases entram para funcionalidades de integração (onde APIs de terceiros adicionam fluxos alternativos), para funcionalidades de tier corporativo que entregam sob contrato e para fluxos relevantes de segurança como SSO e logging de auditoria. O padrão de pareamento é comum para funcionalidades de tier pago, onde procurement pede especificações e o use case vira parte da venda.

E-commerce e varejo. Stories dominam porque o ciclo é rápido e a maioria das funcionalidades tem formato de story. Use cases ganham seu lugar no fluxo de checkout, onde fluxos alternativos em torno de falhas de pagamento, holds de fraude e opções de envio se multiplicam rapidamente. A otimização de signup da Costa Coffee é um exemplo útil: a equipe rodou a versão de story para o redesign, depois identificou fluxos alternativos específicos a partir do session replay (usuários abandonando na entrada do OTP, usuários abandonando quando regras de senha apareciam tarde), e o trabalho que elevou os registros em 15% refletiu os dois formatos.

Gaming e consumo. Stories funcionam bem para a maior parte do trabalho de funcionalidade porque o ciclo é rápido, a equipe é co-localizada e o custo de um caso de borda perdido é limitado. Use cases entram para fluxos de monetização (compras dentro do app, assinaturas) e para qualquer funcionalidade que toca em estado de conta entre dispositivos. A Inspire Fitness é um bom exemplo de como trabalho dirigido por story pode produzir grandes resultados quando fundamentado em comportamento real do usuário, a reformulação de onboarding deles, escrita como uma série de stories fundamentadas em fricção observada, elevou o tempo no app em 460%.

Viagens, hospitalidade e reservas. Use cases são essenciais para qualquer fluxo de reserva porque os fluxos alternativos se multiplicam rapidamente: políticas de cancelamento, disponibilidade parcial, reservas multi-trecho, divisões de pagamento, conversões de moeda, reservas em grupo. Stories funcionam para tudo fora do fluxo de reserva em si. O padrão de pareamento é a norma.

A lição geral entre indústrias é que o formato segue o custo de errar. Onde um fluxo alternativo perdido vira um evento regulatório, um evento de confiança do cliente ou uma quebra contratual, use cases ganham seu peso. Onde o custo é um ticket de fast-follow e um usuário levemente irritado, stories são suficientes.

Templates prontos para copiar

Esses são os templates canônicos em markdown puro. Coloque na ferramenta de sua escolha (descrição do Jira, ticket do Linear, doc do Notion, página do Confluence) e adapte os placeholders.

Template de user story:

Título: [frase imperativa curta]

Como [papel específico com atributos relevantes] Quero [ação ou funcionalidade observável] Para [resultado que o usuário de fato valoriza]

Critérios de aceitação:

• [Condição específica e testável #1]

• [Condição específica e testável #2]

• [Condição específica e testável #3]

• [Condição específica e testável #4]

• [Condição específica e testável #5]

Notas / questões em aberto:

• [Qualquer coisa ainda sendo esclarecida antes do início do sprint]

Fonte / evidência:

• [Link para a session replay, ticket de suporte, gráfico de analytics ou achado de pesquisa que motivou esta story]

Template de use case:

Título: [frase imperativa nomeando o objetivo]

Ator primário: [o ator cujo objetivo isso satisfaz]

Atores secundários: [quaisquer outras pessoas, sistemas ou serviços envolvidos]

Pré-condições:

• [O que precisa ser verdade antes deste use case poder rodar]

• [Especificamente o estado do usuário e do sistema]

Fluxo principal:

1. [Passo um, ação do ator ou do sistema]

2. [Passo dois]

3. [Passo três]

4. [Continue passos numerados até o objetivo]

Fluxos alternativos:

A1. [Condição de gatilho para o primeiro fluxo alternativo]

• Ramo a partir do passo [N].

• [O que acontece]

• Pós-condição: [O que é verdade depois deste fluxo alternativo]

A2. [Gatilho para o segundo fluxo alternativo]

• Ramo a partir do passo [N].

• [O que acontece]

• Pós-condição: [O que é verdade depois deste fluxo alternativo]

A3. [Gatilho para o terceiro fluxo alternativo]

• [Continue para cada divergência significativa]

Pós-condições:

• [O que é verdade depois que o use case se completa]

• [Incluindo o estado de auditoria, logging ou compliance]

Template de critérios de aceitação (variante Given-When-Then):

Given [o estado inicial do usuário e do sistema] When [o usuário toma uma ação específica] Then [o resultado observável que deve ocorrer]

Use o formato Given-When-Then quando os critérios precisam ser testáveis por automação, particularmente para workflows de behavior-driven development. Use o formato mais simples de lista com bullets quando os critérios serão verificados manualmente durante o QA. Os dois funcionam; a escolha depende da sua postura de testes.

Template de pareamento story mais use case (para o padrão combinado):

Story (topo do ticket): Como [papel], quero [ação], para [resultado].

Critérios de aceitação: 3-7 condições testáveis.

Use case vinculado (página separada, linkada do ticket): use case estruturado completo como acima.

Fonte: link para a session replay, tendência de tickets ou achado de analytics que motivou o trabalho.

O template de pareamento é o que recomendo para qualquer funcionalidade onde um fluxo alternativo perdido tem consequências maiores que um usuário irritado. A story mantém a equipe alinhada em valor, o use case mantém a equipe alinhada em comportamento, e o link entre os dois mantém ambos honestos.

Onde a análise de sessões com IA informa os dois

O formato que você escolhe vem depois da pergunta de onde os inputs vêm. Uma user story escrita a partir de especulação é pior que nenhuma user story, porque codifica os vieses da equipe como trabalho a ser entregue. Um use case escrito a partir do modelo mental de um product manager é igualmente frágil. Os dois formatos são bons apenas na medida do entendimento do usuário por trás deles, e a maioria das equipes subestima quanto desse entendimento vem da observação em vez da intuição.

É aqui que a análise de sessões com IA muda a prática. A Tara AI dentro do UXCam lê session replays em escala, agrupa padrões de fricção por impacto no negócio e traz à tona os momentos específicos pelos quais vale a pena escrever stories. Em vez de um product manager adivinhar com o que os usuários têm dificuldade, a camada de analyst entrega a ele uma lista priorizada: este passo do onboarding está produzindo rage taps, este erro de checkout está matando conversão, este padrão de navegação está perdendo usuários recorrentes.

Isso muda o input para a escrita de stories. O papel em "Como [papel]" fica específico porque o dado te diz qual segmento é afetado. A ação fica observável porque você assistiu usuários tentando. O resultado fica real porque você viu o momento em que os usuários desistiram. Os critérios de aceitação ficam testáveis porque você sabe como a falha existente parece e consegue especificar a correção em termos observáveis.

A mesma dinâmica se aplica a use cases. Os fluxos alternativos que você escreve são bons na medida dos modos de falha que você viu. Um use case escrito a partir da imaginação perde os fluxos alternativos que aparecem em produção. Um use case escrito a partir de dados de sessão observados, os momentos específicos em que usuários encontram uma notificação de horário de silêncio, um retry offline, um depósito abaixo do limite, um hold de fraude, captura os fluxos alternativos que de fato acontecem.

Um workflow prático parece com isto. A Tara AI traz à tona um cluster de fricção: 12% dos usuários no fluxo de notificação de depósito experimentam uma supressão por estar abaixo do limite que não esperavam. O product manager escreve uma user story para a correção, fundamentada nos momentos específicos que a IA sinalizou. Durante o refinamento, a equipe escreve um use case que nomeia o fluxo alternativo explicitamente. Engenharia constrói contra o use case. QA testa contra os critérios de aceitação. A correção entrega e o cluster de fricção encolhe. Ninguém adivinhou o input, e o produto de trabalho reflete a realidade observada em vez do modelo mental anterior da equipe.

Esse é o fio condutor que atravessa os resultados mais fortes de clientes do UXCam. A Recora cortou tickets de suporte em 142% porque escreveu a story de redesign a partir de um padrão específico de fricção que a session replay trouxe à tona. A Inspire Fitness elevou o tempo no app em 460% porque as stories de onboarding foram fundamentadas nos rage taps que a equipe observou, não em especulação. A Housing.com dobrou a adoção de funcionalidades de 20% para 40% porque os use cases para a reformulação da navegação foram escritos a partir de dados de sessão em vez do modelo mental da equipe de design. A Costa Coffee elevou os registros em 15% porque a equipe pareou valor do usuário no nível de story com detalhe de fluxo alternativo no nível de use case, ambos fundamentados em fricção observada de signup.

A lição é simples. O formato que você escolhe (story, use case, os dois) é uma decisão menos consequente que o input do qual você parte. Equipes que fundamentam os dois em comportamento real do usuário entregam mais que equipes que discutem qual formato é correto, todas as vezes.

Ferramentas para gerenciar stories e use cases

A prática de escrever e gerenciar stories e use cases é apoiada por uma stack de ferramentas, cada uma com sua opinião sobre o trabalho. A escolha certa depende do tamanho da sua equipe, da sua toolchain existente e se você primariamente vive em stories, use cases ou ambos.

Atlassian Jira (atlassian.com) é o tracker dominante de stories e tickets em software corporativo. L