Postagens

Como dividir epicos em historias prontas para o sprint

Um epico no seu backlog nao e trabalho. E uma promessa de que o trabalho existe em algum lugar dentro dele. Ate voce dividi-lo em historias que sua equipe consiga estimar e entregar em um unico sprint, e apenas um placeholder com ambicao. A maioria das equipes sabe disso. Onde elas travam e na divisao em si. O epico parece uma coisa so, e cada tentativa de separa-lo produz pecas pequenas demais para serem significativas ou grandes demais para caber em um sprint. Este guia aborda os padroes e tecnicas que tornam a divisao limpa.

O que torna uma historia "pronta para o sprint"

Uma historia pronta para o sprint atende a estes criterios:

• Pequena o suficiente para ser concluida em um sprint (idealmente 1-5 story points)
• Entregavel de forma independente, ou seja, nao depende de outras historias serem concluidas primeiro
• Fatiada verticalmente, entregando uma fatia fina de funcionalidade ponta a ponta, nao apenas uma parte do backend ou apenas a UI
• Estimavel pela sua equipe no planning poker sem um debate de 15 minutos
• Testavel com uma condicao clara de aprovacao/reprovacao

Se voce conhece os criterios INVEST, e a mesma ideia. O objetivo sao historias concretas o suficiente para serem construidas.

6 padroes para dividir epicos

Nao existe uma unica forma correta de dividir um epico. Mas esses seis padroes cobrem a maioria das situacoes. Tente-os em ordem. O primeiro que se encaixar geralmente produz as historias mais limpas.

1. Dividir por etapa do fluxo de trabalho

A maioria dos epicos descreve um processo com multiplas etapas. Cada etapa pode se tornar sua propria historia. Epico: "Como cliente, quero comprar um produto online."

Historia	Descricao
Navegar por produtos	Cliente pode visualizar um catalogo de produtos com filtragem
Adicionar ao carrinho	Cliente pode adicionar itens a um carrinho de compras
Checkout	Cliente pode inserir detalhes de envio e pagamento
Confirmacao do pedido	Cliente recebe um email de confirmacao apos a compra

Cada historia tem valor independente. Um cliente que pode navegar por produtos obtem valor mesmo antes do checkout existir.

2. Dividir por regra de negocio

Quando um epico tem logica condicional ou multiplas regras, cada regra e um ponto natural de divisao. Epico: "Como usuario, quero que o sistema calcule os custos de envio."

• Frete gratis para pedidos acima de R$50
• Taxa fixa de R$5 para envio domestico padrao
• Tarifas em tempo real da transportadora para envio expresso
• Envio internacional com estimativa de alfandega

Comece pela regra mais simples (taxa fixa) e adicione complexidade nos sprints seguintes.

3. Dividir por tipo de usuario

Se diferentes usuarios interagem com a mesma funcionalidade de formas diferentes, cada perspectiva e uma historia. Epico: "Como usuario, quero gerenciar os membros da equipe."

• Como admin, quero convidar novos membros por email
• Como admin, quero remover membros da equipe
• Como membro, quero ver quem esta na minha equipe
• Como proprietario, quero transferir a propriedade para outro admin

4. Dividir por caminho feliz vs. casos extremos

Construa o caso direto primeiro. Trate erros, casos extremos e validacoes em historias subsequentes. Epico: "Como usuario, quero fazer upload de fotos de perfil."

• Caminho feliz: Fazer upload de um JPEG ou PNG com menos de 5MB e ve-lo como meu avatar
• Caso extremo: Exibir um erro quando o arquivo e muito grande ou formato incorreto
• Caso extremo: Cortar e redimensionar a imagem antes de salvar
• Caso extremo: Excluir ou substituir uma foto existente

5. Dividir por tipo de dado ou plataforma

Se uma funcionalidade se aplica a multiplos tipos de dados, plataformas ou integracoes, cada um e uma historia. Epico: "Como usuario, quero exportar meus relatorios."

• Exportar como CSV
• Exportar como PDF
• Exportar como Excel
• Enviar uma exportacao agendada por email

6. Dividir por desempenho ou escala

Comece com algo que funcione para o caso comum. Otimize depois. Epico: "Como usuario, quero pesquisar em todos os projetos."

• Pesquisar dentro do projeto atual (consulta simples)
• Pesquisar em todos os projetos (requer indexacao)
• Adicionar filtros (periodo, responsavel, status)
• Sugestoes de autocompletar enquanto digita

Um exemplo real: dividindo "notificacoes do usuario"

Veja como isso funciona na pratica. Digamos que seu backlog tem este epico: "Como usuario, quero receber notificacoes sobre atividades relevantes para mim." Isso e enorme. Vamos aplicar os padroes: Primeiro, divida por fluxo de trabalho. Enviar, receber e gerenciar notificacoes sao preocupacoes separadas. Depois, divida por canal. Email, notificacoes in-app e push sao cada uma sua propria historia. Dentro de cada canal, divida por regra de negocio. Quais eventos disparam uma notificacao? Cada um (mencionado em um comentario, atribuido a uma tarefa, prazo se aproximando) e uma historia. Por fim, escolha o caminho feliz. Comece com "usuario recebe uma notificacao in-app quando atribuido a uma tarefa." Um canal, um gatilho, pronto. Adicione email, push, preferencias e opcoes de resumo depois. O resultado: em vez de um epico estimado como "enorme" que fica no backlog por tres sprints, voce obtem 8-12 historias que podem ser priorizadas, estimadas e entregues incrementalmente.

A regra da fatia vertical

O erro mais comum na divisao e separar um epico por camada tecnica: Em vez disso, fatie verticalmente. Cada historia deve tocar todas as camadas necessarias para entregar uma fina peca de funcionalidade que alguem possa realmente usar e testar. Uma fatia vertical para uma funcionalidade de notificacao pode ser: "Quando um usuario e atribuido a uma tarefa, uma notificacao in-app aparece." Isso toca o backend (gatilho de evento, registro de notificacao), a API (endpoint para buscar notificacoes) e o frontend (badge e lista de notificacoes). E fino, mas funciona de ponta a ponta.

Quando as historias ainda sao grandes demais

As vezes voce divide um epico e as historias resultantes ainda sao grandes demais. Alguns sinais:

• A equipe estima em 13+ pontos
• Tem mais de 5 criterios de aceitacao
• A descricao usa a palavra "e" para conectar dois comportamentos diferentes
• Varios membros da equipe precisariam trabalhar nela simultaneamente

Se isso acontecer, aplique os mesmos padroes novamente. Uma historia sobre "usuario pode fazer checkout com envio e pagamento" se divide em "usuario pode inserir endereco de envio" e "usuario pode inserir dados de pagamento." Continue ate que cada peca caiba confortavelmente em um sprint.

Usando ferramentas para acelerar a divisao

Dividir epicos e uma habilidade que melhora com a pratica, mas ferramentas podem acelerar o processo. O Story Splitter do Kollabe pega a descricao de um epico e gera historias prontas para o sprint usando os padroes acima. E um bom ponto de partida quando voce esta encarando um epico grande e nao sabe por onde cortar. Depois de ter suas historias, o User Story Generator pode ajudar a detalha-las com criterios de aceitacao adequados e o formato padrao de historia de usuario. Entao leve-as para o planning poker para estimar e validar se as divisoes realmente fazem sentido para sua equipe.

Um checklist rapido antes do sprint planning

Passe por isso antes de puxar qualquer historia dividida para um sprint: Se todos os seis criterios estiverem atendidos, suas historias estao prontas para o sprint planning.

Comece a dividir

Seis padroes, uma regra: cada historia deve entregar uma fatia vertical de valor que caiba em um sprint. Quando voce estiver travado encarando um epico vago, escolha o primeiro padrao que se aplica, faca o corte e valide com estimativa. Se as estimativas ainda estiverem muito dispersas, corte novamente.