Epic, user story e tarefa: a diferença, com exemplos de dentro e de fora das TI

Um épico é um objetivo grande de mais para caber numa sprint. Uma user story (história de utilizador) é um pedaço desse objetivo que entrega valor a uma pessoa. Uma 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.

Perceber a diferença não é preciosismo do Scrum. É o que permite estimar, priorizar e acompanhar sem que o quadro se torne uma lista de afazeres sem hierarquia. E vale fora da TI: marketing, operações e atendimento dividem o trabalho da mesma maneira.

As três definições

Nível	Pergunta a que responde	Tamanho típico	Quem define
Épico	Que grande resultado queremos?	Várias semanas ou meses; mais do que uma sprint	Dono do produto ou da área
User story	O que consegue uma pessoa fazer de novo, e porquê?	Cabe numa sprint, de preferência em poucos dias	Dono do produto, com a equipa
Tarefa	O que tem de 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 a aplicação de pedidos" é um épico. "Reduzir o tempo de fecho do mês" também. É grande de propósito: serve para dar direção e agrupar histórias. Não se "termina um épico numa sprint"; acompanha-se pelo andamento das histórias que tem dentro.

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 à equipa propor uma solução mais simples do que a pedida. "Quero um botão de exportar" é uma solução. "Quero enviar o relatório ao meu cliente sem o refazer no Excel" é uma necessidade, e pode ter uma resposta melhor.

Tarefa

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

Como dividir um épico

Dividir bem é a competência central. Um roteiro em quatro passos funciona na maioria dos casos.

1. Escreva o resultado do épico numa 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 a base de dados" e "fazer o ecrã". Corte em fatias finas que atravessam tudo e já entregam algo utilizável, ainda que simples.
4. Teste cada história. É 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. Dividir tudo em tarefas com meses de antecedência gera um plano que será refeito: o conhecimento muda pelo caminho.

Exemplos para software

Épico: permitir que o cliente acompanhe os pedidos pelo telemóvel.

User story	Tarefas
Como cliente, quero ver o estado do meu pedido para não precisar de ligar para a loja.	Criar o ecrã de lista de pedidos; consultar o estado na API; tratar pedidos sem resposta; testar num telemóvel pequeno.
Como cliente, quero receber um 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 um pedido real.
Como atendente, quero ver o mesmo estado que o cliente vê para responder sem consultar o stock.	Mostrar o estado na ficha do cliente; criar a 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 os produtos em destaque; criar o banner; montar a página de ofertas; publicar e conferir no telemóvel.
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 administração; agendar o envio.
Como gestor, 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 fecho do mês no escritório de contabilidade.

User story	Tarefas
Como contabilista, quero receber os documentos do cliente completos até ao dia 5 para não andar atrás deles 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 que clientes ainda não enviaram para cobrar antes do prazo.	Montar a vista por cliente e estado; definir a rotina de cobrança; rever na reunião de segunda-feira.

Critérios de aceitação: o que diz que a história está pronta

Uma história sem critério de aceitação transforma-se em 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 bom critério é verificável por qualquer pessoa, sem interpretação. Compare:

Critério vago	Critério verificável
O ecrã deve ser rápido.	A lista de pedidos abre em até 3 segundos com 200 pedidos.
O e-mail deve estar bonito.	O e-mail aparece sem quebras no telemóvel e tem o botão de compra visível sem deslocar o ecrã.
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 utilizador realmente precisa. Três a cinco critérios por história são suficientes. Mais do que isso costuma indicar que a história é grande de mais.

Erros comuns

• Épico que nunca fecha. Quando o épico não tem um resultado claro, torna-se uma gaveta onde se atira qualquer coisa. Defina quando estará concluído.
• História técnica sem utilizador. "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. Divida. Uma tarefa grande esconde o atraso até à véspera do prazo.
• Hierarquia por vaidade. Não são precisos os três níveis para tudo. Um projeto pequeno pode viver só de histórias e tarefas, ou até só de tarefas.

Como isto 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 a equipa 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 da equipa. O que não vale é deixar o grande objetivo 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 planeamento da sprint, pronta a adaptar. Depois de executar uma sprint, o gráfico de burndown ajuda a ver se o trabalho está a andar: veja como ler o burndown.

Regra de bolso

Se se perguntar "isto 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 de mais para ser dividida. Com este teste de trinta segundos, a maior parte da discussão sobre nomes desaparece, e sobra o que interessa: trabalhar nas coisas pela ordem certa.