Divisão de histórias de usuário que não cabem em um sprint

Dividir uma história de usuário significa dividir uma história que é grande demais em histórias menores, cada uma das quais ainda oferece algo que o usuário possa utilizar. Uma história que não dá para estimar geralmente é aquela que ainda não dá para entregar — e a divisão é a medida que a coloca de volta no quadro.

A maioria das conversas do tipo “não dá para estimar isso” são, na verdade, conversas sobre divisão de tarefas disfarçadas. A equipe não tem um problema de números e esforço; ela tem um problema de excesso de incógnitas. A divisão reduz as incógnitas até que a história assemelhe-se a um trabalho já realizado anteriormente — e as estimativas convergem.

Quando parar de estimar e começar a dividir

Uma história que não cabe em um sprint não é um problema de tamanho; é um problema de forma. Fique atento aos sinais:

• A equipe vota em 13 e 20, e depois continua votando novamente para chegar a um consenso, em vez de se dividir.
• “Depende” responde a mais do que algumas das perguntas de refinamento.
• A história abrange mais de uma área de atuação da equipe.
• “Concluído” requer várias implantações.
• É possível descrever isso em duas frases, mas não em dois critérios de aceitação.

Se você insistir mesmo assim, a equipe passa o sprint tentando e transfere o que sobrar para o próximo — o que é péssimo, pois o que é transferido é justamente o que era mais difícil — ou conclui um subconjunto pronto para lançamento e considera o trabalho concluído, enquanto o restante fica pela metade. Ambas as opções são piores do que dividir o trabalho propositalmente antes do início do sprint.

Por que uma grande diferença nos votos significa divisão, e não nova votação

Quando uma equipe de dimensionamento trabalha em conjunto com o planning poker, uma ampla dispersão é o sinal mais útil que isso produz. Cartas distribuídas de 3 a 13 não representam uma discordância numérica. São duas histórias fingindo ser uma só. Quem votou 3 está enxergando um escopo; quem votou 13 está enxergando um escopo diferente. Uma nova votação não vai conciliar os dois — o trabalho consiste na conversa para definir qual escopo é o real. Eis o que geralmente está acontecendo por trás disso:

• Uma pessoa está avaliando o cenário ideal; outra está avaliando os casos extremos.
• Uma pessoa parte do princípio de que o projeto já existe; outra, de que está criando-o.
• Uma pessoa está avaliando a consulta; outra está avaliando a implementação.
• Uma pessoa sabe que a dependência existe; a outra, não.
• Uma pessoa está avaliando as necessidades de alguém na sala; o trabalho é de outra equipe.

Mais detalhes raramente resolvem isso — isso só gera um ticket mais longo, não uma estimativa mais precisa. Dividir, sim: em um pico, se a incógnita for a causa; em fatias verticais, se a incógnita for o escopo. O fato de haver dois cartões espalhados não significa que a equipe discorde. Significa que a equipe está votando em histórias diferentes. Envie de volta.

Corte na vertical, não na horizontal

A divisão precisa ser vertical — uma fatia fina que seja realmente entregável por si só — e não horizontal. “Backend primeiro, frontend no próximo sprint” divide a história da mesma forma que uma faca corta a massa: você acaba com duas metades de nada. Uma fatia vertical abrange todas as camadas e entrega uma coluna funcional — um botão que funciona do início ao fim, mesmo que lide apenas com um caso de entrada. Consulte divisão horizontal x vertical para conhecer o princípio na íntegra.

Padrões de divisão que funcionam

SPIDR — pico, caminho, interface, dados, regras — abrange a maioria das situações de divisão e é o primeiro lugar a se consultar. Existem alguns outros padrões que se repetem com frequência suficiente para que valha a pena mencioná-los.

Etapas do fluxo de trabalho

Uma história que abrange toda a jornada do usuário — cadastro, definição de preferências, confirmação de e-mail, visualização do painel — geralmente se divide de forma clara de acordo com os limites de cada etapa. Quando funciona, é a técnica mais clara do conjunto de ferramentas: cada história entrega um resultado reconhecível e visível para o usuário, cada uma pode ser demonstrada e cada uma pode ter seu escopo definido de forma independente.

O teste consiste em uma única pergunta, feita a cada etapa: o usuário se beneficiaria com isso se lançássemos apenas essa funcionalidade e nada mais? “Definir preferências” é aprovado — um usuário com preferências definidas, mas sem confirmação por e-mail, ainda está em um estado utilizável. “Enviar formulário” é reprovado — um usuário cujo envio não dá em nada fica em situação pior do que antes. Se a resposta for não, a etapa é uma subtarefa, não uma história, e o fluxo de trabalho não se divide nesse ponto.

A versão mais rápida do mesmo teste: cada etapa poderia entrar em produção ao longo de três sprints sem que nada mais mudasse, e ainda assim proporcionar uma experiência coerente em cada etapa? Se pular uma etapa fizer com que o usuário veja uma página com erros, a divisão é falsa. Essa é a armadilha em que as equipes de engenharia caem — as etapas correspondem à forma como o código se decompõe (serviço de autenticação, API de preferências, componente do painel), por isso parecem granulares. Elas são granulares. São também fatias horizontais com vocabulário de fluxo de trabalho sobreposto, e nenhuma delas entrega nada ao usuário. O indício: cada “etapa” é de responsabilidade de exatamente um especialista. Etapas reais do fluxo de trabalho atravessam a pilha, porque as etapas reais voltadas para o usuário fazem isso.

Variações nas regras de negócios

Uma história com várias regras ou funções — usuário comum, administrador, cliente de API — é dividida por regra. Implemente primeiro a regra mais comum; as variantes vêm em seguida. Cada variante é uma história de verdade, com seus próprios usuários.

Cenário favorável, depois cenário desfavorável

Intimamente relacionado ao conceito de Path do SPIDR. Priorize o caminho normal; o tratamento de erros, as tentativas de recuperação e os casos extremos vêm em seguida. O usuário pode ter sucesso mesmo antes que os modos de falha sejam totalmente tratados — desde que você aceite um comportamento de falha menos ideal nesse meio tempo e realmente retorne para lidar com isso posteriormente.

Qualidade diferida

Lance a versão sem os detalhes finais — sem dicas de ferramenta, sem animações, sem ajustes do administrador — e, em seguida, lance os detalhes finais como uma versão separada. Isso funciona se você realmente lançar os detalhes finais. Equipes que deixam a qualidade de lado e nunca voltam a ela acabam com funcionalidades incompletas para sempre.

Operações

Uma funcionalidade que envolve tanto um recurso para o usuário quanto questões operacionais (registro, monitoramento, alertas) se divide nessa linha. Lance primeiro a parte voltada para o usuário; a parte operacional vem em seguida e costuma ser mais rápida, pois o recurso já está em produção e as lacunas ficam visíveis.

O que não é uma divisão de verdade

“Front-end neste sprint, back-end no próximo” não é dividir — é adiar a entrega, porque nenhuma das duas partes é lançada sozinha. “Crie e depois escreva os testes” segue o mesmo princípio: código não testado é um risco, não uma divisão. Se uma parte do trabalho só tem valor depois que a parte correspondente for entregue, você não dividiu a história. Você apenas a agendou.

Quando uma matéria não puder ser dividida: publique-a na íntegra

Às vezes, o desconhecido é a própria dimensão — ninguém fez isso antes, a API do fornecedor não responde à questão da capacidade de suporte, ou o trabalho depende de uma métrica que ninguém possui ainda (p99 atual, volume de chamadas atual, formato dos dados atual). É nesse momento que você realiza um “spike”: uma investigação com prazo definido cujo resultado é conhecimento — um documento, um protótipo, uma recomendação, uma medição — e não código de produto pronto para lançamento. Você volta capaz de estimar a situação real com honestidade.

Os spikes são frequentemente mal utilizados com a mentalidade de “vamos simplesmente começar e ver o que acontece”. Isso não é um spike — é uma história sem estimativa, com etapas extras. Dois sinais de que você está usando a ferramenta errada: não há uma pergunta específica sendo respondida, ou o resultado esperado é “o recurso está pronto”. O primeiro significa que a equipe não está, na verdade, insegura; o segundo significa que se trata de uma história.

Se uma única etapa ainda não for suficiente, a matéria ainda não está pronta — trata-se de um projeto. Defina-o como tal, comunique o cronograma e pare de fingir que um sprint será suficiente para concluí-lo.

Perguntas frequentes

Como se divide uma história de usuário?

Divida verticalmente — com base nos resultados para o usuário, de modo que cada fatia abranja todas as camadas e entregue algo que o usuário possa usar, mesmo que lide apenas com um caso. O SPIDR oferece cinco linhas de divisão confiáveis: pico, caminho, interface, dados e regras. Escolha aquela que produzir uma fatia que você realmente lançaria.

O que você faz quando uma história de usuário é grande demais para um sprint?

Divida-a antes do início do sprint, de propósito. Uma história que não couber no sprint acaba sendo transferida de forma inadequada — o que sobra é justamente o que era mais difícil — ou entregue como um subconjunto incompleto. Ambas as opções são piores do que uma divisão vertical deliberada em partes, cada uma delas entregue separadamente.

Quando é que se deve dividir uma história em vez de estimá-la?

Quando a equipe não consegue encaixar a tarefa em um sprint, quando a variação nas avaliações é grande (um 3 ao lado de um 13), quando a resposta “depende” surge em mais do que algumas perguntas de refinamento, ou quando a história abrange mais de uma equipe. Uma grande variação não é uma discordância numérica — são duas histórias fingindo ser uma só.

O que é um “spike” ágil?

Um spike é uma investigação com prazo definido, realizada quando a equipe não consegue estimar o tamanho de uma história sem obter mais informações. O resultado é conhecimento — um documento, um protótipo, uma medição — e não código de produto pronto para lançamento. Duas coisas o tornam um spike, em vez de um trabalho sem prazo definido: um prazo e um resultado a ser entregue.

Quais são as formas mais comuns de dividir uma história de usuário?

Etapas do fluxo de trabalho, variações nas regras de negócios, caminho ideal e caminho não ideal, qualidade diferida e questões operacionais — além dos cinco critérios do SPIDR. O teste para todos eles é o mesmo: o usuário se beneficiaria se essa parte fosse lançada e nada mais fosse lançado?

Leituras relacionadas

• Estimativa ágil: o guia completo — o ponto central para tudo o que diz respeito a esse assunto.
• Divisão da história do SPIDR — as cinco linhas de corte confiáveis, em detalhes.
• Divisão horizontal x vertical — o princípio por trás de toda boa divisão.
• Definição de “pronto” — a etapa que uma história dividida precisa superar antes de voltar ao sprint.
• Aperfeiçoamento do backlog — a etapa em que a divisão realmente ocorre.