Por Luiz Alvaro Wienc*
Você já trabalha com o Ágil ou Scrum? Se sim, já se deparou com a escrita de histórias de usuários, se não, a escrita de história de usuários é a forma de expressar a necessidade do cliente/usuário. Por isso, é uma das mais importantes etapas do desenvolvimento, pois ela traz um conjunto de informações que será usado para desenvolver software, aplicativo, sistema, como queira chamar.
Estou há mais de 10 anos trabalhando com ágil/Scrum e percebi diversas maneiras de escrever histórias de usuários. É importante dizer que nenhuma maneira está certa ou errada, apenas existem pontos de vista diferentes e o que escreverei aqui serão as boas ideias que pude praticar ao longo dos anos. Testei algumas delas e consegui obter excelentes resultados.
Cada história de usuário depende da maturidade de conhecimento de quem escreve e, quando digo isso, podemos considerar vários aspectos, tais como, tempo na função de Product Owner ou Analista de Requisitos, tempo de conhecimento do produto, tempo de trabalho com o time, entre outros.
Esse artigo foi escrito com base na minha vivência e conhecimento, foram diversos cursos feitos, pesquisas na internet, trocas de experiências com colegas de trabalho, troca mútua com os times e com o aprendizado constante. Espero que esse conteúdo te ajude de forma simples na evolução das suas escritas de boas histórias de usuários.
Apresentando o USER STORY REVIEW (ou Revisão de Histórias de Usuários)
Com base na troca de boas práticas, percebi que o time técnico que pratica o code review (revisão de código) tinha uma qualidade acima na entrega de software, com base em padrões e técnicas e conhecimento de desenvolvedores mais sêniores. Antes de ver como fazer o USER STORY REVIEW, vamos passar por algumas etapas, tenho certeza que isso fará a diferença no ganho de maturidade de escrita de histórias de usuários como Product Owner, no seu time de Product Owners, caso seja gestor, e, até mesmo, no time de produtos.
Para o Product Owner, é uma ferramenta muito importante, além de facilitar a escrita, um conjunto de histórias de usuários representa a lista de backlog e pode facilmente priorizar por necessidade ou valor para o negócio.
Utilizamos a seguinte estrutura:
Como <quem? – persona>
Desejo/preciso <o quê? – meta/ideia>
Para <por quê? – benefício de negócio>
A partir desse padrão, podemos ter diversas variações, que podemos falar em outro artigo. Quero agora só passar rapidamente por eles… podemos incrementar colocando E em outra linha e adicionar alguma nova informação, ter quebras, pois a história de usuário ficou grande, você pode identificar de forma simples com a palavra OU, E, mais de 1 atributo entre outros.
É importante pensar em um conteúdo que poucos se preocupam, os critérios de aceite, muitos fazem apenas a história de usuário e entendem que é suficiente para o time desenvolver. Ao longo das evoluções que passei, percebi que essa é uma das chaves de sucesso, por isso, invista tempo na escrita desses critérios. Não pense apenas em cenário Felizes, de sucesso, pense também em situações de insucesso.
“A entrada é a parte fundamental para o restante do fluxo de desenvolvimento.”
O Product Owner tem a oportunidade de começar todo o desenvolvimento com boas histórias de usuários com critérios de aceite bem definidos, isso faz com todo o processo de desenvolvimento de um produto comece bem desde a sua concepção.
Como você sabe que as histórias de usuários estão bem escritas?
Te pergunto: como você sabe que as histórias de usuários estão bem escritas? Quando as entregas do time não estão com erros? Quando o time não aciona o Product Owner (PO)? São muitas perguntas e dúvidas, por isso fui pesquisar e ver como melhorar isso.
Para responder essas perguntas e outras eu criei o USER STORY REVIEW (Revisão de Histórias de Usuários) e esse é o intuito desse artigo: falar para que serve isso e como fazer.
Em conversas com meus pares técnicos, recebi alguns feedbacks que as histórias de usuários não traziam nenhum direcionamento e, com isso, nossas entregas não estavam com a devida qualidade. Acabávamos tendo retrabalhos ou não implementado tudo que era necessário para atender o cliente.
Após conversar com meu time, as squads, estabeleci uma recorrência de acompanhamento com os Product Owners, de fazermos a leitura das histórias de usuários e ver se de fato o que estava escrito remetia à necessidade e dava a clareza e os insumos ao time. Foi aí que descobri que tínhamos oportunidade.
“O conhecimento gera alguns gatilhos de forma a ‘hackear’ seu cérebro para a construção de suas histórias de usuários”
Isso mesmo, quando fazíamos as sessões de USER STORY REVIEW, fomos implementando a forma de escrever histórias de usuários.
O que é USER STORY REVIEW?
O USER STORY REVIEW é um técnica onde uma pessoa faz a leitura da história de usuário e faz o entendimento da mesma. Antes de ir para o time de desenvolvimento, essa leitura é feita e analisado o que a história de usuário visa revolver. Se a pessoa que fez a leitura entendeu sem duvidas ou sugestões, ela simplesmente avisa a pessoa que escreveu que está entendida e ela pode seguir com o time. Agora se não está, ela anota perguntas de suas dúvidas para entender melhor o que significa e pode trazer algumas sugestões ou melhorias de como poderia ter sido escrita. Assim, a pessoa que escrever pode melhorar a escrita, trazer mais detalhes.
O intuito é ajudar e não impor que a pessoa que escreveu siga o que foi sugerido, a decisão final é do dono da história de usuário.
Quando iniciei, tinha histórias escritas em 1 linha, onde o time fazia uma sessão de refinamento e tiravam todas as suas dúvidas com o Product Owner e anotavam em cadernos, blocos de anotação. As perguntas que o Product Owner não sabia, anotava e depois trazia para a pessoa que havia perguntado. Imaginem só o desperdício de energia e tempo que gastaram com isso.
Um dos principais beneficio dessa técnica é fazer com que o Product Owner tenha tempo para fazer outras coisas, como ir buscar mais backlog, pensar em melhoria contínua ou entender que precisa de mais dedicação, que o time tenha tempo para desenhar a solução, criar mais cenários de testes etc. Um Product Owner “gastava” em média 2 minutos para história de usuário, mas gastava mais de 1 hora tirando dúvidas, buscando informações que poderia ter colocado desde o inicio, explicando para pessoas diferentes.
Através do USER STORY REVIEW, o Product Owner aprende os principais gatilhos do produto, do cliente e passa a colocar essas informações na história de usuário ou como complemento para o time. As escritas passaram a ser feitas com mais tempo, em média 15 a 20 minutos, mas ele deixou de ficar mais de 1 hora em função de tirar duvida das pessoas, ele passou a escrever nas histórias seguintes informações que o time sempre perguntava, dar mais contexto e detalhe, com isso o time conseguia se resolver muitas vezes sozinho.
Outro beneficio ocorre quando há troca de pessoas no time. Sabemos que precisamos ter time estáveis, mas, às vezes, acontecem trocas de pessoas. Se seu time de Product Owners trabalha da mesma forma, com a mesma estrutura, isso é um desafio a menos para os novos membros do time, ele já conhece a estrutura de histórias de usuários, sabe que aquela squad trabalha de forma parecida no conteúdo das histórias de usuários. Se ele não conhecer do sistema, produto, ele terá informações que não precisará acionar os mais Seniores ou com mais tempo no assunto.
Podemos ter diversos ganhos, se quiserem saber mais, me procurem, posso trazer mais conteúdo sobre escrita de histórias de usuários e sobre o USER STORY REVIEW.
*Luiz Alvaro Wienc: Há mais de 17 anos trabalhando com produtos e serviços financeiros, sempre ouvindo o cliente para garantir a qualidade das entregas. Como Líder de Produtos na comunidade de pagamentos, sou responsável pela execução de Projetos de Pagamentos Digitais (exemplo. PIX, OPB), com foco em digitalização e centralização no cliente. Foco na evolução dos serviços de negócios alinhado a estratégia de pagamentos e visão de mercado. Atuando e aplicando metodologia de desenvolvimento ágil para mais de 15 times antecipando o valor agregado ao negócio. Sou apaixonado por produtos digitais, curioso e com perfil inovador. Profissional habilitado para a gestão de cadeias de valor, gestão do ciclo de vida de produtos (elaboração e condução de discovery, inceptions e acompanhamento do deploy), conhecimento e habilidade na gestão de pessoas, clientes, atingimento de metas e OKRs.
Gostou deste conteúdo?
Confira a participação do autor no Podcast Product Guru´s, onde aborda o tema Como escrever histórias de usuários eficientes.
