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, narrada 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 de má qualidade 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 está desempenhando 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 conversou. 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 à carta 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 sentido, 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 o funcionamento das histórias 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 tem espaço para conter um requisito completo, o que faz com que o próximo C aconteça.

A conversa é onde o requisito realmente se concretiza. A equipe e o proprietário do produto discutem a história 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 e nenhuma conversa, porque “já está escrito”.

A confirmação é o critério de aceitação: as condições de aprovação ou 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 mostra 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 junto com ele.
• 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.
• Valioso — a oração com “para que” resiste a um “por quê?” sincero.
• Estimável — a equipe consegue atribuir um valor a isso. Uma história cujo tamanho ninguém consegue estimar traz uma incógnita; execute um spike para descobri-la.
• Pequeno — cabe em um sprint com espaço de sobra. Se não couber, divida-o.
• Testável — é possível definir 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 “pequena” 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 na fase de INVEST que surge tardiamente: a história era negociável de maneiras que ninguém havia considerado, ou era grande demais para que alguém pudesse ter uma visão completa dela.

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!”) é perder o foco 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 decidir como alcançá-lo. Quando uma história chega com a solução já pré-definida, 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 alguns casos, não há “usuário” na frase:

• Trabalho aprofundado na plataforma. “Como desenvolvedor, quero atualizar a estrutura, para que a estrutura seja atualizada” não acrescenta nada ao que já está no título do ticket. Descreva-o como um trabalho técnico simples, com um resultado específico: o que pode parar de funcionar ou ficar mais lento se isso não acontecer, e o que fica mais fácil quando isso ocorre.
• Bugs com causa conhecida. Um relatório de defeito (comportamento esperado, comportamento real e etapas para reproduzir o problema) é uma forma 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 nos parâmetros de função, objetivo e 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, 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”. Basta manter esses elementos, e o formato já terá cumprido seu papel, mesmo nos casos em que não se aplique diretamente.

Onde as histórias se encontram com a estimativa

Uma história é a unidade de estimativa. Depois de escrita, ela segue este guia: a equipe a discute, estima seu tamanho em pontos de história usando o planning poker, verifica se ela está de acordo com a 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, e essa é a razão prática para se preocupar com o formato.

Para ver como 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 de 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 na perspectiva do usuário e o benefício é o argumento para que o trabalho seja programado. 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 todo 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, com aprovação ou reprovação, se o trabalho concluído atende ao que foi discutido.

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 formalidade 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.

Leituras relacionadas

• Estimativa ágil: o guia completo — o ponto central para tudo o que diz respeito a esse assunto.
• 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 histórias de usuário — o que fazer quando uma história não passa no “teste do pequeno”.