Quando olhamos como os produtos digitais impactam positivamente nosso dia a dia, percebemos que, muitas vezes, eles resolvem problemas de uma maneira bastante simples e de forma personalizada. Afinal, quantas vezes você já conseguiu realizar ações complexas apertando apenas alguns botões e falou “esse aplicativo salvou minha vida”?

Porém, para chegar nessas soluções, product owners, designers, pessoas de negócio e desenvolvedoras trabalham buscando entender quais problemas usuários estão enfrentando e qual é o jeito mais simples de resolvê-los. Para isso, são utilizadas diversas técnicas como, design thinking,  brainstorm, pesquisas e entrevistas. 

Mas, qual método pode ser utilizado para documentar as necessidades dos usuários de maneira ágil e que, se houver necessidade de mudanças de escopo, não implicaria em um desperdício de tempo, dinheiro e esforço? E qual método, também, poderia ajudar as pessoas que irão trabalhar no desenvolvimento da solução a possuírem o mesmo entendimento do que deverá ser construído para resolver o problema do cliente?

O que são User Stories

Bem conhecida em times ágeis (mas não uma exclusividade desses times), User Stories são especificações escritas utilizando linguagem de negócio, exemplificando, de forma simples, como uma pessoa usaria determinada funcionalidade de um produto.

Mesmo sendo consideradas especificações, Users Stories não são um contrato a ser seguido. Sua função é manter as necessidades dos usuários escritas de forma simples e ajudar a nortear a conversa entre as pessoas que construirão a funcionalidade que elas descrevem.

Esta conversa pode seguir o modelo da reunião dos três amigos, onde pessoas de negócio, desenvolvedoras e testadoras discutem o que será criado, evitando suposições e ajudando na entrega de software que atende à necessidade do usuário final.

Elementos importantes das User Stories

Existem alguns métodos para se escrever User Stories. Um dos mais usados no mercado é o dos Três 3C’s.

Cada um desses C’s é um critério importante na hora da escrita das User Stories. Eles representam Cartão, Conversa e Confirmação, e são essenciais para o entendimento de todos os envolvidos no processo.

Uma vez que entendamos a importância de cada um desses C’s e os colocarmos em prática dentro do projeto, é esperado que tenhamos um recurso que de fato ajudará na entrega de software que funciona e atende às necessidades dos usuários.

Cartão

O primeiro “C”, Cartão, é bem conhecido dos times que possuem quadro de tarefas, sejam representados por post-its ou cartões virtuais em softwares de gerenciamento de projetos como Jira, Azure Devops ou Trello, por exemplo.

O cartão é a ferramenta que irá ajudar o time a relembrar o que será conversado antes de iniciar o planejamento da solução.

Como falamos anteriormente, a User Story deve trazer de forma simples o que a funcionalidade de um determinado produto deve fazer, mas é uma prática comum (alguns chamam de erro) que as pessoas escrevam muitas coisas dentro de somente uma User Story.

Basicamente, colocar muitas coisas dentro de uma User Story não permite, por exemplo, que o time busque discutir e pensar nas mais diversas soluções possíveis para o problema, evitando assim que boas soluções sejam colocadas em prática. Outro problema que pode ocorrer é que, uma vez que a user story possua muitas informações, essa tarefa pode levar muito mais tempo para ser desenvolvida, implicando no tempo de entrega de software funcional ao usuário.

Dessa forma, existe uma recomendação de como escrever essas histórias, de modo a manter o foco na descrição da usabilidade:

  • Como < determinada persona >: essa informação traz quem é a pessoa que irá utilizar a feature que está sendo planejada;
  • Quero < determinada funcionalidade >: exemplifica qual funcionalidade haverá no produto;
  • Para < determinado resultado >: deixa clara a razão da criação da funcionalidade. Em outras palavras, a pergunta “para quê essa funcionalidade foi criada?” é respondida aqui.

Veja abaixo alguns exemplos de user stories:

  • Como < Turista >
  • Quero < Encontrar hotéis com vagas para entrada imediata >
  • Para < Não haver preocupação em reservar vagas em hotéis em caso de viagens de emergência >

ou

  • Como < Pessoa que quer comprar uma geladeira >
  • Quero < Filtrar características específicas de geladeiras >
  • Para < Reduzir os resultados da busca somente a geladeiras com características específicas, levando a uma menor quantidade de produtos a serem comparados >

Percebam que, nos exemplos, trouxemos de maneira simples o que o produto precisa entregar aos usuários para que eles fiquem satisfeitos. Contudo, somente com essa descrição, as pessoas que desenvolvem e testam talvez não consigam transformar o objetivo da história em código e em testes de maneira otimizada.

Sendo assim, entraremos no próximo “C”.

Conversa

Com o Cartão em mãos, o time de desenvolvimento (Product Owners, designers, pessoas desenvolvedoras e testadoras), antes do começo da codificação e mapeamento de cenários de testes, realizam a atividade mais importante: a Conversa.

Nesse momento, é esperado que as pessoas, juntas, leiam a User Story e clarifiquem o máximo possível o entendimento do que é esperado, trazendo para discussão quais os possíveis problemas que podem ocorrer ao longo da implementação da feature e quais decisões serão tomadas.

É muito comum também que as pessoas envolvidas nas conversas, seja no momento da criação dos protótipos de layout, na documentação dos cenários de testes ou na própria discussão, encontrem caminhos alternativos, levantem novas questões que podem não ter sido pensadas e agreguem ainda mais valor ao que será desenvolvido.

Esse é um dos grandes benefícios das User Stories: a colaboração gerada permite, muitas vezes, gerar um produto final que agregue muito mais valor ao usuário.

Após a análise de todos os pontos levantados ter sido finalizada e todos do time estarem alinhados, tem início a criação do terceiro C, a Confirmação.

Confirmação

Como o próprio nome diz, a Confirmação é o momento onde, após finalizada toda a discussão acerca da solução a ser criada, a User Story é repartida em diversas tarefas, visando facilitar o processo de desenvolvimento e acompanhamento do progresso do trabalho. 

Nesta etapa também são criados os critérios de aceite, atividade que irá contribuir na diminuição de retrabalho, agilidade nos testes e validação da funcionalidade.

Critérios de aceite são criados com o apoio das pessoas que irão realizar os testes e ajudarão na antecipação de validações que serão realizadas e na prevenção de possíveis bugs, fazendo com que problemas ou desvios no desenvolvimento sejam corrigidos de maneira antecipada.

Os critérios de aceite são maneiras de confirmar que, sendo desenvolvida seguindo as informações descritas, a User Story pode ser considerada apta para a avaliação e liberação por parte do Product Owner ou pelo próprio cliente.

Iremos pegar o exemplo que utilizamos acima para exemplificar a criação de critérios de aceite para a nossa user story < Filtrar características específicas de geladeiras >. Seriam bons critérios de aceite:

  • Critério #1: Caso não exista estoque de geladeiras com a  escolhida pelo usuário, o sistema deve mostrar os produtos resultantes da pesquisa com a etiqueta “Sem estoque”.
  • Critério #2: As características devem ser listadas em ordem alfabética.
  • Critério #3: Quando acessar a aba de filtros, os filtros devem vir todos desmarcados.
  • Critério #4: Deve existir um botão de limpar todos os filtros que tenham sido selecionados.

Percebam que os critérios de aceite são enunciados de forma simples, para nortear o desenvolvimento e definir como a funcionalidade irá se comportar.

Uma vez que o caminho dos 3 C’s é percorrido, toda a equipe já está em condição de realizar o desenvolvimento das features de maneira objetiva, focando não somente nas nuances do código, mas também no que o usuário precisa.

Implementar a utilização de User Stories em seu projeto não é algo complicado, mas traz diversos benefícios, como foco nas necessidades imediatas do usuário e melhorias na colaboração do time. Como resultado, sua equipe será mais eficiente por estar mais integrada e alinhada na comunicação, e os usuários se sentirão mais próximos do produto por estarem vendo suas necessidades sendo atingidas.

Autor

  • Thiago Barreto é agilista na Sofist. Interessa-se por metodologias ágeis, pessoas, melhoria contínua de times e por gestão de produtos.