Como escrever uma user story quando não é você quem constrói

Uma user story é a menor unidade de um briefing de desenvolvimento. Bem escrita, ela entrega o que você imaginou. Mal escrita, vira a fatura que você não esperava. Aqui está o formato, os quatro testes que separam uma story construível de uma armadilha, e um exemplo trabalhado.

Uma fundadora com quem trabalhei no ano passado aprovou uma story em uns quatro segundos. Ela dizia: “Como cliente, quero gerenciar minha conta.” Ela concordou, arrastou o card para a sprint e foi para uma call de vendas. Três semanas depois, o time de desenvolvimento voltou com uma conta pela página de conta: edição de perfil, redefinição de senha, configuração de dois fatores, histórico de cobrança, mudança de plano, exportação de dados, exclusão de conta. Tudo defensável. Tudo “gerenciar minha conta.” Nada do que ela tinha na cabeça, que era uma única tela onde o usuário pudesse trocar o e-mail.

Essa distância é o que uma user story deveria fechar, e é por isso que aprender como escrever uma user story importa mais para quem paga pelo desenvolvimento do que para os desenvolvedores que o fazem. Uma user story é uma frase que descreve algo que uma pessoa específica quer fazer com o seu software e por quê, pequena o suficiente para construir e verificar em poucos dias. O formato clássico, popularizado por Mike Cohn e pelos primeiros times de Extreme Programming, é: Como [tipo de usuário], quero [fazer algo], para que [eu obtenha algum benefício]. Esse é o template inteiro. O difícil não é a frase. É escrever uma que não se transforme silenciosamente em três semanas de trabalho que você nunca aprovou.

O que uma user story é, e o que não é

Uma user story não é uma especificação. Isso confunde fundadores vindos de finanças e consultoria, que esperam um documento fechando cada detalhe de antemão. A expressão de Cohn para uma story é “uma promessa de conversa.” O card é um marcador. Ele diz concordamos que isto vale ser construído e vale ser conversado, e confia que você e o time vão acertar os detalhes quando o trabalho chegar, não meses antes.

É o que chamam de “3 Cs”, que você vê citado em todo lugar: Card, Conversa e Confirmação (Card, Conversation, Confirmation). O card é a frase única. A conversa é onde você e o desenvolvedor descobrem o que a tela realmente faz. A confirmação é como vocês dois sabem que acabou, e a gente chega lá, porque é a parte que fundadores pulam e a parte que custa caro.

Então uma story é deliberadamente incompleta. Mas existe incompleta-de-propósito e incompleta-porque-é-vaga, e a diferença é o jogo inteiro. “Como cliente, quero gerenciar minha conta” não é uma pequena promessa de conversa. É uma área de funcionalidade inteira fantasiada de story única. O time pode precificar de um dia a um mês, e qualquer que seja a escolha, você vai se surpreender.

O template de user story, e as três partes que são de fato suas

Aqui está o formato de novo, preenchido direito:

Como comprador de primeira viagem, quero trocar o e-mail cadastrado na minha conta, para que eu continue recebendo atualizações de pedido depois de mudar de emprego.

Três campos. Como quem, quero o quê, para que por quê. Chamam o “quem/o quê/quando/onde/por quê” de os 5 Ws de uma story, mas você, como fundador, é dono só de três deles: para quem é, o que a pessoa tenta fazer, e por que importa. O quando e o onde pertencem à conversa com o time.

Os três campos não são enfeite. Cada um é uma alavanca:

O quem impede você de construir para um “usuário” genérico que não existe. Um comprador de primeira viagem e um usuário avançado que volta sempre querem coisas diferentes da mesma tela. Nomeie a pessoa real e metade da ambiguidade desaparece.

O o quê é uma única ação, não uma capacidade. “Trocar o e-mail” é uma ação. “Gerenciar as configurações da conta” é uma capacidade, e uma capacidade é um balde que segura uma dúzia de stories. Se o seu o quê contém a palavra “gerenciar”, “tratar”, “suportar” ou “e”, pare. Você tem mais de uma story.

O para que é a parte que todo mundo derruba, e a mais útil. Ela diz ao time por que você quer aquilo, o que permite propor um jeito mais barato de chegar ao mesmo resultado. Metade das vezes, a versão do desenvolvedor para o para que é melhor que a funcionalidade que você pediu. Você só descobre isso se escreveu.

Os quatro testes que separam uma story construível de uma armadilha

Times ágeis usam uma checklist chamada INVEST para isso. É boa, e foi escrita para quem executa. Aqui está a tradução para fundadores: as quatro perguntas que eu de fato faço antes de uma story entrar numa sprint que estou pagando.

Dá para construir e me mostrar sozinha? Uma boa story é uma fatia que atravessa o produto inteiro, não uma camada dele. “Construir o banco de dados das contas” é uma camada. Você não consegue ver, não consegue testar, não consegue dizer se está certo. “Trocar meu e-mail” atravessa o banco, a tela e o e-mail de confirmação de uma vez, e termina em algo que você pode olhar. Se uma story só faz sentido como parte de um pacote, ela ainda não é uma story.

É pequena o bastante para terminar em poucos dias? Não porque desenvolvedores não conseguem fazer coisas grandes, mas porque stories grandes escondem surpresas, e surpresas num orçamento fechado saem do seu bolso ou do seu prazo. Se você não consegue imaginar a coisa pronta dentro de uma semana, é um matacão. Divida. “Trocar meu e-mail” e “verificar o novo e-mail antes de valer” são duas stories, e precificá-las separadas protege você.

Eu poderia recusar na entrega? Essa é a que fundadores nunca pensam até ser tarde. Uma story que você não consegue reprovar é uma story que você vai pagar duas vezes. “Melhorar a experiência de checkout” nunca pode estar errada, o que significa que você nunca pode devolver. “Mostrar o total, incluindo frete, antes do botão de pagar” ou faz ou não faz. Escreva stories que você poderia recusar, e você mantém poder de barganha até a entrega.

É sobre o usuário, não sobre o encanamento? “Adicionar um cache Redis” é uma tarefa técnica, e tarefas técnicas são decisão do time, não sua. Suas stories descrevem o que alguém consegue fazer com o produto. Se você se pega escrevendo sobre bancos de dados, filas ou caches, você andou para o lado do desenvolvedor da mesa. Devolva e fique do seu.

Critérios de aceite: como uma story deixa de ser um desejo

Aqui é onde a aprovação de quatro segundos dá errado e onde você tem o retorno do seu dinheiro. A story é a promessa. Os critérios de aceite são a confirmação, a checklist que diz exatamente o que “pronto” significa, escrita antes do trabalho começar. É a diferença entre uma story que você torce para sair certa e uma que você consegue aceitar ou recusar de forma objetiva.

Para a story do e-mail:

• O usuário consegue abrir as configurações da conta e ver o e-mail atual.
• Trocar o e-mail envia um link de verificação para o novo endereço.
• O e-mail só muda de fato quando o link é clicado.
• Se o novo endereço já é usado por outra conta, o usuário vê um erro claro.
• E-mails de atualização de pedido vão para o novo endereço só depois da verificação.

Repare no que essas cinco linhas acabaram de fazer. Elas transformaram um desejo de uma frase em algo que o desenvolvedor pode precificar com exatidão e que você pode conferir linha por linha na entrega. Elas também trouxeram à tona uma decisão (o que acontece com um e-mail duplicado?) que de outro modo viraria uma pergunta no meio da sprint, ou pior, uma suposição silenciosa que você descobriria em produção. Critérios de aceite são baratos de escrever e caros de pular. A gente aprofunda isso no nosso texto sobre como escrever critérios de aceite que um fundador não técnico consegue de fato cobrar.

Um exemplo trabalhado: de um pedido vago a uma story que dá para entregar

Comece com o que fundadores de fato dizem num kickoff: “Quero que os usuários consigam convidar os colegas de time.”

Isso é uma capacidade, não uma story. É a armadilha do “gerenciar minha conta” com outra roupa. Passe pelos testes e ela se divide em stories, cada uma que você consegue ver, dimensionar e recusar:

Como dono da conta, quero enviar um convite por e-mail a um colega, para que ele entre no meu workspace sem eu compartilhar minha senha.

Como colega convidado, quero aceitar um convite e definir minha própria senha, para que eu tenha meu próprio login em vez de um compartilhado.

Como dono da conta, quero ver quais convites ainda estão pendentes, para que eu cobre os que não entraram.

Três stories onde havia uma linha. Cada uma é de poucos dias de trabalho, cada uma termina em algo que você pode olhar, e cada uma tem seus próprios critérios de aceite. Quando o time orça, você pode decidir que “ver convites pendentes” é desejável e cortar para bater um prazo. Você não conseguiria tomar essa decisão em “deixar usuários convidarem colegas”, porque não conseguia ver as costuras. Boas stories te dão costuras para cortar. É para isso que elas servem, na maior parte.

Stories assim não flutuam no ar. Elas ficam no seu product backlog, ordenadas pelo que importa, e sobem para o quadro maior que você definiu no seu documento de requisitos de produto. A story é o átomo. O backlog é a molécula. O documento de requisitos é o composto.

Escreva menos, escreva mais apertado

O instinto, quando você aprende o formato, é escrever quarenta stories num fim de semana e entregar uma pilha. Não faça. Uma pilha de stories vagas é pior que nenhuma, porque dá a todos uma falsa confiança de que o pensamento está pronto. Não está. Stories vagas são do que o scope creep é de fato feito: a expansão silenciosa de “gerenciar minha conta” em sete telas, descoberta uma fatura por vez.

Escreva as cinco ou seis stories da próxima fatia de trabalho. Faça cada uma passar nos quatro testes. Dê a cada uma critérios de aceite que você se sentiria confortável em cobrar. Depois converse sobre elas com quem constrói, porque o card sempre foi uma promessa de ter essa conversa. Faça isso e a story cumpre o seu papel de verdade, que não é documentação nem processo. É manter a coisa que é construída e a coisa que você imaginou na mesma sala.

Perguntas frequentes

Quais são os 3 Cs de uma user story?
Card, Conversa e Confirmação (Card, Conversation, Confirmation). O Card é a story de uma linha. A Conversa é a discussão entre você e o time sobre o que ela realmente significa. A Confirmação são os critérios de aceite que definem “pronto”. O formato vem de Ron Jeffries, um dos autores do Extreme Programming, e lembra que a frase é um ponto de partida, não o acordo inteiro.

O que é um exemplo de user story?
“Como comprador de primeira viagem, quero trocar o e-mail cadastrado na minha conta, para que eu continue recebendo atualizações de pedido depois de mudar de emprego.” Ela nomeia um usuário específico, uma única ação concreta e a razão por trás. Compare com “Como usuário, quero gerenciar minha conta”, que não nomeia ninguém, descreve uma área inteira de funcionalidade e não pode ser precificada nem recusada.

O que é um template de user story?
O template padrão é: Como [tipo de usuário], quero [fazer algo], para que [eu obtenha algum benefício]. Preencha os três campos. Se o campo do meio contém “e”, “gerenciar” ou “suportar”, você quase certamente tem mais de uma story e deveria dividir.

Quais são os 5 Ws em user stories?
Quem, o quê, quando, onde e por quê (who, what, when, where, why). Na prática, um fundador é dono de três: para quem é a story, o que a pessoa quer fazer e por que importa. O quando e o onde (qual tela, qual estado, qual caso de borda) se acertam na conversa com quem constrói, e ficam fixados nos critérios de aceite.

O que é a regra 3-5-3 no ágil?
Ela se refere à estrutura do Scrum: 3 papéis, 5 eventos e 3 artefatos. É sobre como um time de Scrum se organiza, não sobre como escrever uma story, então é uma pergunta diferente desta. Se você está contratando um desenvolvimento em vez de tocar o time você mesmo, o formato de story acima importa muito mais do que a contagem de cerimônias.