User story: saiba o que é e como escrever as histórias de usuários
User stories ou, em português, histórias de usuários, fazem parte de uma estrutura ágil e explicação informal que ilustra o recurso do software na perspectiva do usuário final ou cliente.
Publicado em 9 de novembro de 2021
User stories ou, em português, histórias de usuários, fazem parte de uma estrutura ágil e explicação informal que ilustra o recurso do software na perspectiva do usuário final ou cliente. Um dos objetivos das histórias é mostrar como uma tarefa entregará determinado valor ao usuário.
Se você não sabe como escrever as suas histórias, este artigo é exatamente o que você precisa. Nas próximas linhas, eu te explico como documentar as user stories da melhor maneira. Vem comigo!
Glossário
O que são user stories e por que usar as histórias de usuários?
As histórias de usuários fazem parte do desenvolvimento Agile. Com elas, seus usuários ficam no centro das ações que serão adotadas no seu produto. Além de priorizar os clientes, as stories são úteis para estimar o esforço necessário para realizar os objetivos propostos.
Uma vez documentadas, o time de desenvolvimento sabe o porquê precisa desenvolver. É uma maneira de dar visão para que a equipe consiga enxergar valor na execução.
Como escrever as histórias de usuários?
A primeira coisa que você precisa saber é que as histórias de usuários devem ser simples e objetivas. Se as suas histórias forem longas a ponto de não caber um quadro, por exemplo, é preciso refiná-las.
Basicamente, as user stories são descrições sobre a funcionalidade do seu produto e, por essa razão, é importante que elas representem verdadeiramente o ponto de vista do usuário. Para escrever as histórias de usuários, a minha recomendação é documentá-las em três blocos, da seguinte maneira:
1. Entrega de valor
Para começar, você deve relacionar as user stories a uma entrega de valor. Ou seja, a razão pela qual essas histórias são importantes. Responda: a qual North Star/OKR/Business Goal essa história está conectada?
Exemplo: 80% dos usuários ativos da “Empresa XPTO” estão engajando com nossos produtos ao final de Q2. Como auxílio, você pode utilizar o modelo do método Scrum at Scale para definir a fonte de valor.
Na descrição da documentação, é preciso colocar o objetivo da funcionalidade em “Valor de Mercado”, “Redução de Risco” ou “Aumentar a Capacidade” e qual é o detalhe, seguindo os exemplos do quadro acima.
Documente da seguinte forma:
Valor perseguido: **Valor de Mercado**
Descrição: aumentar nosso NPS e o engajamento com nossos produtos (North Star).
2. Narrativa do usuário e hipótese
Após preencher o primeiro bloco, é hora de partir para a narrativa do usuário. Aqui, você pode usar aquele famoso template que contempla:
- Como … [target da funcionalidade]
- Eu quero … [item desejado – título]
- Para que eu possa … [entrega de valor – job to be done daquilo]
No segundo bloco, você também pode colocar a validação da hipótese, isto é, a resposta para a pergunta: “como saberemos se a funcionalidade atingiu seu objetivo?”, conforme referência de Paulo Caroli no livro “Lean Inception”.
A ideia é descrever e, idealmente, definir métricas quantitativas para validar essa hipótese.
Exemplo: Nós acreditamos que este MVP vai conseguir **contribuir para o aumento do engajamento dos usuários da “Empresa XPTO”**. Sabemos que isso aconteceu com base **no número de usuários que abriram o app diariamente vs o número total de usuários ativos, que deve ser de 50% mensalmente**.
3. Requisitos técnicos
No terceiro e último bloco, você vai descrever os requisitos técnicos. Para isso, é possível utilizar a técnica “7 dimensões do produto”, que percorre os seguintes aspectos:
- 1. Atores: Administrador da Fazenda; Dono da Fazenda.
- 2. Interfaces:
– Fluxos da jornada do usuário
– Interface com as APIs do Climatempo.
- 3. Ação (história do usuário):
**Eu como** usuário administrador da fazenda **quero** visualizar a probabilidade de chuva para o dia seguinte, com umidade e volume **para que** eu possa planejar a irrigação da lavoura com a quantidade correta de água.
- 4. Dados:
– Login via Google, Facebook, Celular
– Dados da previsão do tempo via fornecedor externo (Climatempo)
– Deveremos taguear os eventos de uso do produto segundo o documento de mapa de eventos nesse link: https://bit.ly/mapa_eventos_app
- 5. Regras de negócios:
– Usuários com plano de assinatura suspenso não poderão ter acesso ao app.
– Não estamos violando nenhuma regra da LGPD e os dados do Climatempo estão devidamente regulamentados. É preciso estar na tela o “por Climatempo”.
– Níveis de permissionamento diferentes entre Administrador, Dono e demais usuários daquela conta.
- 6. Ambiente:
– Aplicativos na versão iOS e Android
– Pipeline de deploy configurado
– Precisa ser criado um ambiente de homologação para essa feature.
- 7. Qualidade (critérios de aceite):
– Informações carregadas na tela ficam em cache para uso offline
– O usuário pode cadastrar notificações de aviso sobre a previsão via push
– Ao abrir o app o usuário verá na tela o dia seguinte
– Com scroll para cima, o usuário avança nos dias
– Uso de dados do calendário do dispositivo para definir data de abertura no app
– Dados da Climatempo serão armazenados na AWS; os recursos de servidores já foram alocados pelo time de DevOps; os dados dos usuários serão encriptados em curva elíptica de 384 bits para autenticação
– Com scroll para baixo, o usuário retorna nos dias.
Além da técnica acima, você também pode aplicar a “BDD – Sintaxe Gherkin”, para criação de cenários de testes.
O template é o seguinte:
- **Feature**: Tela com probabilidade de chuva e volume para o dia seguinte
- Contexto: O usuário, ao abrir o aplicativo, não terá conexão com a internet via rede G ou wifi. Informações carregadas na tela ficam em cache para uso offline em uma nova abertura. Nesse caso, a interface do app avisará a falta de conexão e o horário da última atualização com a internet.
- **Scenario** (cenário): usuário sem rede G abrindo o aplicativo
- **Given** a falta de conexão com a internet
- **When** o usuário abrir o app da “Empresa XPTO”
- **Then** o app apresentará uma mensagem via toast de falta de conexão
- **And** apresentará os dados em cache da última abertura com conexão
- **Then** o app iniciará uma rotina de novas tentativas de conexão a cada 5 segundos
- **And** quando a conexão for estabelecida
- **Then** apresentará uma nova mensagem via toast avisando que a conexão foi restabelecida
- **And** os dados atualizados serão exibidos na tela.
Vale acrescentar que você pode incluir ainda outros cenários, ok?
Depois de preencher todos os blocos listados acima, o processo de documentação das histórias de usuários chega ao fim. Com todas as informações registradas, os desenvolvedores estão prontos para codar.
Sem dúvida, com o documento de requisitos bem feito, o seu produto tem uma parte importante do que é preciso para dar certo no mercado. Então, siga as recomendações deste artigo e seja feliz! 🙂
Saiba mais sobre o tema com a Awari
Awari é uma plataforma completa com mentorias individuais, cursos com aulas ao vivo e suporte de carreira para você dar seu próximo passo profissional.
Conheça nossa trilha de Design e confira todos os nossos cursos de UX/UI com jornada personalizada e materiais complementares feitos por especialistas no mercado 😉
Referência: https://www.martinfowler.com/bliki/UserStory.html
