Épico, história de usuário e tarefa: diferenças com exemplos
O épico no Scrum é a forma mais comum de organizar um Product Backlog que cresceu demais: em vez de 300 itens soltos, o time agrupa as necessidades grandes em épicos, divide cada um em histórias de usuário e, na Sprint, transforma as histórias em tarefas. O problema é que muita gente usa os três nomes como sinônimos, e o backlog vira uma mistura de "melhorar o financeiro", "criar tabela de clientes" e "o vendedor quer emitir pedido pelo celular", tudo no mesmo nível.
Cada um desses itens responde a uma pergunta diferente. O épico diz que capacidade o produto precisa ganhar. A história diz o que um usuário específico consegue fazer quando ela estiver pronta. A tarefa diz o que os Developers vão executar para chegar lá. Misturar os níveis atrapalha a priorização, a estimativa e a conversa com quem paga o projeto.
Abaixo estão a definição de cada nível, uma tabela com as diferenças, um exemplo completo e as formas mais usadas de quebrar um épico.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
Épico, história e tarefa estão no Guia do Scrum?
Não. O Guia do Scrum 2020 fala em itens do Product Backlog e diz que, na Sprint Planning, os Developers costumam decompor os itens em unidades de trabalho de um dia ou menos. Os termos épico, história de usuário e tarefa não aparecem no texto. Eles vêm de práticas complementares, muito difundidas pelos métodos ágeis e pelas ferramentas de gestão, e o Scrum aceita qualquer uma delas desde que o backlog continue ordenado, transparente e útil.
Isso tem uma consequência prática: não existe "o jeito oficial" de usar épicos. O time decide quantos níveis precisa. Um produto pequeno pode viver só com histórias; um programa com vários times pode precisar de um nível acima do épico. O guia completo de métodos ágeis e Scrum mostra onde o backlog se encaixa no framework.
O que é épico
Épico é um item grande demais para caber numa Sprint. Ele descreve uma capacidade do produto que interessa ao negócio, como "pagamento por Pix", "retirada na loja" ou "agendamento on-line", e normalmente leva várias Sprints para ser entregue por completo.
Um bom épico tem três coisas:
- Um objetivo de negócio claro. Por que essa capacidade importa e para quem.
- Um limite. O que está dentro e o que fica de fora, para não virar uma gaveta sem fundo.
- Um jeito de saber que terminou. Um resultado observável, não "quando todas as histórias acabarem".
O épico fica no Product Backlog como referência e vai sendo dividido aos poucos. Não é preciso quebrá-lo inteiro no primeiro dia: só a parte que vai entrar nas próximas Sprints precisa estar detalhada.
O que é história de usuário
A história de usuário descreve uma necessidade do ponto de vista de quem usa o produto. O formato mais conhecido é: "Como [tipo de usuário], quero [ação], para [benefício]". Ela é pequena o bastante para ser concluída numa Sprint e vem acompanhada de critérios de aceite, que dizem como o time e o Product Owner vão verificar que a história está pronta.
Um teste conhecido para avaliar histórias é o INVEST, proposto por Bill Wake: a história deve ser independente, negociável, valiosa, estimável, pequena e testável. Se ela não passa no "pequena" ou no "estimável", provavelmente ainda é um épico disfarçado.
A história não é uma especificação completa. Ela é um lembrete de uma conversa, e o detalhe surge no refinamento. Para escrever histórias que entregam valor, o artigo sobre histórias de usuário com Kanban traz exemplos e critérios que servem também para times Scrum.
O que é tarefa
A tarefa é uma unidade de trabalho técnico que os Developers criam para entregar uma história: "criar endpoint de reserva", "ajustar layout da tela de confirmação", "escrever teste automatizado do cálculo de estoque". Ela não tem valor para o usuário sozinha e por isso não é priorizada pelo Product Owner.
As tarefas nascem na Sprint Planning, quando os Developers respondem à pergunta "como o trabalho escolhido será feito?", e continuam surgindo durante a Sprint, à medida que o time aprende. Elas fazem parte do Sprint Backlog, que é o plano dos Developers, e não do Product Backlog.
Diferenças entre épico, história e tarefa
| Critério | Épico | História de usuário | Tarefa |
|---|---|---|---|
| Pergunta que responde | Que capacidade o produto ganha? | O que um usuário consegue fazer? | O que o time precisa executar? |
| Tamanho típico | Várias Sprints | Cabe numa Sprint | Algumas horas a um dia |
| Quem conduz | Product Owner, com partes interessadas | Product Owner, com os Developers | Developers |
| Onde fica | Product Backlog | Product Backlog e, depois, Sprint Backlog | Sprint Backlog |
| Como se verifica | Resultado de negócio observado | Critérios de aceite e Definição de Pronto | Concluída ou não |
| Estimativa | Ordem de grandeza, se tanto | Story points ou outra unidade do time | Horas, ou nenhuma |
| Quem vê valor | Patrocinador e áreas de negócio | Usuário final | Só o time |
A linha mais importante da tabela é a primeira. Se um item do backlog não responde a nenhuma das três perguntas com clareza, ele precisa ser reescrito antes de ser priorizado.
Exemplo de épico Scrum, do épico às tarefas
O exemplo é ilustrativo. Uma rede de farmácias está construindo a loja on-line e quer reduzir a desistência de clientes que não podem esperar a entrega.
Épico: Retirada na loja. Objetivo: o cliente compra pelo site e retira o pedido numa farmácia da rede no mesmo dia. Fora do escopo: retirada em armário automático e entrega por motoboy. Sinal de sucesso: pedidos com retirada respondem por uma parte relevante das vendas on-line após o lançamento, medida que o Product Owner definirá com a área comercial.
Histórias derivadas do épico:
- Como cliente, quero escolher a farmácia de retirada no carrinho, para buscar o pedido perto de casa.
- Como cliente, quero ver se os itens estão disponíveis na loja escolhida, para não ir até lá à toa.
- Como cliente, quero receber uma mensagem quando o pedido estiver separado, para saber a hora de ir.
- Como atendente da loja, quero ver a lista de pedidos para retirada do dia, para separar com antecedência.
- Como atendente, quero confirmar a retirada com um código, para evitar entrega à pessoa errada.
Critérios de aceite da história 2 (exemplo): a disponibilidade aparece ao selecionar a loja; item indisponível fica marcado e não pode seguir para pagamento com retirada; a consulta responde em poucos segundos mesmo nos horários de pico.
Tarefas da história 2, criadas pelos Developers na Sprint Planning: consultar o serviço de estoque por loja; criar o componente de aviso de indisponibilidade; tratar o caso de estoque desatualizado; escrever testes automatizados da regra de bloqueio; validar com a área de lojas o tempo de atualização do estoque.
Repare que o Product Owner ordena as histórias 1 a 5 entre si e frente a outros épicos. As tarefas da história 2 são decisão dos Developers.
Como quebrar um épico em histórias
Quebrar bem é o que separa um backlog útil de uma lista de desejos. As formas mais usadas:
- Pelas etapas do fluxo do usuário. Escolher loja, ver disponibilidade, pagar, ser avisado, retirar. Cada etapa vira uma ou mais histórias. O User Story Mapping organiza esse corte pela jornada do usuário.
- Por tipo de usuário. Cliente e atendente têm necessidades diferentes dentro do mesmo épico.
- Por regra de negócio. Primeiro a regra simples (produtos sem receita), depois as exceções (medicamentos controlados).
- Caminho feliz primeiro. Entregar o fluxo que funciona quando tudo dá certo e tratar erros e exceções em histórias seguintes.
- Por variação de dado ou canal. Site antes do aplicativo, uma região antes de todas.
- Por operação. Criar, consultar, alterar e cancelar podem ser histórias separadas.
Evite quebrar por camada técnica ("história do banco de dados", "história da tela"). Isso produz itens que não entregam nada ao usuário sozinhos e que só têm valor quando todos estiverem prontos. Esse trabalho de divisão acontece no refinamento do backlog, que mostra como preparar as histórias resultantes para a Sprint Planning.
Como isso aparece no Jira e em outras ferramentas
Nas ferramentas de gestão ágil, os três níveis costumam virar tipos de item. No Jira, a documentação da Atlassian descreve o épico como item pai e coloca história, tarefa e bug no mesmo nível logo abaixo dele, com a subtarefa um nível abaixo. O administrador pode criar e personalizar outros tipos.
Isso gera uma confusão frequente: no Jira, "tarefa" é irmã da história, e não filha. O que este artigo chama de tarefa (o trabalho técnico dentro de uma história) corresponde à subtarefa da ferramenta. Combine com o time qual tipo de item representa o quê e registre a convenção, para que relatórios e quadros façam sentido.
Erros comuns com épicos, histórias e tarefas
- Épico que nunca termina. Sem limite e sem sinal de sucesso, o épico vira categoria permanente. Feche e abra outro.
- História escrita como tarefa. "Criar tabela de pedidos" não é história; é trabalho técnico de alguma história ainda não escrita.
- Product Owner distribuindo tarefas. As tarefas são o plano dos Developers. O PO esclarece o que e por que, não o como.
- Detalhar todos os épicos de uma vez. O que está longe no backlog muda. Detalhe o suficiente para uma ou duas Sprints.
- Histórias sem critérios de aceite. Sem eles, "pronto" vira opinião, e a discussão aparece na Sprint Review.
Para ver como esses níveis convivem com o resto do backlog, inclusive bugs e itens técnicos, veja o que é backlog na metodologia ágil.
O que fazer agora
Pegue os dez primeiros itens do seu Product Backlog e classifique cada um: é épico, história ou tarefa? Reescreva os que estiverem no nível errado e confira se cada épico tem objetivo, limite e sinal de sucesso. Se o time usa o Jira, aproveite para alinhar a hierarquia de tipos de item com essa convenção. O curso Jira Avançado da Projeto Diário trata da configuração de fluxos, quadros, automações e relatórios no Jira, para que a ferramenta reflita o backlog que o time realmente usa.
