Como dividir histórias de usuário após o Planning Poker

Para dividir uma história de usuário grande, comece pelo menor resultado útil que uma pessoa consegue perceber, não pelas camadas técnicas. Separe caminhos, regras, tipos de dado ou níveis de experiência; mantenha em cada fatia o necessário para funcionar de ponta a ponta; escreva critérios observáveis; e só então volte ao Planning Poker para estimar cada recorte.

Uma carta alta não ordena automaticamente a divisão. Ela é um sinal de diagnóstico: o item pode combinar resultados demais, conter uma incerteza dominante ou simplesmente estar mal compreendido. A ação correta é descobrir qual desses problemas existe antes de transformar 21 em três histórias arbitrárias.

Resposta direta: o que fazer depois de uma carta alta

Sinal da rodada	Diagnóstico provável	Próxima ação
A maioria escolhe a maior carta disponível	O resultado pode ser amplo demais para uma única unidade de entrega	Procure uma primeira fatia vertical e reestime
Aparecem cartas altas e `?`	O desconhecido pode dominar o tamanho	Registre a pergunta; faça uma investigação curta se necessário
Os votos vão de `3` a `21`	As pessoas podem estar estimando escopos diferentes	Compare premissas antes de decidir se deve dividir
O item só cabe quando UI, API e banco viram trabalhos separados	A divisão é horizontal e ainda não entrega um resultado observável	Recombine uma faixa fina de cada camada em uma fatia vertical
A nova história continua reunindo vários fluxos alternativos	O primeiro corte ainda está largo	Aplique outra lente: caminho, regra, dado ou interface

O Scrum Guide não define um limite universal de story points. Ele afirma que itens prontos para seleção podem ser concluídos dentro de uma Sprint e que o refinamento os quebra e define em itens menores e mais precisos. Portanto, 13 ou 21 podem ser gatilhos internos, mas não são uma regra do Scrum.

Dividir não é transformar uma história em departamentos

Uma boa fatia vertical atravessa as partes necessárias do produto para mudar um comportamento observável. Pode envolver interface, regra, integração e persistência, mas em uma faixa estreita. Ao concluí-la, existe algo verificável por quem usa ou depende do sistema.

Uma divisão horizontal separa componentes: “criar tabela”, “fazer endpoint”, “montar tela” e “testar fluxo”. Esses itens podem ser úteis como tarefas de implementação, porém dependem uns dos outros para produzir o resultado. A Agile Alliance alerta que histórias não costumam corresponder a um componente técnico ou de interface e associa incrementos pequenos a feedback mais rápido.

Divisão horizontal	Fatia vertical
Banco de dados do checkout	Finalizar pedido com cartão nacional aprovado
Endpoint de pagamentos	Finalizar pedido com Pix confirmado
Tela de confirmação	Consultar o estado do pedido após o pagamento
Testes do checkout	Tratar pagamento recusado com mensagem acionável

Fato de framework: o Product Backlog pode ser refinado em itens menores, e quem realizará o trabalho é responsável pelo dimensionamento. Interpretação: Planning Poker pode revelar quando o item ainda está largo. Recomendação prática: use a carta alta para abrir uma decisão de produto, não para negociar um número no meio da escala.

Quando uma história está grande demais

Não existe um corte numérico que funcione para todas as equipes. Story points são relativos ao contexto, às referências e à Definition of Done de cada time. Use sinais combinados.

Se a equipe ainda precisa verificar objetivo, critérios, dependências ou conhecimento mínimo, comece pelo checklist de refinamento antes do Planning Poker. Dividir é uma das saídas do refinamento, não um substituto para esclarecer o item.

Ela não pode chegar a Done dentro da Sprint

Esse é o teste mais próximo do texto do Scrum Guide. “Cabe” não quer dizer apenas codificar: inclui validação, integração e tudo o que a equipe exige para criar um Increment utilizável.

Ela contém resultados que poderiam ser ordenados separadamente

Se o Product Owner escolheria entregar pagamento com cartão antes de Pix, ou busca por título antes de filtros avançados, há caminhos com valor e prioridade próprios. Isso costuma indicar uma divisão promissora.

A conversa alterna entre muitos contextos

Quando a estimativa precisa cobrir várias personas, canais, regras, países, permissões ou exceções, talvez a equipe esteja tentando pontuar uma pequena feature inteira, não uma história.

A maior parte do número é desconhecimento

Uma fatia menor não resolve automaticamente uma dúvida arquitetural que afeta todas as opções. Nesse caso, extraia uma investigação com pergunta, limite de tempo e saída verificável. O artigo sobre cartas especiais do Planning Poker mostra como tratar ? sem convertê-lo em um número inflado.

Os extremos descrevem trabalhos diferentes

Antes de dividir, peça às pessoas com menor e maior voto que expliquem o que incluíram. O guia de divergência de votos no Planning Poker ajuda a separar uma lacuna de entendimento de um item realmente grande.

Cinco lentes para encontrar uma fatia menor

Mike Cohn organiza cinco abordagens no acrônimo SPIDR: spike, caminhos, interfaces, dados e regras. Use as lentes como perguntas, não como uma receita rígida. O resultado ainda precisa preservar valor e ser testável.

1. Caminho: qual jornada pode vir primeiro?

Separe fluxos que levam ao mesmo objetivo por rotas diferentes. Em checkout, cartão e Pix são caminhos distintos. Em autenticação, senha e provedor corporativo também podem ser.

Pergunta útil: qual caminho atende um grupo real primeiro sem obrigar a construção dos demais?

2. Regra: qual política pode ser adicionada depois?

Comece com o conjunto mínimo seguro de regras e adicione variações em histórias posteriores. Um cálculo pode tratar clientes padrão antes de contratos especiais, desde que a limitação seja explícita e aceitável.

Não adie segurança, conformidade ou qualidade essencial apenas para fazer a história parecer pequena. Dividir exige um trade-off de produto consciente.

3. Dado: qual subconjunto entrega aprendizado real?

Restrinja formatos, regiões, categorias ou volumes quando o recorte ainda atende um uso verdadeiro. Um importador pode aceitar CSV no primeiro incremento e planilhas em outro. O primeiro formato não é “metade do backend”; é um fluxo completo para um conjunto de dados menor.

4. Interface: qual experiência simples já permite concluir o objetivo?

Uma interação básica pode anteceder automações, atalhos ou visualizações avançadas. A simplificação precisa continuar utilizável. “Backend pronto, tela depois” não é uma versão simples da experiência; é uma dependência interna.

5. Investigação: qual pergunta bloqueia uma divisão responsável?

Use um spike quando a equipe não sabe, por exemplo, se um provedor suporta idempotência ou qual volume muda a arquitetura. Defina a decisão que a investigação deve habilitar. “Estudar pagamentos” é vago; “validar se a API permite repetir a confirmação sem criar dois pedidos” é verificável.

O guia abrangente da Humanizing Work acrescenta um teste importante: as fatias devem continuar verticais e ser avaliadas depois do corte. A técnica usada não compensa uma história que perdeu valor, independência ou testabilidade.

Fluxo: da carta alta à nova estimativa

Fluxo que transforma uma carta alta em diagnóstico, fatia vertical, validação e nova rodada de Planning Poker — A nova votação só começa depois que a equipe consegue nomear o resultado, os limites e a forma de validar a fatia.

O fluxo evita dois atalhos ruins: escolher um número menor sem mudar o escopo e abrir várias tarefas técnicas sem produzir uma entrega independente. Se a fatia não passa no teste, volte à decisão de produto; se a dúvida bloqueia todas as opções, investigue antes de votar novamente.

Passo a passo para dividir e reestimar

1. Encerre a rodada sem forçar uma estimativa

Registre que o item precisa ser dividido ou investigado. Uma sessão útil pode terminar sem número. A equipe ganhou informação sobre o backlog, mesmo que ainda não tenha uma estimativa acordada.

2. Escreva o resultado e o limite atual

Complete duas frases:

a pessoa consegue: qual comportamento novo será possível;
nesta fatia não entra: quais caminhos, regras ou dados ficam explícitos para depois.

Isso reduz a chance de a história encolher apenas no título enquanto os critérios continuam cobrindo tudo.

3. Escolha uma lente de corte

Comece por caminho, regra, dado ou interface. Use investigação apenas quando falta conhecimento para escolher um corte. Se a primeira lente não produzir uma fatia coerente, combine duas de forma controlada — por exemplo, “cartão nacional” combina caminho de pagamento e subconjunto de dado.

4. Verifique valor, ponta a ponta e teste

Faça quatro perguntas:

existe uma pessoa ou parte interessada que percebe o resultado?
a fatia pode ser demonstrada sem depender da conclusão das demais?
ela atravessa as camadas necessárias para funcionar?
os critérios dizem como confirmar o comportamento?

Se a resposta for “não” porque o item é apenas API, tela ou banco, você provavelmente criou uma tarefa técnica, não uma fatia vertical.

5. Ordene antes de detalhar tudo

Escolha a primeira fatia pelo equilíbrio entre valor, risco e aprendizado. Não é preciso decompor toda a feature com o mesmo detalhe. Itens próximos recebem mais precisão; os distantes podem permanecer maiores até se aproximarem da execução.

6. Nomeie a nova rodada pelo resultado

Use “Checkout — cartão nacional sem cupom”, não “Parte 1 do checkout”. O título compartilhado ajuda todos a estimarem o mesmo recorte e deixa o histórico mais compreensível.

7. Vote novamente com referências da equipe

No Battle Poker, a equipe pode criar uma sala sem cadastro, compartilhar o link e nomear a rodada. Os votos ficam ocultos até a revelação simultânea. Depois, distribuição e extremos ajudam a verificar se a divisão reduziu o escopo ou apenas escondeu trabalho.

8. Registre uma decisão, não uma média automática

Se a conversa convergir, confirme a estimativa acordada. Se a fatia mudou durante a discussão, refaça a rodada. O histórico permite manter o contexto das rodadas; ele não substitui os critérios e premissas que devem permanecer no backlog da equipe.

Para calibrar a comparação relativa, use o método do guia de como estimar story points.

Exemplo completo: checkout com vários meios de pagamento

A equipe recebe a história:

Como cliente, quero finalizar minha compra com diferentes meios de pagamento para receber meu pedido.

Os critérios misturam cartão, Pix, cupom, antifraude, parcelamento, mensagens de recusa, retomada da compra e conciliação. Na primeira rodada aparecem 13, 21 e ?.

Diagnóstico da rodada

Quem votou 13 considerou apenas cartão à vista. Quem votou 21 incluiu Pix, parcelamento e antifraude. A pessoa que escolheu ? não sabe se a API do provedor trata tentativas repetidas com segurança.

O problema não é apenas tamanho: existem escopos diferentes e uma dúvida transversal.

Cenário feliz: uma fatia vertical pequena

A equipe escolhe o caminho “cartão nacional à vista” e adia Pix e parcelamento. Também limita a primeira fatia a pedidos sem cupom. O resultado fica:

Como cliente com cartão nacional, quero concluir uma compra à vista sem cupom para receber a confirmação do pedido.

Critérios essenciais:

pagamento aprovado cria um único pedido e mostra confirmação;
pagamento recusado não cria pedido e informa como tentar novamente;
uma repetição da confirmação não duplica o pedido;
Pix, parcelamento, cupom e cartão internacional ficam fora desta fatia.

Essa história ainda atravessa interface, regra, integração e dados. Ela é menor porque atende um caminho e um conjunto de regras restritos, não porque cada camada virou uma história diferente.

Depois de esclarecer idempotência com o provedor, a nova rodada revela 5, 5, 8 e 5. Quem escolheu 8 lembra o teste de concorrência; a equipe inclui o caso, compara com uma referência concluída e registra a decisão. Em seguida, ordena “Pix confirmado” e “parcelamento” como fatias posteriores.

Cenário de falha: componentes disfarçados de histórias

A equipe cria quatro itens: “modelar tabelas”, “integrar gateway”, “fazer checkout” e “testar pagamento”. Todos precisam terminar para alguém comprar. O backlog parece menor, mas o risco de integração foi empurrado para o final e nenhum item isolado produz feedback sobre o fluxo.

Correção: escolha um caminho estreito e inclua nele a faixa mínima de dados, integração, interface e teste necessária para concluir a compra.

Cenário alternativo: a incerteza impede o corte

O provedor não documenta claramente como tratar callbacks repetidos, e essa regra afeta cartão e Pix. A equipe não cria duas histórias infladas com a mesma dúvida. Ela define uma investigação curta: reproduzir callbacks duplicados no ambiente de teste, verificar a chave de idempotência e registrar a estratégia recomendada. Com a evidência, volta a fatiar e estimar.

Como escolher a primeira fatia

Critério	Pergunta	Sinal favorável
Valor	Quem consegue fazer algo novo?	Existe um resultado perceptível
Aprendizado	O que esta entrega valida cedo?	Reduz uma hipótese de produto ou técnica
Risco	Qual perigo vale enfrentar primeiro?	O risco fica visível sem ampliar todo o escopo
Independência	Pode ser ordenada sem concluir todas as outras?	Há poucos acoplamentos de prioridade
Testabilidade	Como saberemos que terminou?	Critérios observáveis e executáveis
Tamanho	Pode chegar à Definition of Done na Sprint?	A equipe consegue explicar o recorte e compará-lo

Recomendação: prefira a menor fatia que preserve um resultado real e gere aprendizado relevante. A menor quantidade de código não é necessariamente a melhor primeira entrega.

Erros comuns ao dividir histórias

Usar um número como regra universal

“Tudo acima de 13 deve ser dividido” pode ser um acordo local, não uma verdade geral. Uma equipe pode usar outra escala; referências e capacidade também mudam. Combine o gatilho com os testes de valor, prontidão e tamanho.

Criar “parte 1”, “parte 2” e “parte 3”

Esses títulos escondem resultado e limites. Nomeie cada fatia pelo comportamento que ela habilita.

Separar desenvolvimento e teste

Uma história só fica pronta quando atende à Definition of Done. Teste não é uma entrega posterior usada para diminuir artificialmente a estimativa.

Adiar qualidade essencial

Segurança, acessibilidade, observabilidade ou conformidade podem fazer parte do padrão mínimo do produto. Negocie níveis e casos conscientemente; não remova obrigações silenciosamente.

Detalhar todas as fatias futuras

O refinamento é contínuo. Detalhar agora cada exceção de um item distante cria inventário e pode congelar decisões antes do aprendizado.

Reestimar sem alterar o escopo

Se o item continua com os mesmos critérios, escolher 8 no lugar de 21 não é divisão. Mostre o que saiu, o que permaneceu e por que a fatia ainda entrega valor.

Confundir divergência com tamanho

Votos distantes podem indicar premissas diferentes. Converse antes de cortar. Às vezes uma resposta esclarece o item e a segunda rodada converge sem divisão.

Checklist antes da nova rodada

Perguntas frequentes

Toda história com 13 ou 21 pontos deve ser dividida?

Não existe limite universal. A equipe pode usar esses valores como gatilho para verificar se o item cabe na Sprint, reúne resultados independentes ou contém incerteza removível. A decisão depende da escala e das referências locais.

Qual é a diferença entre história, tarefa e épico?

Uma história descreve um incremento funcional pela perspectiva de quem recebe valor. Tarefas organizam como a equipe implementará esse resultado. “Épico” é um rótulo comum para um item grande que será refinado, mas o Scrum Guide não prescreve esses três formatos.

Uma fatia precisa poder ir para produção sozinha?

Ela precisa produzir um incremento utilizável e verificável dentro do padrão de qualidade da equipe. A decisão de liberar imediatamente pode depender de estratégia, operação ou mercado; “utilizável” e “já lançado” não são sinônimos.

Posso dividir por front-end e back-end?

Como tarefas internas, sim. Como histórias independentes, geralmente é um corte horizontal: nenhuma parte entrega o resultado sozinha. Prefira uma faixa funcional fina que atravesse as camadas necessárias.

O que fazer se nenhuma divisão parece pequena?

Volte ao objetivo do usuário, procure caminhos e regras opcionais e verifique se uma incerteza técnica domina todas as opções. Se dominar, faça uma investigação curta antes de tentar estimar de novo.

É obrigatório usar SPIDR?

Não. SPIDR é uma forma prática de lembrar lentes de divisão, não uma regra do Scrum. Você pode usar story mapping, exemplos de negócio ou outro método, desde que as fatias preservem valor, testabilidade e coerência.

O Battle Poker divide histórias automaticamente?

Não. A ferramenta apoia a conversa com sala compartilhável, votos ocultos, revelação simultânea, distribuição, nova rodada e histórico. A equipe continua responsável por definir o recorte e atualizar o backlog.

Conclusão: uma carta alta deve produzir uma decisão

O melhor resultado de uma rodada com 21 talvez não seja um número. Pode ser a descoberta de que a equipe juntou caminhos demais, confundiu tarefas com valor ou precisa responder uma pergunta antes de comparar o trabalho.

Use a sequência: diagnostique o motivo, defina o menor resultado útil, corte verticalmente, valide a fatia e reestime. Quando o novo recorte estiver claro, crie uma sala no Battle Poker, nomeie a fatia e deixe as cartas testarem a qualidade da divisão. Se os votos continuarem altos, isso é informação para uma nova conversa — não uma falha da cerimônia.