O que são Histórias de Usuário?
História de Usuários são os itens de uma Product Backlog que descrevem partes do produto a ser desenvolvido. Por outro lado, a Product Backlog é lista dessas histórias representando tudo que será desenvolvido ao longo do tempo. Quando você criar histórias de Usuário, para cada História, lembre-se que ela precisa ser simples mas com detalhes suficientes. Você precisa tomar cuidado com excesso para não transformar a história de usuário em uma especificação técnica. O foco deve estar sempre na necessidade do usuário.
A Importância da User Story no Desenvolvimento Ágil
Embora as histórias de usuário não sejam parte formal do Scrum — que é um framework ágil e não uma metodologia —, o uso das User Stories tem se tornado uma prática amplamente adotada por equipes ágeis. Quando bem elaboradas pelo Product Owner, as histórias de usuário ajudam a manter o foco no que é mais importante: as necessidades e expectativas do usuário. Essa prática é tão eficaz que se tornou um padrão comum em muitos times que utilizam metodologias ágeis.
Um dos maiores benefícios das histórias de usuário é a sua flexibilidade. Diferentemente de abordagens tradicionais, como Waterfall, onde todos os requisitos são definidos de antemão, as histórias de usuário podem ser ajustadas e evoluir conforme o produto avança. Essa adaptabilidade permite que o desenvolvimento ágil responda rapidamente a mudanças, mantendo o foco no valor do negócio.
Como Criar Histórias de Usuário de Forma Eficiente
Criar histórias de usuário de qualidade exige atenção, mas não é uma tarefa que demanda conhecimento técnico profundo. Elas não devem ser curtas demais, como um simples recado, nem longas e detalhadas como uma especificação técnica. Evite incluir diagramas técnicos, como UML, nas histórias de usuário. O objetivo é capturar a necessidade de negócio e a essência do que deve ser implementado.
Há uma recomendação amplamente difundida que merece destaque: o uso das seis características do acrônimo INVEST para garantir a qualidade das histórias de usuário. Esse acrônimo representa:
- Independente: As histórias devem ser independentes para evitar dependências entre elas.
- Negociável: As histórias não devem ser contratos rígidos, mas sim flexíveis e negociáveis.
- Valiosa: A história deve agregar valor ao negócio.
- Estimável: A história precisa ser pequena o suficiente para que a equipe possa estimar o esforço.
- Small (Pequena): Quanto menor a história, mais fácil será de implementar e testar.
- Testável: A história deve permitir a criação de critérios claros de aceitação que possam ser testados.
Seguir o INVEST ao criar histórias de usuário ajudará a manter o backlog organizado, com histórias claras e bem definidas. Isso facilita tanto o entendimento pela equipe quanto a priorização pelo Product Owner.
Adotar essa técnica junto ao Example Mapping tornará possível criar histórias de alta qualidade.
Exemplo de Estrutura para Histórias de Usuário
Veja abaixo alguns exemplos práticos de como criar histórias de usuário de maneira eficiente. “Como um [tipo de usuário], quero [ação] para [objetivo/motivação]“.
- Como a/o/um | Sendo a/o <pessoa simulada>
- Quero | Devo | Preciso | Gostaria de <ação, o que se faz, a necessidade na história>
- Porque | Para <Motivação dessa necessidade – Porque você precisa, quer ou deve?>
Por exemplo, para um blog:
- “Como um usuário do blog devo me autenticar de forma padrão para conseguir comentar uma postagem”
- “Como um usuário que faz postagem devo me autenticar como editor para conseguir postar um novo artigo”
E, em um site de vendas de veículos:
- “Como um usuário interessado devo me cadastrar no site para criar um anúncio de venda de veículo”
- “Como um usuário cadastrado preciso me autenticar no site para editar os dados do anúncio”
- “Como um usuário autenticado gostaria de anexar uma ou mais fotos de um veículo para serem exibidas como parte do anúncio”
- “Sendo o usuário proprietário de um anúncio gostaria de selecionar uma foto do veículo para exibir como destaque no anúncio”
- “Sendo o usuário proprietário de um anúncio quero uma maneira para destacar o anúncio porque espero ter maiores chances de vender o veículo”
Você percebeu que se sabemos o que se deseja e o seu “porquê” (sua motivação), então temo um indicativo de valor para o negócio? Por isso, também será possível testar cada necessidade e o cliente saberá como fazer isso. Quando o cliente ainda não sabe como testar é porque a história não está clara o suficiente e talvez o “porquê” (a motivação) e há alguma confusão ali. Pode ser que ainda não esteja agregando valor! e se esse for o caso, não faz sentido existir. Portanto, para agregar valor é necessário captar a “ideia”, a “essência” da coisa, e não um monte de detalhes para uma feature.
Histórias devem ser objetivas
É importante, especialmente para programadores ou profissionais com habilidades técnicas, evitar discutir detalhes de implementação durante a criação das histórias de usuário. O momento de criar histórias é voltado para capturar a necessidade do usuário, e não para decidir aspectos técnicos, como o layout da interface ou a tecnologia a ser usada.
Ao criar histórias de usuário, o foco deve ser sempre na necessidade de negócio e não em uma visão técnica de como a equipe vai implementar a solução. Evite discussões sobre ícones, componentes específicos ou tecnologias, que podem ser resolvidas mais tarde.
Observe que, nos exemplos anteriores, conseguimos especificar necessidades independentes, o que é uma das partes mais desafiadoras. Com histórias independentes, o time pode implementar uma feature a qualquer momento e em qualquer ordem, sem a necessidade de encadear histórias ou seguir uma sequência fixa. Isso evita bloqueios no processo, já que não será necessário concluir uma história para começar outra, o que poderia causar gargalos e prejudicar a entrega da Sprint. Se esse tipo de bloqueio acontecer, pode ser que duas ou mais histórias sejam redundantes.
As histórias ficaram objetivas e pequenas, mas ainda contêm detalhes suficientes para capturar a essência do que se espera na implementação das features. Além disso, ao expressar os desejos do usuário, elas se tornam negociáveis. Mesmo sendo curtas, fornecem uma base sólida para estimativas, permitindo que a equipe avalie com precisão o esforço necessário. Histórias curtas facilitam estimativas mais precisas, pois o time entende claramente o que se espera, evitando suposições sobre o tempo de implementação. É essencial ser capaz de estimá-las corretamente, sem “chutes”.
Desmembrando as Histórias de Usuário
Uma vez que as histórias de usuário tenham sido criadas, o próximo passo é desmembrá-las para obter uma visão mais clara e detalhada da necessidade do usuário. Desmembrar histórias ajuda a criar cenários de teste mais precisos e a identificar requisitos adicionais.
Uma técnica eficaz para isso é o Example Mapping. Trata-se de uma reunião com foco em uma única história de usuário, com um tempo fixo e curto, geralmente entre 25 e 30 minutos. Idealmente, essa reunião deve incluir de 3 a 5 pessoas que representem o negócio. Durante a reunião, a equipe desmembrará a história, definindo regras e critérios de aceitação. Se surgirem novas histórias, elas devem ser anotadas e tratadas em uma reunião futura, evitando desviar o foco do tema principal.
Testando as regras de aceitação
Podemos aplicar exemplos de testes para cada regra, incluindo um cenário, a ação do usuário e o resultado esperado. Dessa forma, a história se torna testável, e isso serve como base para a criação de testes automatizados, embora ainda não os defina por completo. No entanto, ao adicionar detalhes técnicos nesse estágio, o time pode acabar desviando o foco para discussões desnecessárias, envolvendo pessoas que não estão tecnicamente preparadas. Por isso, é essencial manter o foco no que realmente importa para o negócio, evitando entrar em detalhes técnicos.
A técnica de example mapping também sugere o uso de cartões ou post-its coloridos, cada um com seu objetivo. De preferência, a equipe deve padronizar as cores. Isso evitará confusões, principalmente porque chegará um momento em que a cor estará ligada a ideia ali aplicada.
Escolha uma das cores para conter a User Story, e logo em seguida outra cor que representará uma regra de aceitação. Descreva apenas uma regra de aceitação por cartão ou post-it! E daqui a pouco virão exemplos, não se preocupe! 🙂
Quando tivermos uma regra de aceitação, teremos então definido obviamente um critério de aceitação. Isso é redundante mas esclarece o ponto! E se você têm um critério de aceitação, pode aplicar cenários de testes para identificar resultados de sucesso e insucesso. Logo, poderemos eleger outra cor de cartão ou post-it para definirmos cada exemplo.
Mas, durante a reunião, poderão surgir questionamentos válidos sobre a história, a regra ou o exemplo. Sendo assim, mais uma vez poderemos eleger uma nova e quarta cor para indicar os questionamentos que ficarão documentados.
Escrevendo as regras
Um padrão interessante para ajudar a criar história de usuários com clareza, é por utilizar cores: amarelo para User Story, azul para Regras, verde para Exemplos e Vermelho/Rosa para Questionamentos. O Cucumber propôs esse padrão de cores. (https://cucumber.io/blog/example-mapping-introduction/)
Então para iniciar o entendimento da ideia, vamos tomar uma história como exemplo:
“Como um usuário interessado devo me cadastrar no site para criar um anúncio de venda de veículo”
Exemplos de regras aqui seriam:
“Dados obrigatórios devem ser informados tais como nome, e-mail”
“Uma senha complexa deve ser provida com letras, números e ao menos 8 caracteres”
Estas regras poderiam estar, cada uma, descrita em um cartão azul. Tendo estas regras provido critérios de aceitação, podemos prover exemplos correspondentes.
Antes de começar a escrever, talvez você deva pensar em acontecimentos aproximados. Para isso, também há uma convenção amigável sugerida, partindo da ideia: “The one where …”, ou seja , “Aquele onde/em que …”. Note abaixo:
- Aquele em que o usuário cadastrado esquece de informar seu nome de usuário.
- Aquele onde o usuário cadastrado informa uma senha com apenas números.
Veja que raciocínio interessante em uma reunião! Daí, para descrever um exemplo, considere prover: contexto, ação e resultado esperado.
Envolvendo em um cenário
Você vai perceber uma sintaxe muito parecida com: Give … when … then… Mas não se prenda rigorosamente a essa estrutura. Apenas note os exemplos:
Para um “caminho feliz”:
- Para dados obrigatórios
- usuário informa dados válidos e quando e submete formulário
- Resulta: Ok! Cadastro efetivado com sucesso
Para um “caminho triste”:
- Para dados obrigatórios
- usuário esquece de informar um dos dados e quando submete formulário
- resulta: Falha! Dados incorretos
Ou:
Para um “caminho feliz”:
- Para senha complexa
- usuário informa uma senha 1234abcd e quando submete formulário
- Resulta: Ok! Cadastro efetivado com sucesso
Para um “caminho triste”:
- Para senha complexa
- usuário informa uma senha 12345678 e quando submete formulário
- Resulta: Falha! Senha não atende os requisitos de complexidade
Vale dizer que, o Cucumber (https://cucumber.io/) provê ferramentas para a documentação de example mapping e sem dúvida será interessante para documentar o que ocorreu na reunião, talvez utilizando até uma sintaxe Gherkin. Mas não se apegue a nada disso durante a reunião pois, poderá intimidar os usuários ou gastar muito tempo valioso apenas no entendimento de algo desnecessário para o momento.
Mas e se por algum motivo aparecerem dúvidas? Como já mencionei, a equipe pode usar um cartão vermelho/rosa para isso. Talvez, nessa mesma linha de raciocínio sobre o cadastro, um questionamento seria:
“O e-mail cadastrado para o usuário deverá ser único?”
Dependendo da resposta do cliente, poderá surgir aqui uma nova regra de aceitação. Mas outro questionamento seria:
“Será preciso confirmar o e-mail do usuário?”
Note que neste caso, poderemos ter uma nova história de usuário.
Mesmo com exemplo, tenho certeza de que estes principios e métodos serão válidos para todos os cenários, desde o mais simples, até os mais complexos.
Conclusão
Criar histórias de usuário com qualidade é uma prática fundamental no desenvolvimento ágil. Embora o Scrum não exija formalmente o uso de User Stories, essa técnica se tornou uma ferramenta poderosa para organizar e descrever o backlog de maneira clara e objetiva. Utilizando métodos como o INVEST e o Example Mapping, você garante que as histórias de usuário sejam independentes, negociáveis, valiosas, estimáveis, pequenas e testáveis.
Além disso, ao focar diretamente nas necessidades reais do usuário e evitar inserir detalhes técnicos desnecessários, você facilita a comunicação entre o time de desenvolvimento e o cliente. Com isso, assegura que o produto entregue atenda exatamente às expectativas e requisitos. Histórias de usuário bem elaboradas permitem melhor estimativa de esforço, flexibilidade na implementação e, sobretudo, entregas mais ágeis e com maior valor agregado.
Em resumo, ao criar histórias de usuário de forma eficaz, você melhora a agilidade do processo, alinha o time com os objetivos do cliente e evita gargalos durante o desenvolvimento. Embora pareça simples, essa prática exige atenção aos detalhes e uma compreensão profunda das necessidades do negócio. Com essas abordagens, o desenvolvimento se torna mais eficiente e orientado para resultados concretos.