Atualmente, quase todas as equipes de desenvolvimento de software usam Kanban, Scrum ou mesmo uma versão adaptada dos dois.
A real é que não importa qual dessas você utiliza, desde que os processos funcionem para todas as pessoas envolvidas e que seja possível acompanhar o progresso e produtividade ao longo do tempo.
A questão é que ambas abordagens para a gestão do trabalho no dia-a-dia acabam envolvendo algum grau de escrita e direcionamentos importantes. E para isso, a maioria das equipes utilizam as chamadas histórias de usuário (US).
As histórias de usuário representam o menor trabalho possível que agrega valor ao usuário final. Elas têm um escopo fixo e são implementadas durante um período de tempo específico (Por exemplo, durante um sprint).
O objetivo é colocar o usuário final no foco da conversa e permitir que devs e designers entendam melhor o que/por que/para quem estão construindo recursos.
No geral, a equipe pode decidir o que quer incluir nas histórias de usuário, mas com o tempo, descobri um formato que parece funcionar para diferentes times de desenvolvimento.
O que uma boa história de usuário precisa?
Bill Wake introduziu o chamado princípio INVEST para escrever histórias de usuários que define o que uma boa história de usuário deve conter.
O formato das histórias de usuário realmente não importa, contanto que o conteúdo delas siga esses princípios. No entanto, como escrever histórias de usuários e adicioná-las ao backlog é uma tarefa contínua, o melhor é definir um formato específico.
Esse formato deve ser criado junto com o time para que todos estejam alinhados com a aparência de suas histórias.
Template para criar excelentes histórias de usuário
Em minha atuação como dev descobri que o modelo a seguir é bastante útil. Introduzi esse modelo em algumas equipes, assim como acabou sendo adotado por várias outras. Para criar a rotina de escrever histórias de usuário realmente boas, o melhor é definir um critério baixo, focar na estrutura e começar por aí. A maioria das ferramentas usadas pelas equipes, como JIRA e etc., oferecem a possibilidade de criar um modelo para diferentes tipos. Use-o.
Numa primeira etapa, recomendo criar uma estrutura de história de usuário junto com a equipe. Depois, você deve adicionar essa estrutura como modelo para qualquer software que estiver usando para gerenciar as tarefas.
O modelo a seguir é o que utilizei. Dito isto, você deve adaptá-lo às necessidades da sua equipe.
E vale uma nota: ainda que ele seja propositalmente detalhado – e sabemos que nem toda história de usuário requer tantos detalhes – acho importante ter um modelo nesse formato de modo a precisar apenas remover algumas partes que não serão necessárias, se for o caso.
Template
- O que?
- Por que? (ofereça o máximo de contexto possível)
- Como? (adicionado por devs durante o refinamento)
- Critérios de aceitação (<= 8)
- Casos de teste (dado que — quando — então)
- Exemplo(s)
- Informações adicionais (documentação / etc.)
- Insumos necessários (arquivos/imagens/etc.)
- Dependências (Internas/Externas)
Quem deve escrever histórias de usuários?
A responsabilidade pela redação contínua das USs é de um ou vários membros da equipe que representem o negócio e tragam a visão do produto/parte do produto.
Isso geralmente significa que a pessoa responsável pela escrita seja o(a) Product owner, Product Manager, Analista de Negócios, etc. No entanto, para aproveitar ao máximo as histórias de usuário, é crucial incluir os(as) devs no processo.
Como trabalhar melhor com as histórias de usuário?
O melhor modelo de história de usuário e as melhores intenções não significam muito quando não são usados corretamente. Na maioria das vezes, a pessoa que faz o descritivo (por exemplo, PO/PM/BA/etc.) pode preencher a maior parte do modelo por conta própria.
No entanto, muitas vezes acaba faltando o conhecimento técnico aprofundado para escrever uma história que possa ser estimada imediatamente. E está tudo bem.
Na minha experiência, a maioria das equipes possuem planejamentos de sprint, estimativas, reviews e retrospectivas definidas como reuniões regulares.
Mas muitos não têm reuniões de refinamento.
As equipes tendem a começar esse refinamento durante a reunião de estimativa ou quando têm dificuldade com questões levantadas por devs que, ao iniciarem uma issue, acabam bloqueados pois certas informações estão faltando ou foram mal interpretadas.
Na minha opinião, uma reunião regular de refinamento é crucial para um processo de desenvolvimento produtivo e fornece uma boa porta de entrada para uma discussão contínua e aberta sobre as próximas features e tarefas.
Para além disso, na minha experiência, o melhor é realizar essa reunião de refinamento uma vez por semana. Claro, como sempre, cabe a você e sua equipe decidir a frequência. Porém, realizá-la semanalmente mantém todas as partes informadas e responsabiliza quem escreve os descritivos a realmente escrevê-los.
Beleza, e o que deve acontecer nessa reunião?
A reunião é sobre a pessoa que escreveu o descritivo da issue apresentando-a à equipe de desenvolvimento. Aqui, não é necessário que todos os(as) devs estejam presentes, mas pelo uma parte da equipe deve comparecer.
Quando a issue for introduzida, a equipe poderá fazer perguntas e iniciar a discussão sobre o que precisa ser feito para implementá-la. Durante esse período, a discussão do “como” é concluída, assim como outros pontos que estejam em aberto no template e que são importantes para a implementação. O objetivo principal deve ser preparar a estimativa da história do usuário.
Aqui, é importante separar os momentos de refinamento e estimativa das USs, uma vez que combinar ambos em uma reunião geralmente leva a uma agenda que consome muita energia, daí a maioria das pessoas acabam se distraindo em algum momento e apenas duas pessoas continuam discutindo as coisas.
Isso geralmente leva a confusão e mal-entendidos quando uma issue é iniciada em determinado momento.
Ter um foco claro durante ambas as reuniões mantém todas as pessoas envolvidas e significa que as USs serão discutidas diversas vezes antes da implementação. Isto também é crucial porque, por um lado, toda a equipa está envolvida e tem de trabalhar em conjunto e, em segundo lugar, como todos sabemos, por vezes temos de falar sobre as coisas várias vezes para conseguirmos fazer as perguntas certas/ver os problemas, etc.
–
Este post é uma tradução livre do artigo 🔗“How to write better user stories? — A template” publicado por Rebekka Orth.
