Épico, user story e tarefa: a diferença, com exemplos de dentro e de fora da TI

Épico é um objetivo grande demais para caber numa sprint. User story (história de usuário) é um pedaço desse objetivo que entrega valor a uma pessoa. Tarefa é o trabalho concreto que alguém executa para entregar a história. A confusão acontece porque os três parecem "coisas a fazer", mas respondem a perguntas diferentes: o quê e para quê, para quem, e como.

Entender a diferença não é preciosismo do Scrum. É o que permite estimar, priorizar e acompanhar sem que o quadro vire uma lista de afazeres sem hierarquia. E vale fora da TI: marketing, operações e atendimento quebram trabalho do mesmo jeito.

As três definições

Nível	Pergunta que responde	Tamanho típico	Quem define
Épico	Qual resultado grande queremos?	Várias semanas ou meses; mais de uma sprint	Dono do produto ou da área
User story	O que uma pessoa consegue fazer de novo, e por quê?	Cabe numa sprint, de preferência em poucos dias	Dono do produto, com o time
Tarefa	O que precisa ser feito para entregar a história?	Horas ou um dia	Quem vai executar

Épico

Um épico descreve um resultado, não uma lista de atividades. "Lançar o aplicativo de pedidos" é um épico. "Reduzir o tempo de fechamento do mês" também. Ele é grande de propósito: serve para dar direção e agrupar histórias. Você não "termina um épico numa sprint"; você o acompanha pelo andamento das histórias dentro dele.

User story

A história descreve o que uma pessoa específica passa a conseguir, e o motivo. O formato clássico ajuda a não esquecer nenhuma das três partes:

Como [tipo de pessoa], quero [ação] para [benefício].

O motivo ("para") é a parte que mais se omite e a mais valiosa. É ele que permite ao time propor uma solução mais simples que a pedida. "Quero um botão de exportar" é solução. "Quero enviar o relatório ao meu cliente sem refazer no Excel" é necessidade, e pode ter resposta melhor.

Tarefa

A tarefa é o trabalho técnico ou operacional: criar a tela, escrever o texto, configurar o servidor, revisar o contrato. Tem um responsável e um estado simples (a fazer, fazendo, feito). Se a tarefa não puder ser concluída por uma pessoa em um dia, quase sempre é uma história disfarçada.

Como quebrar um épico

Quebrar bem é a habilidade central. Um roteiro em quatro passos funciona na maioria dos casos.

1. Escreva o resultado do épico em uma frase. Se precisar de duas, são dois épicos.
2. Liste as pessoas envolvidas. Cada tipo de pessoa costuma gerar histórias próprias: cliente, atendente, gestor, financeiro.
3. Corte por valor, não por camada. Evite histórias como "fazer o banco de dados" e "fazer a tela". Corte em fatias finas que atravessam tudo e já entregam algo utilizável, ainda que simples.
4. Teste cada história. Ela é independente das outras? Dá para estimar? Cabe numa sprint? Dá para verificar se ficou pronta?

Só depois, e só para as histórias que entrarão na próxima sprint, desça ao nível das tarefas. Quebrar tudo em tarefas com meses de antecedência gera plano que será refeito: o conhecimento muda no caminho.

Exemplos para software

Épico: permitir que o cliente acompanhe os pedidos pelo celular.

User story	Tarefas
Como cliente, quero ver o status do meu pedido para não precisar ligar para a loja.	Criar tela de lista de pedidos; consultar o status na API; tratar pedido sem retorno; testar em celular pequeno.
Como cliente, quero receber aviso quando o pedido sair para entrega para organizar a minha agenda.	Definir o gatilho de envio; escrever o texto da mensagem; configurar o envio; testar com pedido real.
Como atendente, quero ver o mesmo status que o cliente vê para responder sem consultar o estoque.	Exibir o status na ficha do cliente; criar permissão de visualização; validar com um atendente.

Exemplos para marketing

Épico: lançar a campanha de Black Friday da Loja Aurora.

User story	Tarefas
Como cliente da loja, quero ver as ofertas na página inicial para comprar sem procurar.	Escolher produtos em destaque; criar o banner; montar a página de ofertas; publicar e conferir no celular.
Como cliente antigo, quero receber a oferta por e-mail antes de todos para aproveitar primeiro.	Segmentar a lista; escrever o e-mail; aprovar com a diretoria; agendar o envio.
Como gerente, quero ver as vendas por canal para decidir onde investir mais verba.	Definir os canais de origem; configurar o rastreio; montar o painel; testar com um pedido de cada canal.

Exemplos para operações

Épico: reduzir o tempo de fechamento do mês no escritório de contabilidade.

User story	Tarefas
Como contador, quero receber os documentos do cliente completos até o dia 5 para não correr atrás no fim do mês.	Listar os documentos exigidos; criar o formulário de envio; configurar o lembrete ao cliente; testar com dois clientes.
Como coordenadora, quero ver quais clientes ainda não enviaram para cobrar antes do prazo.	Montar a visão por cliente e status; definir a rotina de cobrança; revisar na reunião de segunda.

Critérios de aceite: o que diz que a história está pronta

Uma história sem critério de aceite vira discussão no fim da sprint. O critério é a lista curta de condições que, se cumpridas, fazem a história contar como entregue. Escreva-os antes de começar o trabalho.

Um critério bom é verificável por qualquer pessoa, sem interpretação. Compare:

Critério vago	Critério verificável
A tela deve ser rápida.	A lista de pedidos abre em até 3 segundos com 200 pedidos.
O e-mail deve estar bonito.	O e-mail aparece sem quebra no celular e tem o botão de compra visível sem rolar.
O cliente deve conseguir enviar os documentos.	O cliente envia PDF e imagem de até 10 MB e recebe confirmação com protocolo.

Os números acima são exemplos para ilustrar o formato; defina os seus a partir do que o usuário realmente precisa. Três a cinco critérios por história são suficientes. Mais que isso costuma indicar que a história é grande demais.

Erros comuns

• Épico que nunca fecha. Quando o épico não tem um resultado claro, vira uma gaveta onde se joga qualquer coisa. Defina quando ele estará concluído.
• História técnica sem usuário. "Refatorar o módulo X" não é história, é tarefa ou dívida técnica. Se tem valor para alguém, escreva o benefício; se não, trate como tarefa.
• Tarefa com mais de um dia. Quebre. Tarefa grande esconde atraso até a véspera do prazo.
• Hierarquia por vaidade. Não são necessários os três níveis para tudo. Um projeto pequeno pode viver só de histórias e tarefas, ou até só de tarefas.

Como isso aparece numa ferramenta

O que importa é poder agrupar e ver o andamento do conjunto. Na Tasskee, a prática é usar tarefa e subtarefa para os níveis de baixo, e as sprints para os ciclos em que o time se compromete com um conjunto de histórias. Os épicos podem ser mantidos como frentes de trabalho ou como tarefas-mãe, conforme a preferência do time. O que não vale é deixar o objetivo grande só na cabeça de alguém.

Para começar com um exemplo pronto, o modelo de backlog e sprint traz a estrutura de lista priorizada e planejamento da sprint, pronta para adaptar. Depois de rodar uma sprint, o gráfico de burndown ajuda a ver se o trabalho está andando: veja como ler o burndown.

Regra de bolso

Se você se perguntar "isso entrega valor sozinho a alguém?" e a resposta for não, é tarefa. Se for sim e cabe numa sprint, é história. Se for sim, mas não cabe, é épico ou uma história grande demais para ser quebrada. Com esse teste de trinta segundos, a maior parte da discussão sobre nomes desaparece, e sobra o que interessa: trabalhar nas coisas na ordem certa.