O que é uma história de usuário?

Uma história de usuário é uma descrição curta e em linguagem simples de uma mudança, contada da perspectiva da pessoa que se beneficia dela: “Como cliente recorrente, quero fazer login com meu e-mail para poder ver meu histórico de pedidos.” Ela não é, deliberadamente, uma especificação. O cartão representa a promessa de uma conversa, e os detalhes surgem quando a equipe refina a história, redige seus critérios de aceitação e avalia seu escopo.

Todo o restante deste guia gira em torno das histórias. São elas que o planning poker utiliza para dimensionar, às quais os story points se referem e que são divididas quando a estimativa não converge. Uma equipe que redige histórias ruins fará estimativas ruins, não importa o quão bem conduza a sessão, pois é nos dados de entrada que o problema começa.

O formato: função, objetivo, benefício

O formato clássico remonta à Connextra, uma equipe de XP de Londres, por volta de 2001:

Como [função], quero [objetivo], para que [benefício].

São três slots, e cada um deles desempenha uma função.

• A função indica quem recebe o valor. “Como usuário” é o erro mais comum nesse formato: uma história que poderia ser sobre qualquer pessoa é uma história com a qual ninguém realmente se identificou. Indique a pessoa específica: o cliente fiel, o desenvolvedor de integração.
• O objetivo é a capacidade do ponto de vista do usuário, descrevendo o que a pessoa faz, em vez de como o sistema é construído. “Quero redefinir minha senha” é um objetivo. “Quero um microsserviço de redefinição de senha” é uma decisão de projeto que assume essa forma.
• O benefício é a cláusula que as equipes definem primeiro, e é ela que garante ao cartão seu lugar no backlog. O “para que” é o argumento da história para que ela seja agendada. Se ninguém conseguir concluí-la, o trabalho não tem razão de ser, e escrever a cláusula é a maneira de descobrir isso antes do início do sprint, em vez de depois.

Cartão, conversa, confirmação

Ron Jeffries resumiu como as histórias funcionam em três Cs, e a ordem é importante.

O cartão é um símbolo: uma ou duas frases, propositalmente curtas. Seu tamanho é uma característica: ele fisicamente não pode conter um requisito completo, o que faz com que o próximo C ocorra.

A conversa é onde o requisito realmente se concretiza. A equipe e o proprietário do produto discutem a história detalhadamente durante o aperfeiçoamento do backlog: os casos extremos e o que está explicitamente fora do escopo. As equipes que pulam essa etapa e tratam o cartão como se fosse o requisito acabam ficando com o pior dos dois mundos: um documento muito superficial para servir de base para o desenvolvimento e nenhuma conversa, porque “já está escrito”.

A confirmação é o critério de aceitação: as condições de aprovação/reprovação que determinam se o trabalho concluído atende ao que foi acordado na conversa. O capítulo sobre o modelo de história de usuário apresenta os dois formatos que funcionam, e o capítulo sobre critérios de aceitação aborda em detalhes como redigi-los.

A lista de verificação do INVEST

A lista de verificação de Bill Wake, de 2003, continua sendo a maneira mais rápida de verificar se uma história está pronta para ser trabalhada. Uma boa história é:

• Independente: pode ser agendado por conta própria, sem precisar incluir outras três tarefas no sprint.
• Negociável: o cartão convida a uma conversa; o escopo ainda pode mudar. Uma história com todos os detalhes fixados é um requisito disfarçado de história.
• Valor: a oração com “para que” se sustenta diante de um “por quê?” sincero.
• Estimável: a equipe consegue quantificá-la. Uma história cujo tamanho ninguém consegue estimar traz uma incógnita; execute um spike para descobri-lo.
• Pequeno: cabe em um sprint com espaço de sobra. Se não couber, divida-o.
• Testável: é possível escrever critérios de aceitação que sejam aprovados ou reprovados. “A página parece mais rápida” é reprovado; “os resultados carregam em menos de um segundo” é aprovado.

“Estimável” e “pequeno” são os pontos em que as histórias se relacionam com o restante deste guia. Uma grande dispersão de votos no planning poker geralmente indica uma falha no processo de INVEST que só vem à tona mais tarde: a história era negociável de maneiras que ninguém havia considerado, ou era grande demais para que alguém pudesse enxergá-la por completo.

O que uma história de usuário não é

Não é uma tarefa. Uma história apresenta algo que o usuário pode ver; uma tarefa é um passo que a equipe dá para chegar lá. “Fazer login com e-mail” é uma história. “Configurar o armazenamento de sessões” é uma de suas tarefas. O capítulo sobre épico x história x tarefa aborda a hierarquia e explica por que os pontos pertencem exclusivamente ao nível da história.

Não é um documento de requisitos. Um requisito deve estar completo antes do início do trabalho. Uma história deve ser suficiente para dar início à conversa e nada mais. Avaliar histórias com base nos padrões de requisitos (“é muito vago!”) é ignorar o propósito do projeto: a imprecisão é um espaço reservado para o julgamento da equipe.

Não é uma promessa de implementação. A história define o resultado; a equipe é responsável por definir como isso será feito. Quando uma história chega com a solução já pré-determinada, a parte negociável do INVEST já não existe mais.

Quando as histórias de usuário não são a ferramenta adequada

O formato tem suas limitações, e fingir o contrário prejudica a credibilidade perante as pessoas que precisam escrever as frases mais complicadas. Em algumas frases, o usuário não aparece:

• Trabalho aprofundado na plataforma. “Como desenvolvedor, quero atualizar a estrutura, para que ela seja atualizada” não acrescenta nada ao que já consta no título do ticket. Descreva-o como um trabalho técnico simples, com um resultado específico: o que pode deixar de funcionar ou ficar lento se isso não acontecer, e o que ficará mais fácil quando acontecer.
• Bugs com causa conhecida. Um relatório de defeito (comportamento esperado, comportamento real e etapas para reproduzir o problema) é uma forma nativa mais adequada do que uma história adaptada posteriormente. O capítulo sobre pontos de história aborda quando os bugs recebem pontos.
• Picos de pesquisa. Um pico consiste em uma pergunta acompanhada de um intervalo de tempo definido, e seu resultado é o conhecimento. Forçar essa abordagem a se encaixar no modelo “função-objetivo-benefício” obscurece o que realmente importa: o que a equipe precisa aprender.
• Trabalho de conformidade. Não é possível negociar o escopo com um órgão regulador. A exigência é a exigência; registre-a como tal.

O que se aplica a todos esses casos é a disciplina, e não o formato da frase: uma razão clara pela qual o trabalho é importante e uma definição verificável do que significa “concluído”. Mantendo esses elementos, o formato já cumpriu seu papel, mesmo nos casos em que não se aplica diretamente.

Onde as histórias se encontram com a estimativa

Uma história é a unidade de estimativa. Depois de redigida, ela segue este guia: a equipe a discute, estima seu tamanho em pontos de história usando o planning poker, verifica se ela atende à definição de pronto e a divide caso a votação não chegue a um consenso. Uma história bem estruturada agiliza cada uma dessas etapas, o que é a razão prática para se dar importância ao formato.

Para ver o formato aplicado, o capítulo sobre exemplos de histórias de usuário apresenta dezesseis histórias comentadas, tanto boas quanto ruins. Para escrever a sua própria história, comece pelo modelo.

Perguntas frequentes

O que é uma história de usuário?

Uma história de usuário é uma descrição breve e em linguagem simples de uma mudança, narrada da perspectiva da pessoa que se beneficia: “Como cliente recorrente, quero fazer login com meu e-mail para poder ver meu histórico de pedidos.” Ela não é, deliberadamente, uma especificação. O cartão serve como ponto de partida para uma conversa, e os detalhes surgem quando a equipe refina e dimensiona o trabalho.

O que é o formato da história do usuário?

O formato clássico é função-objetivo-benefício: “Como [função], eu quero [objetivo], para que [benefício].” A função indica quem recebe o valor, o objetivo descreve a capacidade nos termos do usuário e o benefício é o argumento para que o trabalho seja planejado. Se ninguém conseguir completar a cláusula “para que”, a história não tem justificativa para estar no backlog.

Quais são os três Cs das histórias de usuário?

Cartão, conversa, confirmação. O cartão é um lembrete, deliberadamente pequeno demais para conter o requisito. É na conversa que o requisito realmente ganha vida, à medida que é refinado com a equipe. A confirmação são os critérios de aceitação que determinam se o trabalho concluído atende ao que foi discutido, seja com aprovação ou reprovação.

O que significa a sigla INVEST?

Independente, negociável, valiosa, estimável, pequena, testável. Essa é a lista de verificação de Bill Wake para determinar se uma história está pronta para ser trabalhada. Na prática, os três últimos itens têm maior peso: uma história que a equipe não consiga estimar, que não caiba em um sprint ou que nenhum teste consiga confirmar é uma história que ainda não está pronta.

Quando não se deve usar histórias de usuário?

Quando o formato acrescenta formalidades em vez de clareza. Trabalhos aprofundados na plataforma, correções de bugs com causa conhecida, requisitos de conformidade e picos de pesquisa têm, todos, formas nativas mais adequadas. Mantenha a cláusula de benefício e os critérios de aceitação; evite o clichê “como desenvolvedor, eu quero” quando não houver nenhum usuário na frase.

Leitura relacionada

• Estimativa ágil: o guia completo. O centro de informações sobre tudo o que há aqui.
• Exemplos de histórias de usuário: dezesseis histórias comentadas, incluindo aquelas que dão errado e os motivos para isso.
• Modelo de história de usuário e critérios de aceitação: o modelo, suas variantes e um exemplo prático, incluindo a estimativa.
• Épico x história x tarefa: onde a história se encaixa na hierarquia e qual nível é destacado.
• Divisão de user stories: o que fazer quando uma história não passa no “pequeno teste”.