História de usuário a partir de uma entrevista: modelo e critérios de aceitação
Aprenda a escrever uma história de usuário com base no relato de um cliente: identifique a necessidade, preserve a fonte e acrescente critérios de aceitação. Inclui exemplo e modelo.
Uma história de usuário descreve o benefício para a pessoa
Uma história de usuário descreve brevemente o resultado desejado do ponto de vista de quem vai usar o produto. Um formato comum é «Como [papel], quero [ação] para [benefício]». Ele ajuda a iniciar a conversa sobre a necessidade. Os requisitos e a verificação do resultado ainda precisam ser definidos.
A fala «adicionem um botão verde» propõe uma solução. Para escrever a história, descubra o que a pessoa tenta fazer e o que atrapalha no caminho atual. Guarde a fala original para verificar sua interpretação.
Como usuário, quero um botão grande de exportação que seja fácil de usar.
Como coordenador de projeto, quero compartilhar pontos selecionados da reunião com um colega para que ele receba apenas os combinados que lhe dizem respeito.
Como escrever uma história a partir de uma entrevista
Escolha um episódio concreto
Procure o relato da última situação real. Quem agiu, com qual material e para obter o quê? Uma frase genérica como «todo mundo precisa de relatórios» não sustenta uma história separada.
Registre a fala exata e o contexto
Guarde a marca de tempo e algumas frases próximas. Separe as palavras da pessoa da sua conclusão. Se ela descreveu uma exceção, trate-a como tal.
Formule o papel, a ação e o benefício
O papel deve explicar a situação, indo além do rótulo «usuário». A ação deve ser observável e o benefício deve explicar por que ela importa para a pessoa.
Verifique o escopo
Uma história deve abranger um resultado útil e completo que possa ser discutido e verificado separadamente. Evite incluir todo o percurso do cadastro ao relatório anual.
Acrescente critérios de aceitação
Registre as condições que permitem verificar se o comportamento desejado foi implementado. Inclua o caso principal e uma exceção importante. Valide os critérios com a equipe antes de tratá-los como requisitos.
Leve as questões em aberto de volta à discussão
Se as permissões, o volume de dados ou o formato do resultado ainda forem desconhecidos, registre a pergunta. Evite preencher a lacuna com a solução mais comum.
Da fala do coordenador ao cartão da história
Depois da chamada, envio ao desenvolvedor só as tarefas da parte dele. Hoje copio tudo à mão e tenho medo de levar junto comentários internos.
O exemplo se refere a um sistema fictício de notas e não descreve funções atuais do Transkribator. A necessidade é enviar um trecho selecionado sem informações extras. A cor de um eventual botão é uma decisão de design.
História. Como coordenador de projeto, quero reunir pontos selecionados da reunião em um texto separado para enviar à pessoa responsável apenas os combinados que lhe dizem respeito.
Critérios propostos. Se três pontos forem selecionados, o resultado contém exatamente esses três. Antes de enviar, o coordenador vê o texto completo. Se nenhum ponto for selecionado, o sistema explica que é preciso escolher itens.
Questão em aberto. O texto deve incluir marcas de tempo? Isso não foi discutido na entrevista. Vamos esclarecer na próxima conversa antes de incluir a condição como requisito.
A história tem uma fonte, mas sua importância para a maioria dos clientes ainda precisa ser confirmada. Uma gravação mostra uma experiência. Defina a prioridade considerando outras evidências, os objetivos do produto e o custo de implementação.
Como distinguir uma história de uma lista de tarefas técnicas
«Criar uma tabela no banco» ou «adicionar um manipulador de eventos» são tarefas técnicas. Elas podem fazer parte da implementação, mas não explicam o benefício para a pessoa. Uma frase bem escrita também não garante que a equipe entenda todas as restrições.
Conte a história a uma pessoa de testes sem mencionar um componente da interface. Se for impossível descrever o que a pessoa faz antes e depois, volte à entrevista. Teste também os casos de falha: sem dados selecionados, com permissões insuficientes ou em uma nova tentativa. Inclua só as exceções essenciais para esta história e evite transformar o cartão em uma especificação de todo o produto.
Cartão com fonte e questões em aberto
Título da história: Papel e situação de trabalho: Como [quem], quero [ação] para [benefício]. Fonte: entrevista / data / marca de tempo: Fala original: Nossa interpretação: Critérios de aceitação: 1. Dada [condição], a pessoa pode [ação] e obtém [resultado]. 2. Se [exceção importante], ocorre [comportamento esperado]. Fora do escopo da história: O que falta esclarecer: Quem confirmou a formulação e quando:
- O papel é específico e o benefício é claro.
- A fala original está separada da solução da equipe.
- Os critérios podem ser verificados por observação.
- As perguntas continuam explícitas.
Veja os detalhes
É sempre preciso escrever «Como… quero… para…»?
A fórmula é um ponto de partida. O essencial é que a equipe entenda quem é a pessoa, o que quer fazer e por quê.
Quantos critérios de aceitação são necessários?
O suficiente para cobrir o cenário principal e as exceções relevantes. Se os critérios descrevem resultados independentes, talvez valha a pena dividir a história.
Posso criar uma história a partir de uma única entrevista?
É possível formular uma hipótese e indicar a fonte. Isso não comprova a necessidade em todo o segmento nem justifica automaticamente o desenvolvimento.