Awari

9 de novembro de 2021

User stories: 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. 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!

Conheça os descontos de até R$3 mil reais da Black Friday da Awari clicando aqui.

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:

Primeiro bloco: 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. 

O que é valor para o negócio?

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

Segundo bloco: 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]

Referência: https://www.martinfowler.com/bliki/UserStory.html

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”:

Referência do Livro Lean Inception

A ideia é descrever como no modelo acima 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**.

Terceiro bloco: 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: 

     – Visuais de UX/UI

     – 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?

Conclusão

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!

Escrito por

Alex Ivonika

Mais de 10 anos criando produtos digitais em startups premiadas no Brasil e Latam. Co-foundador do Product Guru's e professor do curso de Product Management na Awari. Consultor e mentor sobre Product Management, Estratégia e Negócios para empresas e startups.