Feature, User Story e Task: a hierarquia da entrega

O que é a hierarquia Feature → User Story → Task

A hierarquia Feature → User Story → Task é a forma de organizar o trabalho de um time em três níveis de detalhe, do mais estratégico ao mais operacional. A Feature é uma entrega grande, com nome de negócio, que leva semanas ou meses para ficar pronta. A User Story é uma fatia dessa entrega que cabe dentro de uma sprint e gera valor perceptível para alguém. A Task é o passo concreto de execução — algo que uma pessoa resolve em algumas horas — necessário para completar uma User Story. O Bug entra no mesmo nível da Story: um defeito em algo já entregue, ligado à Feature de origem.

Os três níveis se encaixam como bonecas russas: toda Task pertence a uma User Story, e toda User Story pertence a uma Feature. Essa regra simples é o que dá rastreabilidade à entrega. Qualquer pessoa do time consegue olhar para a menor tarefa do dia e responder "por que estou fazendo isso?" subindo dois níveis; e o gestor consegue olhar para a Feature e responder "quanto falta?" descendo dois níveis. Sem a hierarquia, o board vira uma pilha de cartões soltos em que ninguém enxerga o todo.

Vale dizer também o que a hierarquia não é: não é burocracia de ferramenta nem exclusividade de time de tecnologia. O vocabulário vem do mundo ágil, mas a lógica é universal — objetivo grande, fatias de valor, passos de execução. Um time de marketing, de RH ou de operações se organiza exatamente da mesma forma, como os exemplos mais adiante mostram.

Os três níveis, um a um

Feature: a entrega com nome de negócio

A Feature é o nível que conversa com a estratégia. Ela tem nome que um diretor entende sem tradução: "Portal de autoatendimento do cliente", "Campanha de lançamento do produto X", "Onboarding digital dos novos colaboradores". Uma Feature atravessa várias sprints, agrupa de três a dez User Stories e só é considerada pronta quando o objetivo de negócio foi atingido — não quando "a maioria dos cartões andou".

Dois sinais de uma Feature bem definida: ela tem um resultado observável (dá para saber quando acabou) e um porquê explícito (o problema ou a oportunidade que motivou a entrega). Feature sem fim definido vira geladeira de desejos — tudo que aparece é jogado lá dentro e ela nunca fecha.

User Story (e Bug): a fatia de valor

A User Story é o coração da hierarquia. Ela descreve uma necessidade na perspectiva de quem usa o resultado, normalmente no formato "Como [pessoa], quero [ação] para [benefício]", e precisa caber dentro de uma sprint. É na Story que mora a conversa sobre escopo, os critérios de aceite e a estimativa — se o seu time usa story points, eles são atribuídos à Story, nunca às Tasks. Escrever uma boa Story é uma habilidade em si; se o time ainda patina nisso, vale ler o guia de como escrever uma User Story.

O Bug vive no mesmo nível da Story, e por um bom motivo: ele também é uma unidade de trabalho que cabe numa sprint, também pertence a uma Feature e também pode ser quebrado em Tasks. A diferença é a natureza — a Story adiciona valor novo; o Bug conserta valor que já foi entregue e quebrou. Registrar o defeito do jeito certo, com passos para reproduzir e comportamento esperado, encurta muito a correção; o artigo sobre como reportar um bug detalha esse formato.

Task: o passo de execução

A Task é o nível do "mão na massa": uma ação concreta, com verbo no infinitivo, que uma pessoa executa em algumas horas — no máximo um dia. "Escrever o texto do e-mail de boas-vindas", "Configurar o formulário da landing page", "Revisar a planilha de acessos". A Task não precisa de formato especial nem de estimativa em pontos; ela é o checklist vivo de uma Story. Quando todas as Tasks de uma Story terminam (e os critérios de aceite passam), a Story está pronta.

Um teste rápido para saber se algo é Task ou Story: pergunte "isso gera valor sozinho para alguém de fora do time?". Se sim, é Story. Se só faz sentido como parte de algo maior, é Task.

Quem cria o quê: o gestor estrutura, o time detalha

A hierarquia funciona porque cada nível tem um dono natural. O gestor (ou Product Owner, ou coordenador — o nome varia por área) é quem estrutura as Features: ele conversa com stakeholders, enxerga o trimestre e decide quais entregas grandes importam agora. Essa é uma decisão de priorização, e priorizar é escolher o que não fazer — o guia de priorização de backlog trata exatamente disso.

Já as User Stories e as Tasks são do time. Quem executa o trabalho é quem melhor sabe fatiá-lo: o time conhece as dependências, os riscos e os atalhos que o gestor, de fora, não vê. Na prática, o ritmo saudável é este: antes da planning, o gestor chega com as Features priorizadas e o contexto de negócio; durante a montagem da sprint, o time quebra as Features em Stories, estima e negocia o que cabe; as Tasks nascem na própria planning ou nos primeiros dias da sprint, conforme cada Story é puxada.

Essa divisão protege as duas pontas. O gestor que desce ao nível da Task e escreve o passo a passo dos outros está microgerenciando — e sinalizando que não confia no time. O time que sobe ao nível da Feature e decide sozinho as apostas do trimestre está navegando sem alinhamento estratégico. Cada um no seu nível, com conversa constante entre eles, é o desenho que escala.

Por que toda Story vive numa Feature (e toda Task numa Story)

A obrigatoriedade da hierarquia parece rigidez, mas é ela que responde, em segundos, às três perguntas que mais consomem energia de um time:

• "Por que estou fazendo isso?" — qualquer Task sobe até a Story e a Feature. O contexto viaja junto com o trabalho, e ninguém executa no escuro.
• "Quanto falta para entregar?" — o progresso das Stories se acumula na Feature. O gestor vê o avanço real da entrega grande sem interrogar pessoa por pessoa.
• "O que acontece se cortarmos isto?" — quando o prazo aperta, dá para olhar a árvore e escolher qual fatia sai, sabendo exatamente qual objetivo é afetado.

Sem a regra, aparecem os dois vilões clássicos do backlog. A Task órfã: um cartão solto ("ajustar relatório") que ninguém lembra por que existe, não conta para nenhum progresso e sobrevive de sprint em sprint por inércia. E a Story órfã: trabalho de valor real, mas desconectado de qualquer objetivo — o time entrega, entrega, e no fim do trimestre ninguém consegue dizer qual aposta avançou.

No TeamBOX, essa hierarquia é obrigatória por design: não existe User Story fora de uma Feature nem Task fora de uma Story. O board da sprint mostra apenas as User Stories — as Tasks vivem dentro do cartão de cada uma —, os story points ficam só na Story e o progresso das Features se consolida sozinho. A ferramenta impede o cartão órfão justamente para que a rastreabilidade nunca dependa de disciplina individual.

Exemplo completo 1: time de marketing

A hierarquia não é coisa de TI — métodos ágeis funcionam em qualquer área. Veja a árvore completa de um time de marketing lançando um material rico:

Feature: Lançamento do e-book "Tendências do varejo 2027"

• User Story: Como visitante do site, quero baixar o e-book em troca do meu e-mail para receber o conteúdo completo.
  • Task: Escrever o texto da landing page
  • Task: Criar o formulário de captura integrado ao CRM
  • Task: Diagramar a capa e as páginas finais do e-book
  • Task: Configurar o e-mail automático com o link de download
• User Story: Como lead que baixou o e-book, quero receber uma sequência de três e-mails para aprofundar os temas e conhecer a solução.
  • Task: Escrever os três e-mails da régua
  • Task: Configurar a automação com intervalos de dois dias
  • Task: Definir o critério de saída da régua (lead respondeu ou virou oportunidade)
• Bug: Formulário da landing page não envia no celular.
  • Task: Reproduzir o erro nos principais navegadores móveis
  • Task: Corrigir o botão de envio e revalidar

Repare como qualquer Task faz sentido lida de baixo para cima: "escrever os três e-mails da régua" existe para a Story da sequência, que existe para o lançamento do e-book. E o gestor, olhando só a Feature, sabe que a entrega tem duas Stories e um Bug — e enxerga o avanço sem abrir cartão por cartão.

Exemplo completo 2: time de RH

Agora a mesma estrutura num time de RH modernizando a chegada de novos colaboradores:

Feature: Onboarding digital dos novos colaboradores

• User Story: Como novo colaborador, quero receber um kit de boas-vindas digital antes do primeiro dia para chegar sabendo o básico da empresa.
  • Task: Escrever o guia de boas-vindas (cultura, benefícios, quem procurar)
  • Task: Gravar o vídeo curto de boas-vindas da diretoria
  • Task: Montar o checklist de acessos e equipamentos com o TI
  • Task: Criar o e-mail padrão de envio do kit
• User Story: Como gestora de um novo contratado, quero um roteiro pronto da primeira semana para conduzir a integração sem improviso.
  • Task: Mapear os encontros essenciais da semana 1 (buddy, RH, time)
  • Task: Escrever o roteiro do primeiro 1:1 entre gestora e contratado
  • Task: Validar o roteiro com três gestores de áreas diferentes
• Bug: Link do vídeo de boas-vindas expira depois de sete dias.
  • Task: Trocar o vídeo para um repositório com link permanente
  • Task: Atualizar o e-mail padrão com o novo link

Dois setores completamente diferentes, a mesma árvore: entrega grande com nome de negócio, fatias que geram valor para alguém específico (o novo colaborador, a gestora) e passos de execução que uma pessoa resolve em horas.

Erros comuns ao montar a hierarquia

Alguns tropeços aparecem em quase todo time que adota a estrutura — vale conferir a lista antes de rodar a primeira sprint:

1. Feature que nunca fecha. Se a Feature não tem resultado observável, ela vira um balde eterno. Defina o "pronto" dela no dia em que criá-la.
2. Story que é Task disfarçada. "Como analista, quero atualizar a planilha" não é uma Story — não há valor para ninguém de fora do time. Suba um nível na pergunta: para que a planilha precisa estar atualizada?
3. Task gigante. Se uma Task leva mais de um dia, ela provavelmente esconde uma Story inteira (ou duas). Quebre antes de começar.
4. Pular a hierarquia "para ir mais rápido". Um board só de tasks soltas parece ágil na primeira semana e vira névoa na quarta: ninguém sabe mais o que avançou de verdade.
5. Estimar Tasks em pontos. A estimativa pertence à Story; pontuar Task duplica a conta e gera discussão inútil. Task se mede em "fiz ou não fiz".
6. Bug enfiado como Task numa Story antiga. O defeito merece cartão próprio no nível da Story, ligado à Feature de origem — assim o retrabalho fica visível em vez de escondido.

Se o seu time acerta a hierarquia, o resto do método fica mais leve: a planning tem matéria-prima clara, o board conta uma história que qualquer pessoa lê e a pergunta "quanto falta?" deixa de precisar de reunião para ser respondida.