User Stories: boas práticas, estruturação e dicas extras

User Stories ou Histórias de Usuário são os documentos comumente utilizados para descrever as funcionalidades de uma solução que está sendo criada dentro da metodologia ágil. Poderíamos resumir em uma única palavra o objetivo da User Story (US): comunicar. Comunicar a visão do cliente e como ela deverá ser implementada pelo time de desenvolvimento (aqui, o time de desenvolvimento inclui todos os papéis necessários: análise, design, desenvolvimento, qualidade, entre outros).

Portanto, dependendo da organização de cada empresa, ao menos o time de desenvolvimento e o cliente devem ser considerados no momento de definir a linguagem que utilizaremos, as informações que estarão na história e como elas serão organizadas (já, já falaremos mais disso). Geralmente, estes dois papéis (cliente e time de desenvolvimento) formam o nosso público-alvo. Precisamos entender que cada time é um time, cada empresa é uma empresa e cada cliente é um cliente, então, podem haver diferenças no uso das US.

Por isso, é importante lembrar que não existe uma regra de ouro na hora de escrever User Stories, porém, existem sim boas práticas para seguirmos; e eu ainda gostaria de acrescentar algumas, que fazem muita diferença no dia a dia de todos os envolvidos na criação de uma solução de valor.

As boas práticas sugerem que uma User Story deveria conter:

– Descrição

– Critérios de aceitação

Descrição

Deve trazer uma visão básica da história do usuário, identificando a persona (quem?), a funcionalidade (o quê?) e qual o problema/objetivo que será resolvido por ela (por quê?). É o conhecido padrão ou template “role-feature-benefit” (papel-funcionalidade-benefício). Abaixo, segue um exemplo de uma possível história para o setor bancário/financiero.

Como analista de crédito,
quero visualizar as informações de risco do cliente,
para ter assertividade na aprovação de crédito.

Em uma frase simples, é possível entender que a nossa persona é o analista de crédito, ou seja, compartilhamos quem é o usuário; além disso, entendemos a necessidade (visualizar as informações de risco do cliente); e o que será resolvido ao ter essa necessidade atendida, ou seja, qual problema ou objetivo será alcançado (ter assertividade na aprovação de crédito). Uma User Story que não tem uma persona ou uma necessidade atendida, não deveria ser priorizada para o desenvolvimento.

Além disso, uma dica é incluir dois itens extras nessa seção inicial: contextualização e protótipos.

A contextualização pode ser uma frase simples de introdução para a US, visto que nem todas as pessoas do time estão participando da criação desta solução desde o início. Além disso, geralmente quem cria a US participa de diversas reuniões de discussão e definição da solução, mas o restante do time pode não ter sido incluído. Transmitir onde cada item do backlog se encaixa dentro do produto é muito importante e traz uma visão macro do porquê aquele item foi priorizado e será desenvolvido. Comunicação é a chave.

No geral, nós somos seres visuais. Portanto, protótipos podem ser bons norteadores para os Critérios de Aceitação. As figuras dos protótipos podem ser incluídas diretamente no software de gestão da US (Jira, Azure, o próprio Word, etc) ou com um link do protótipo (dependendo da organização de cada equipe). Tip extra: a segunda opção é mais viável para quando o protótipo sofre muitas atualizações durante o processo de refinamento.

Portanto, se sugere que a User Story contenha:

– Descrição: Contextualização + Descrição (quem, o quê e por quê) + Protótipos.

– Critérios de aceitação

Critérios de aceitação

Poderíamos fazer um artigo inteiro só para falar dos amados Critérios de aceitação. O que são? Onde vivem? Do que se alimentam?

Eles são as condições que a funcionalidade deve ter para ser aceita pelo usuário. Os Critérios de aceitação vivem e se alimentam das regras de negócio, definições da Experiência do Usuário (UX), acessibilidade, segurança, permissões (que não são parâmetros), entre outros. Em resumo, devemos incluir tudo que for relevante e que deve ser considerado pelo time no momento do refinamento e da planning. Em outras palavras, que é importante para os envolvidos e que impacta no desenvolvimento.

Não existe uma regra para a descrição dos Critérios, porém, as boas práticas nos trazem dois formatos principais (orientado a cenário e orientado a regra), além da customização que pode ser feita (com zelo e atenção):

• Scenario-oriented (Given/When/Then) / Orientado a cenário (Dado que/Quando/Então): herdada do BDD (behavior-driven development), essa estrutura oferece Critérios de aceitação que, quando combinados, cobrem todas as ações do usuário e as condições para executar uma tarefa, além de definir o resultado dessas ações.

Cenário 1: X
Dada alguma precondição,
Quando eu fizer alguma ação,
Então eu espero um resultado.

Descrição: 
Como atendente da ouvidoria, 
Quero que o sistema inicie a conversa com a pessoa usuária, 
Para padronizar e agilizar o atendimento inicial.

Cenário 1: Iniciando atendimento via chat
Dado que a pessoa usuária é a primeira da fila,
e está online no chat
Quando o próximo atendente ficar disponível
e aceitar o atendimento,
Então a conversa deve iniciar
e enviar a mensagem padrão "Olá, eu sou <o/a nome do atendente> e 
vou realizar o seu atendimento. Como posso ajudá-lo/a?"

Veja mais exemplos, em inglês, aqui.

• Rule-oriented / Orientado a regra: Nem sempre é possível utilizar o formato acima, por isso, uma outra forma de descrever é listando as regras (estilo checklist) de um comportamento do sistema.
  Cá entre nós, eu utilizo esse formato com mais frequência, primeiro porque atualmente os cenários de teste serão escritos pelos QAs, portanto, não há problema em focar mais nas regras; e, segundo, simplifica o processo para User Stories mais complexas.

Descrição: 
Como atendente da ouvidoria, 
Quero que o sistema inicie a conversa com a pessoa usuária, 
Para padronizar e agilizar o atendimento inicial.

Critérios de aceitação:
- A conversa via chat deve iniciar quando uma pessoa atendente ficar disponível e aceitar o atendimento;
- O sistema deve buscar a próxima pessoa usuária da fila, que está online;
- O sistema deve iniciar a conversa entre pessoa atendente e pessoa usuária, enviando a mensagem: "Olá, eu sou <o/a nome do atendente> e vou realizar o seu atendimento. Como posso ajudá-lo/a?".

• Customizados: Quando necessário, pode-se utilizar modelos customizados para facilitar o entendimento dos Critérios de aceitação.
  Podemos, por exemplo, separar a informação mais relevante para o negócio do conteúdo mais técnico: para descrever um formulário, nos critérios de aceitação poderíamos informar quais são os campos e sua obrigatoriedade; ao final dos critérios, poderíamos incluir que o campo “Nome do cliente” deve aceitar no máximo 120 caracteres e não pode aceitar caracteres especiais. Outro exemplo seria incluir uma tabela complementar de um critério de aceitação sobre a regra de validação de senha, com exemplos de quais combinações de senha são aceitas e quais não seriam, desta forma, se demonstraria mais claramente o comportamento de uma validação do sistema.
  O formato customizado pode ser utilizado sempre, inclusive em conjunto com os demais formatos, desde que resulte com um melhor entendimento da User Story para os envolvidos.

Aqui, a sugestão é que a User Story pode conter:

– Descrição: Contextualização + Descrição (quem, o quê e por quê) + Protótipos.

– Critérios de aceitação: (Orientado a cenários ou orientado a regras) + customizado.

Tips extras e, finalmente (=P), tips finais:

• Lembre-se de que não existe uma regra de ouro. Temos boas práticas porque elas são o básico bem feito. Porém, nada te impede de melhorar o que for necessário de acordo com o cliente ou time em que você está;
• Escute o que o time pergunta no refinamento e a cada sprint inclua essas informações nos critérios de aceitação. Se necessário, faça uma dinâmica com os envolvidos para ver o que está faltando e o que facilitaria o trabalho de cada um. De qualquer forma, comece simples e vá evoluindo;
• Priorize sempre a linguagem do usuário e evite tecnicidades, mas não a ponto de faltar informação para o desenvolvimento (exemplo: para criar um formulário, defina os campos do formulário, sinalize quais são obrigatórios… e pare por aí, você não precisa incluir o nome do campo do banco de dados — se tem “algo_assim” ou “algoAssim”, provavelmente está muito técnico). A descrição técnica deve ficar dentro das tarefas de desenvolvimento.
• Leia e leia muito: artigos, livros, jornais, revistas, e o que mais for útil para você. Isso porque é importante que quem escreve a User Story tenha um bom desenvolvimento linguístico e uma boa escrita, e a leitura colabora muito nesse processo. Lembre-se que a User Story também é um canal de comunicação da criação do produto/solução;
• Um pouco relacionado com o item anterior, tente escrever os critérios de aceitação em voz ativa: o sistema envia o arquivo para o e-mail do cliente (sujeito + verbo + complemento); ao invés da voz passiva: o arquivo será enviado para o e-mail do cliente, pois isso define melhor o executor da ação, além de facilitar a compreensão do texto.

Uma User Story completa, escrita em linguagem simples e objetiva, unifica a visão do produto e/ou solução que será construída. Além disso, facilita para que o time tenha mais empatia pelo usuário, visto que irá entender o contexto e o porquê de cada item priorizado no backlog. O santo graal é que todos os envolvidos (áreas de negócio, usuários — quando possível — e time de desenvolvimento) se sintam à vontade e com conhecimento suficiente para contribuir na criação da solução.