User Stories vs. Use Cases vs. Job Stories (Exemplos)

User stories, use cases, job stories e declarações de requisitos são quatro formas de descrever o que o software deve fazer. Eles são frequentemente apresentados como rivais, mas respondem a diferentes perguntas em diferentes níveis de detalhe. Uma user story pergunta quem quer o quê e por quê. Um use case percorre uma interação passo a passo, incluindo o que pode dar errado. Uma job story parte da situação em que o usuário está. Um requisito declara uma regra que o sistema deve obedecer.

Este guia compara os quatro, mostra o mesmo recurso escrito de cada forma e explica quando usar qual. Para os fundamentos de escrita de histórias, veja nosso guia central sobre como escrever user stories.

Comparação rápida

Histórias de usuário

Uma história de usuário é uma descrição curta de uma capacidade, contada do ponto de vista da pessoa que a deseja. O formato usual, “Como [tipo de usuário], eu quero [ação], para que [benefício]”, surgiu da equipe Connextra em 2001 e se espalhou pelo livro User Stories Applied de Mike Cohn. As histórias cresceram na Programação Extrema, onde eram deliberadamente breves: Ron Jeffries descreveu cada história como um cartão, uma conversa e uma confirmação (os 3 Cs). O cartão não é a especificação; a conversa é onde os detalhes são acordados, e os critérios de aceitação os confirmam.

Pontos fortes: as histórias são pequenas o suficiente para serem estimadas e concluídas em um sprint, fáceis para partes interessadas não técnicas lerem, e mantêm o valor (“para que”) em vista. Mike Cohn expõe o caso a favor delas em Vantagens das histórias de usuário para requisitos.

Limites: um backlog de histórias individuais não mostra como elas se encaixam em um fluxo, e o formato facilita pular casos de erro. As equipes corrigem o primeiro com um mapa de histórias de usuário e o segundo com critérios de aceitação bem escritos (veja nosso modelo de história de usuário).

Casos de uso

Um caso de uso descreve como um ator (uma pessoa ou outro sistema) usa o sistema para alcançar um objetivo, como uma sequência de passos, junto com as formas como essa sequência pode ramificar ou falhar. Ivar Jacobson introduziu casos de uso no final dos anos 1980, e o livro Writing Effective Use Cases (2000) de Alistair Cockburn estabeleceu o estilo focado em objetivos e em texto simples que a maioria das equipes usa hoje (site de Cockburn).

Um caso de uso completo geralmente inclui:

• Ator principal: quem inicia a interação.
• Objetivo e escopo: o que o ator deseja e qual sistema está sendo descrito.
• Pré-condições: o que já deve ser verdadeiro.
• Gatilho: o que inicia o caso de uso.
• Cenário de sucesso principal: os passos numerados quando tudo dá certo.
• Extensões: caminhos alternativos e de falha, cada um ligado ao passo onde ramificam.
• Pós-condições ou garantias: o que é verdadeiro no final, em caso de sucesso e de falha.

Pontos fortes: a seção de extensões força você a pensar no que pode dar errado, e o fluxo completo é visível em um só lugar, o que é valioso para integrações, pagamentos e qualquer coisa auditada. Limites: casos de uso levam mais tempo para escrever e manter atualizados, e um caso de uso geralmente é grande demais para ser construído em um único sprint.

Casos de uso se adaptaram ao trabalho ágil. Em Use-Case 2.0, Jacobson e colegas dividiram cada caso de uso em “fatias”, cada uma pequena o suficiente para planejar e testar, que desempenham um papel muito semelhante ao das histórias de usuário.

Histórias de tarefa (jobs to be done)

Uma história de tarefa substitui a persona pela situação: “Quando [situação], eu quero [motivação], para que [resultado esperado].” A ideia foi mencionada pela primeira vez por Paul Adams no blog da Intercom e desenvolvida por Alan Klement, que a explicou em um post convidado de 2013 na Intercom, Usando histórias de tarefa para projetar recursos. Ela aplica o pensamento jobs-to-be-done, associado a Clayton Christensen, ao design de recursos.

O argumento a favor das histórias de tarefa é que “Como um pai ocupado” carrega pressupostos que a equipe não pode testar, enquanto a situação (“Quando estou prestes a sair de casa e percebo que esqueci de pedir compras”) explica a urgência, as restrições e como “concluído” se sente para o usuário. Duas personas muito diferentes na mesma situação muitas vezes precisam da mesma coisa.

Pontos fortes: as histórias de tarefa são boas em descoberta e design, mantêm a equipe focada no contexto e produzem melhores perguntas para entrevistas com clientes. Limites: elas dizem pouco sobre quem tem permissão para fazer o quê, o que importa para permissões e papéis, e a maioria das equipes ainda as transforma em histórias de usuário ou tarefas para planejamento.

Declarações de requisitos

O formato tradicional é uma declaração numerada: “O sistema deve bloquear uma conta após cinco tentativas de login falhas.” As especificações de requisitos ainda são a norma em indústrias reguladas, licitações governamentais e contratos de preço fixo, e o padrão internacional atual para escrevê-los é a ISO/IEC/IEEE 29148.

Equipes ágeis também usam declarações de requisitos, principalmente para requisitos não funcionais (desempenho, segurança, disponibilidade, acessibilidade) que se aplicam a muitas histórias. Esses requisitos geralmente são registrados uma vez, na definição de pronto ou em uma página curta de atributos de qualidade, em vez de serem repetidos em cada história.

O mesmo recurso escrito de três formas

Recurso: em um aplicativo de despesas compartilhadas para colegas de apartamento, uma pessoa paga por algo e divide o custo com os outros.

Como uma história de usuário

Como um colega de apartamento que pagou por uma compra compartilhada, quero dividir o custo com as pessoas para quem foi, para que o saldo de todos mostre o que me devem.

• Posso escolher quais membros do grupo compartilham o custo; estou incluído por padrão.
• A divisão padrão é igual; posso alternar para valores exatos ou porcentagens.
• O aplicativo não salvará uma divisão cujas partes não somem o total, e indicará em quanto está incorreto.
• O saldo de cada pessoa é atualizado assim que a despesa é salva, e eles recebem uma notificação.

Como um caso de uso

Caso de uso: Dividir uma despesa. Atores principais: Pagador. Pré-condição: o pagador está autenticado e pertence a um grupo com pelo menos outro membro. Gatilho: o pagador escolhe “Adicionar despesa”.

1. O pagador insere o valor, uma descrição e a data.
2. O sistema exibe os membros do grupo, com o pagador selecionado.
3. O pagador seleciona os membros que compartilham o custo.
4. O sistema propõe uma divisão igual e mostra cada parte.
5. O pagador confirma.
6. O sistema salva a despesa, atualiza todos os saldos e notifica os membros selecionados.

• 4a. O pagador alterna para valores exatos ou porcentagens: o sistema recalcula conforme cada valor é digitado.
• 5a. As partes não somam o total: o sistema bloqueia a salvagem e mostra a diferença.
• 6a. O dispositivo está offline: o sistema salva a despesa localmente, marca-a como pendente e sincroniza quando voltar a ter conexão.
• Pós-condição em caso de sucesso: a despesa é registrada uma vez, e todos os saldos refletem isso. Em caso de falha: nenhum saldo é alterado.

Como uma história de tarefa

Quando acabei de pagar algo no caixa que é parcialmente para meus colegas de apartamento, quero registrá-lo antes de esquecer o valor, para que eu possa ser reembolsado sem precisar cobrar ninguém.

Como declarações de requisitos

• REQ-1: O sistema deve permitir que um membro do grupo registre uma despesa com valor, descrição, data e pagador.
• REQ-2: O sistema deve permitir que o pagador divida uma despesa igualmente, por valores exatos ou por porcentagem.
• REQ-3: O sistema deve rejeitar uma divisão cujas partes não sejam iguais ao total.
• REQ-4: O sistema deve atualizar todos os saldos afetados em até dois segundos após a salvagem.

Observe o que cada versão revelou. A história de usuário é a mais fácil de estimar e planejar. O caso de uso é o único que levantou o cenário offline e declarou o que deve ser verdade se a salvagem falhar. A história de tarefa revelou a restrição real, que é a velocidade no caixa; ela sugere que a primeira tela deve pedir apenas o valor e nada mais, algo que nenhuma das outras versões teria sugerido. Os requisitos adicionaram uma meta de desempenho mensurável que a história deixou implícita.

Qual delas você deve usar?

É possível combiná-los?

Sim, e a maioria das equipes maduras faz isso. Uma sequência viável é a seguinte:

1. Use histórias de tarefa durante a pesquisa, para capturar situações e motivações de usuários reais.
2. Organize as capacidades resultantes em um mapa de histórias como histórias de usuário, e escolha a fatia do primeiro lançamento.
3. Para os um ou dois fluxos em que o erro é caro (pagamentos, cadastro, sincronização de dados), escreva um caso de uso leve para encontrar as extensões, e depois transforme cada extensão em sua própria história ou critério de aceite.
4. Registre os requisitos transversais (desempenho, segurança, acessibilidade, conformidade) uma vez, como declarações numeradas ou na definição de pronto.

A regra geral: escreva apenas o que a equipe precisa para construir a coisa certa com segurança. Uma equipe de MVP de três pessoas não precisa de um documento de requisitos, e uma integração bancária não deve se basear em uma única frase.

Erros comuns

• Escrever casos de uso como scripts de interface de usuário (“o usuário clica no botão azul”), o que vincula o requisito a um design que mudará.
• Escrever histórias de usuário sem o “para que”, o que impede a equipe de sugerir uma solução mais simples.
• Tratar uma história de tarefa como uma persona disfarçada (“Quando eu sou uma mãe ocupada...”); a situação deve ser um momento, não uma identidade.
• Copiar uma longa lista de requisitos para o backlog como uma história por linha, o que gera histórias sem usuário e sem valor.
• Usar formatos diferentes no mesmo backlog sem um acordo sobre qual é a fonte da verdade.

Perguntas frequentes

Não tem certeza de quanto de especificação seu produto precisa? Ajudamos fundadores a transformar ideias em um backlog com escopo definido e, em seguida, a construí-lo em sprints curtos. Veja nossos planos de desenvolvimento mensais.