O que é Épico?

A expressão epic se difundiu nas práticas de User Stories e em ferramentas de gestão de produto para indicar histórias grandes. Mike Cohn discute a evolução de histórias e sua divisão em User Stories Applied, publicado em 2004. Não há uma definição formal única do termo em todos os métodos.

O Scrum Guide de 2020 define o Product Backlog como lista ordenada do que é necessário para melhorar o produto, mas não prescreve Épicos, histórias ou tarefas como níveis obrigatórios. Seu uso é uma convenção útil quando ajuda a conversar sobre intenção e a fatiar trabalho.

Uma oportunidade de produto pode ser importante antes que o time saiba exatamente qual solução construir. “Ajudar usuários a reagendar consultas” pode representar muitas jornadas, regras e dependências. Registrar essa intenção como Épico permite manter a conversa no Backlog sem fingir que o trabalho já está detalhado. Conforme se aproxima da decisão de entrega, o time investiga riscos e divide a necessidade em partes que possam gerar aprendizado e valor.

Grande não é apenas quantidade de pontos. Uma ideia pode ser um Épico por abrangência, incerteza ou dependências, mesmo sem estimativa. Outra pode parecer pequena em esforço, mas esconder questões de negócio que exigem exploração. Fixar um número universal de Story Points acima do qual todo item vira Épico pode ser uma convenção local, não regra do Scrum. A classificação deve ajudar a decidir o próximo passo.

Detalhe cresce com a proximidade. Um item distante pode ter problema, público e resultado esperado, sem todas as regras. Se ganha prioridade, o Product Owner e os Desenvolvedores conversam, dividem alternativas e esclarecem condições. Isso é parte do refinamento do Backlog. Especificar todas as partes de um Épico meses antes pode gerar trabalho descartado quando a hipótese muda.

Fatie pelo efeito para o usuário. Dividir “agendamento” em banco de dados, API e interface cria tarefas de componentes que não necessariamente produzem um Incremento utilizável. Um recorte vertical pode permitir primeiro consultar opções elegíveis, depois confirmar uma troca e depois receber aviso. Cada parte atravessa as competências necessárias para entregar um comportamento verificável. O Story Mapping pode ajudar a enxergar a jornada e escolher fatias, mas não é obrigatório.

Não prometa entregar todo o Épico. Depois da primeira fatia, a equipe pode descobrir que uma solução simples resolve a necessidade principal ou que a oportunidade não tem valor esperado. Algumas partes podem ser descartadas. Manter uma lista fixa de todas as histórias planejadas desde o início transforma o Épico em contrato de escopo e reduz aprendizado. Registre o resultado desejado e revise o plano.

Um Épico pode ser representado como item no Backlog ou como agrupamento de itens, dependendo da ferramenta e da política do time. O que importa é não contar simultaneamente o Épico e todas as suas fatias como entregas independentes. Isso distorce acompanhamento e priorização. Deixe visível que nível representa intenção ampla e que nível representa trabalho selecionável.

Diferencie Épico de tema. Um tema pode agrupar histórias relacionadas por objetivo ou área sem ter uma única necessidade grande a ser dividida. Por exemplo, “acessibilidade” pode reunir melhorias em várias jornadas; um Épico específico pode ser “permitir concluir matrícula com leitor de tela”. A nomenclatura varia. Explique o que cada agrupamento significa para a equipe antes de usar filtros ou métricas por categoria.

O Scrum Guide diz que itens prontos para seleção na Sprint Planning normalmente podem ser concluídos dentro de uma Sprint. Um Épico amplo costuma precisar de divisão antes de ser selecionado nesse formato. Mas isso não exige converter toda fatia em User Story com texto “Como... quero... para...”. Um item claro em outra forma também pode ser adequado, desde que o time compreenda a entrega.

Conecte ao objetivo. Uma lista de Épicos com nomes de funcionalidades pode virar portfólio de soluções pré-aprovadas. Para cada um, pergunte qual problema, público e resultado justificam o investimento. Um roadmap de produto pode mostrar temas e apostas ao longo do tempo, mas não precisa prometer todas as fatias com data fixa. A equipe aprende durante entrega e adapta o Backlog.

Quando um Épico envolve vários times, cuide das dependências sem repartir apenas por organograma. As pessoas precisam de uma visão comum do comportamento que será entregue e de um caminho para integrar partes. Criar subtarefas de cada área e marcar o Épico como quase concluído por meses pode esconder que nenhum usuário recebeu valor. Escolha recortes integráveis e observe o resultado real.

Imagine um serviço hipotético de biblioteca digital. O Épico “ajudar leitores a renovar empréstimos” entra no Backlog depois de reclamações sobre o processo presencial. A equipe ainda não sabe quais livros podem ser renovados, que regra limita a quantidade e como informar uma negativa. Os números seguintes são apenas ilustrativos.

Antes, o plano é implementar uma grande “área de empréstimos” com 12 telas e só lançar quando tudo estiver completo. O trabalho é dividido em banco, API e interface; cada frente avança, mas nenhuma pessoa consegue renovar um livro. A previsão de entrega fica frágil porque dúvidas de política aparecem no fim.

Depois, PO e Desenvolvedores conversam com a biblioteca e escolhem um primeiro recorte: mostrar se um empréstimo é elegível à renovação e por quê. Um segundo recorte permite renovar um item elegível. Um terceiro informa a nova data e oferece caminho quando a renovação é negada. Cada parte pode ser construída, testada e observada como comportamento útil.

Ao entregar o primeiro recorte, o time descobre que 4 tipos de obra não podem ser renovados por regra institucional. Isso muda os exemplos de teste e a ordem das próximas fatias. Talvez uma mensagem clara reduza parte das ligações antes de existir uma nova tela. O Épico mantém a intenção; o plano de implementação muda com a evidência.

Se, após duas fatias, a necessidade principal estiver atendida, não há obrigação de construir tudo o que havia sido imaginado. O PO pode encerrar o Épico ou registrar outra oportunidade. Concluir uma aposta de produto não é completar todas as caixas que foram desenhadas antes de aprender.

Curso K21 recomendado