Histórias de usuário (user stories)
Descreva o que construir como necessidades pequenas e testáveis, escritas do lado do usuário, para a equipe construir a coisa certa e saber quando terminou.
- Tempo
- 45 min
- Pessoas
- 3–6
- Tipo de trabalho
- Planejar
Em resumo
A história de usuário é uma frase curta sobre uma necessidade do usuário, escrita como "Como [usuário], eu preciso de [algo], para que [motivo]", com critérios de aceite que dizem quando ela está pronta. Para escrevê-las, parta da pesquisa, agrupe as histórias relacionadas em épicos, divida as grandes e combine os critérios com quem vai construir e testar.
O que é
A história de usuário descreve um trabalho do ponto de vista de quem vai usá-lo, e não como uma tarefa técnica. Ela tem três partes: quem é o usuário, do que ele precisa e por que precisa. A parte "para que" é a mais importante, porque diz à equipe que problema o trabalho resolve e permite que ela sugira um jeito melhor de resolvê-lo. Cada história traz critérios de aceite: uma lista curta de condições que precisam ser verdadeiras para a história contar como pronta.
As histórias de usuário vêm da prática ágil de software e foram usadas pela primeira vez no Extreme Programming, no fim dos anos 1990. Hoje são padrão em equipes de serviços digitais, inclusive no governo. O GOV.UK Service Manual usa a formulação "eu preciso" em vez de "eu quero", para manter o foco em necessidades reais. Histórias grandes, que cobrem um objetivo inteiro, são chamadas de épicos e são divididas em histórias menores que podem ser construídas e testadas em pouco tempo. Nesta planilha você registra o usuário, a necessidade, o motivo, os critérios de aceite, o épico a que ela pertence e a evidência por trás.
Quando usar
Use quando
- Você terminou a pesquisa e o desenho e precisa transformá-los numa lista de trabalho que uma equipe de entrega consiga construir.
- Um documento de requisitos é longo e técnico, e ninguém sabe dizer quais partes mais importam para os usuários.
- Você está planejando a primeira versão de um novo serviço e precisa combinar o que entra e o que pode esperar.
- As equipes de negócio, de políticas e de tecnologia descrevem o mesmo serviço com palavras diferentes e vivem se desentendendo.
- Você precisa de condições claras para os testes, para que todos concordem quando uma funcionalidade está pronta.
Evite quando
- Você ainda não sabe quem são seus usuários nem do que precisam. Faça pesquisa antes, ou as histórias vão descrever palpites.
- O trabalho é puramente técnico, sem mudança visível para o usuário, como atualizar um banco de dados. Uma descrição simples da tarefa é mais clara.
- Você ainda está explorando ideias muito diferentes. As histórias fixam detalhes cedo demais; use antes um storyboard ou um protótipo.
Do que você precisa
- Tempo
- Cerca de 45 minutos para rascunhar e revisar as histórias de um épico; mais para um serviço inteiro.
- Pessoas
- De 3 a 6 pessoas: um responsável pelo produto ou serviço, alguém da pesquisa e pelo menos uma pessoa que vai construir e uma que vai testar.
- Materiais
- Achados de pesquisa ou um mapa de experiência, fichas ou um quadro compartilhado e um modelo simples com os seis campos da planilha.
Como aplicar
Passo 1: Parta do objetivo do usuário
Escreva no topo do quadro o objetivo geral de um grupo de usuários, por exemplo "um segurado pede a aposentadoria". Esse vai ser o épico. Fixe ao lado a pesquisa relevante, como falas, um mapa de experiência ou uma declaração de ponto de vista, para as histórias continuarem ligadas à evidência.
Passo 2: Nomeie os usuários com precisão
Liste os tipos de usuário envolvidos no objetivo, em palavras simples: "um segurado que se aposenta este ano", "o empregador do segurado", "um servidor da previdência". Evite "como usuário" e "como sistema"; eles escondem de quem é a necessidade. Servidores também são usuários e ganham as próprias histórias.
Passo 3: Rascunhe as histórias
Peça a cada pessoa que escreva histórias em fichas separadas no formato "Como…, eu preciso…, para que…". Escreva a necessidade nos termos do usuário, não como uma tela ou um botão: "eu preciso saber quais documentos enviar" em vez de "eu preciso de uma página de envio de documentos". Mire em uma necessidade por ficha.
Passo 4: Confira o "para que"
Leia cada ficha em voz alta e pergunte se o motivo é real e específico. "Para que eu possa fazer o pedido" não acrescenta nada. "Para que meu primeiro pagamento não atrase" diz à equipe como é o sucesso. Se ninguém souber dizer por que o usuário precisa daquilo, tire a ficha ou marque-a como premissa a conferir.
Passo 5: Divida as histórias grandes
Se uma história levaria mais que alguns dias para uma equipe construir e testar, divida-a. Boas formas de dividir são por tipo de usuário, por passo da jornada, por casos simples e complexos, ou pelo caminho principal primeiro e as exceções depois. Mantenha as histórias divididas sob o mesmo épico.
Passo 6: Escreva os critérios de aceite
Para cada história, combinem de três a seis condições que precisam ser verdadeiras quando ela estiver pronta, escritas de forma que um testador consiga conferi-las. Um padrão útil é "Dado [situação], quando [ação], então [resultado]". Inclua os caminhos de erro, como um documento faltando ou um número errado, e não só o principal.
Passo 7: Ordene e registre
Organize as histórias sob o épico na ordem em que os usuários as encontram e marque quais são necessárias para a primeira versão. Registre cada história com sua evidência e seus critérios no backlog da equipe e combinem quem vai revisar as histórias com a equipe de pesquisa antes de a construção começar.
Exemplo prático
Um fundo público de previdência recebia cerca de 3.400 pedidos de aposentadoria por mês, quase todos em papel. Os pedidos levavam em média 47 dias para ser processados, e 38% eram devolvidos ao segurado pelo menos uma vez por informação faltando ou errada. O fundo planejava um serviço online e tinha um documento de requisitos de 400 páginas que a equipe de entrega achava difícil de usar.
Cinco pessoas se reuniram por 45 minutos: a responsável pelo serviço, um pesquisador de usuários, uma servidora da previdência, um desenvolvedor e uma testadora. Pegaram o épico "um segurado pede a aposentadoria" e colocaram ao lado falas das entrevistas e o mapa de experiência.
Listaram quatro usuários: um segurado que se aposenta este ano, o empregador do segurado, um servidor da previdência e um familiar designado pelo segurado. O primeiro rascunho gerou 26 fichas de história.
Conferir o "para que" eliminou quatro fichas que só repetiam o passo. Também transformou "Como segurado, eu preciso enviar minha certidão de tempo de serviço" em "Como segurado que se aposenta este ano, eu preciso saber que meu empregador já confirmou minhas datas de serviço, para que eu não precise ir atrás de uma certidão sozinho".
A história sobre o cálculo da aposentadoria era grande demais. A equipe a dividiu em três: segurados com um empregador, segurados com vários empregadores e segurados com lacunas nas contribuições, e marcou só a primeira para a versão um.
Os critérios de aceite da história das datas de serviço incluíam "Dado que o empregador confirmou as datas, quando o segurado entra no sistema, então as datas aparecem e podem ser aceitas" e "Dado que as datas estão faltando, quando o segurado entra no sistema, então ele vê com quem falar e o caso é sinalizado para um servidor".
O backlog final do épico tinha 18 histórias, 11 delas marcadas para a primeira versão. A equipe agendou uma revisão com o pesquisador antes da primeira sprint.
IlustrativoDicas e erros comuns
Dicas
- Escreva a necessidade como algo que o usuário quer alcançar, não como uma funcionalidade. Isso deixa espaço para a equipe encontrar uma solução mais simples.
- Mantenha as histórias pequenas o bastante para construir e testar dentro de uma sprint ou de uma semana. Histórias grandes escondem risco.
- Escreva histórias também para os usuários internos. Os servidores que processam os casos têm necessidades que moldam o serviço inteiro.
- Ligue cada história à evidência por trás dela, para qualquer pessoa conseguir conferir de onde veio a necessidade.
Erros comuns
- Escrever "Como usuário" em tudo, o que esconde as necessidades diferentes de pessoas diferentes.
- Transformar uma tarefa técnica em história acrescentando "Como sistema", o que anula o propósito do formato.
- Deixar de fora os critérios de aceite, e cada um, equipe e testadores, decide o que significa pronto.
- Escrever o backlog inteiro sozinho numa mesa e entregá-lo pronto, em vez de rascunhá-lo e conferi-lo com a equipe.
O que você leva
Você sai com um épico dividido em pequenas histórias de usuário, cada uma nomeando o usuário, a necessidade e o motivo, com critérios de aceite, um link para a evidência e uma marca para a primeira versão. As histórias vão direto para o backlog da equipe de entrega. Um roadmap ajuda a sequenciar os épicos ao longo do tempo, e um storyboard pode mostrar como as histórias formam uma única experiência.
Perguntas frequentes
Por que o GOV.UK usa "eu preciso" em vez de "eu quero" nas histórias de usuário?
"Eu preciso" mantém o foco no que os usuários precisam conseguir fazer para chegar ao resultado, e não em preferências. Isso leva as equipes a pedir evidências de que a necessidade é real. Muitas equipes fora do governo usam "eu quero"; a estrutura da história é a mesma.
Qual a diferença entre épico e história de usuário?
O épico é um objetivo grande do usuário, como pedir a aposentadoria, grande demais para construir de uma vez. A história de usuário é uma parte pequena desse objetivo que uma equipe consegue construir e testar em poucos dias. Um épico normalmente reúne várias histórias, às vezes dezenas.
Quantos critérios de aceite uma história de usuário deve ter?
Em geral, de três a seis. Menos pode indicar que a história está vaga ou que os caminhos de erro ficaram de fora. Muito mais que isso costuma indicar que a história é grande demais e deve ser dividida.
Ficha da ferramenta
A planilha que sua equipe preenche, um quadro por campo.
- Usuário
- Necessidade
- Para que
- Critérios de aceite
- Épico
- Evidência