Divisão de user stories 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 você não consegue estimar geralmente é aquela que ainda não pode ser entregue, 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, em seguida, continua votando novamente para chegar a um consenso, em vez de se dividir.
• “Depende” responde a mais do que apenas 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 sobrou (o que é ruim, porque 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 propositalmente antes do início do sprint.

Por que uma grande diferença de 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 ela 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 sobre 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 o porte da consulta; outra está avaliando o porte da implantação.
• Uma pessoa sabe que a dependência existe; a outra, não.
• Uma pessoa está fazendo a avaliação para alguém que está na sala; o trabalho é de outra equipe.

Mais detalhes raramente resolvem isso: resultam em um ticket mais longo, não em 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. Duas cartas espalhadas não significam que a equipe discorda. Significa que a equipe está votando em histórias diferentes. Mande de volta.

Corte na vertical, não na horizontal

A divisão precisa ser vertical, não horizontal: uma fatia fina que seja realmente entregável por si só. “Backend primeiro, frontend no próximo sprint” divide a história da mesma forma que uma faca divide 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 se encontra 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. Entregue a regra mais comum primeiro; as variantes vêm em seguida. Cada variante é uma história de verdade, com seus próprios usuários.

Cenário ideal, depois cenário adverso

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 obter 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 volte a lidar com isso posteriormente.

Qualidade diferida

Lance a versão sem os ajustes finais (sem dicas de ferramentas, sem animações, sem alterações do administrador) e, em seguida, lance os ajustes finais como uma história separada. Isso funciona se você realmente lançar os ajustes finais. Equipes que negligenciam a qualidade e nunca voltam a trabalhar nisso acabam com funcionalidades incompletas de forma permanente.

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 estão 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 magnitude: 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. Ao concluir, você volta capaz de estimar o escopo real do projeto com honestidade.

Os spikes são frequentemente usados de forma equivocada, como se dissessem “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, na verdade, não está insegura; o segundo significa que se trata de uma história.

Se uma única etapa ainda não for suficiente, a histó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-o verticalmente, de acordo com os 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 trate apenas de 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á será transferida de forma inadequada (o que sobrar será justamente o que era mais difícil) ou lançada como um subconjunto incompleto. Ambas as opções são piores do que uma divisão vertical deliberada em partes, cada uma delas lançada separadamente.

Quando é que se deve dividir uma tarefa em partes, em vez de fazer uma estimativa dela?

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?

Leitura relacionada

• Estimativa ágil: o guia completo é o ponto central de tudo isso aqui.
• Divisão de histórias no SPIDR aborda em profundidade as cinco linhas de corte confiáveis.
• 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 a fazer parte do sprint.
• Aperfeiçoamento do backlog é o momento em que a divisão efetivamente ocorre.