“Eu sou responsável pelo que escrevo, não pelo que você entende.” — Não!!! A responsabilidade da clareza de comunicação é de todos. E o refining é sobre isso: alinhamento, comunicação clara e objetiva!

Constantemente ao conversar com alguns amigos que estão adotando a agilidade, ou ao chegar em alguns clientes, percebo que há dúvidas quanto à execução do refinamento dos cards (refining ou grooming, este último tem entrado em desuso, dado que em alguns países de língua inglesa a expressão tem sido relacionada a casos de assédio. Inclusive o Scrum Guide abandonou o uso da palavra em 2013).

Também há dúvidas quanto a importância deste processo: “Por qual razão devo usar no meu time?” , “É realmente útil?”. Acredito que o processo de refining é extremamente importante para o bom andamento de um projeto. Sua principal função é deixar as user stories melhor descritas, com o menor número de incertezas possíveis. Sua execução visa criar um maior alinhamento das expectativas das partes interessadas, deixando claro para todos o que será construído. Gera uma série de benefícios, como:

• Com user stories melhor descritas a previsibilidade de conclusão é mais clara;
• A chance de um imprevisto surgir durante o desenvolvimento e criar um bloqueio se torna menor;
• Todos do time de desenvolvimento ficam cientes do passo a passo para conclusão do requisito, por exemplo.

O ponto é que ainda é nebuloso para muitas pessoas a escrita de cards e a respectiva execução do levantamento.

Um entendimento que podemos ter acerca do assunto e que defendo é:

• Se o levantamento do card ocorre todo no mesmo momento, seja de planejamento, replenishment, refining ou outro nome que você costume usar. E começa a escrever o card ali, adicionando dúvidas, critérios de aceite e tudo nesse momento. Então sim, concordo que seu refining é uma reunião (ainda que toda reunião seja – ou deveria ser- um processo, hehe).
• Se o levantamento do card vem sendo feito antes da reunião, alguns dias antes você começa a levantar os impedimentos, dúvidas, critérios de aceite, possíveis bloqueios, integrações, etc para chegar com o card escrito. Ou seja, está fazendo um processo de levantamento do card, logo, refining se torna um processo.

A ideia deste texto é explicar, e defender, quais as vantagens de tratar o refining como um processo e não como uma reunião. Mas antes, o que é um processo? Um dos possíveis significados para processo é: “…um método, sistema, maneira de agir ou conjunto de medidas tomadas para atingir algum objetivo.”. No caso, o objetivo de um processo de refining é gerar user stories prontas para serem desenvolvidas.

Agora, vamos começar a parte legal. Qual a razão de transformar o refining num processo, e não uma reunião?

Acredito que haja algumas razões que façam com que o processo se sobressaia à reunião e crie um output com user stories melhores escritas ao final. Essas razões oneram menos o time de desenvolvimento, trazem um peso maior sobre a agenda do responsável pelo produto e do responsável pelo processo, entretanto flexibiliza para o restante do time. [Ok! Mas, como?]

Quando se define um processo de refining, deixando claro os passos para antes e depois da reunião, conseguimos atingir alguns pontos cruciais:

• Melhor preparo para a reunião com o time: [como?] Bem, ao saber que você terá uma reunião você normalmente se prepara (espero que sim), correto? Definindo o processo corretamente, você sabe quais passos precisará tomar, para estar preparado para o refining. Uma boa reunião, acredito que seja influenciada por alguns fatores: uma pauta bem definida, um time box fechado e um facilitador para que a reunião seja fluida;
• Otimizar o tempo do time: quando você se prepara para um refining, escrevendo os cards antes, realizando pesquisas e levantando possíveis dúvidas, você está reduzindo o tempo em que todos precisarão ficar juntos para fazer isso. Otimizando o tempo de todos os envolvidos;
• Reduz possibilidade de devaneios: quantas vezes você esteve refinando uma user story, e do nada alguém começou a devanear durante a reunião? Levando uma user story melhor descrita para o momento da discussão reduz as chances de alguém começar a puxar um debate de algo que não está no escopo do card.

Que ótimo, como eu realizo um refining?

Você deve estar se perguntando, não?

Uma coisa imprescindível é definir um processo para o refining (para não sermos muito “disruptivos”), e reduzir a confusão na cabeça de algumas pessoas. Costumamos dizer aqui na Plataformatec que dividimos o refining em duas etapas, sendo que ambas fazem parte do processo de refining: pré-refining e o refining em sí, isto é, o encontro para que o time feche o entendimento do que foi escrito na user story.

Opa, maravilha. Pré-refining e refining, mas o que seriam?

Chamamos de pré-refining todo o preparo tido para que a user story chegue mais redonda para o time. Costumamos começá-lo mais assíncrono, e realizando alguns passos.

Primeiro, como responsável pelo processo e auxiliando a pessoa de produto, costumo estudar o escopo de negócio para entender do que se trata a user story, de forma a ter o mínimo de conhecimento para escrever e questionar critérios de aceite, ou formas de implementação (falando de negócio, não de código). Os critérios de aceite são adicionados à user story, de forma que fique claro para todos os envolvidos o que é necessário para que o card seja tido como completo, ou seja, que a user story seja aceita como pronta.

Desta forma, é possível que já sejam levantadas dúvidas do produto dentro da user story. E esse é o segundo passo, conversar com a pessoa de negócio, passando o primeiro filtro no card, e anotando dúvidas que possam surgir relativo ao escopo do projeto ou da user story. Esses questionamentos ficam anotados no card, de forma que todo o time possa ver.

Em seguida, procuro algum dos desenvolvedores e converso sobre a user story, demonstrando o que já foi levantado, para que passemos por um segundo filtro da escrita. Nesta conversa com o desenvolvedor surgem as dúvidas mais técnicas, dúvidas de integrações, por exemplo.

A ideia neste passo, como dito anteriormente, é deixar a user story minimamente escrita de forma a otimizar o tempo de todos. Como o especialista em negócio e um dos especialistas técnico do projeto já foram consultados, em teoria os cards já possuem informações suficientes para que sejam levados para o refining. Caso ainda existam dúvidas que não foram sanadas, com grande risco de não serem respondidas durante o encontro, o ideal é que essas respostas sejam obtidas antes do mesmo.

Levantei todas as dúvidas, deixei o card pronto! O desenvolvedor pode puxar a user story?

Opa! Calma lá jovem Padawan, não é bem assim! Você validou a hipótese do card com apenas duas pessoas! O seu time provavelmente possui bem mais pessoas que isso! Agora sim, vamos ao encontro para refining!

Agora é onde há o acordo do time, que aquilo que está escrito na user story faz sentido, e é entregável! É o momento em que o responsável pelo negócio dá sua palavra de que é aquilo que ele espera como produto do card desenvolvido, e também é o quando analistas de qualidade e desenvolvedores entram em acordo do que será construído e testado.

Quais os passos de um refining?

Calma! Queria apenas deixar claro o que faremos a partir de agora! Já que estamos entendidos, vejamos agora algumas dicas de como fazer isso!

Primeiro de tudo, há algo muito importante que eu defendo: traga as pessoas certas para as reuniões certas. No caso, como estaremos falando do desenvolvimento, é imprescindível a participação de desenvolvedores. Falaremos também de testes, então um analista de qualidade é muito importante! E também falaremos de incrementos ao negócio, logo, a participação do responsável pelo produto é essencial! Entretanto, não há a necessidade de participarem todos os desenvolvedores, por exemplo. A user story deve estar escrita de forma clara o suficiente para que alguém que não participou do encontro seja capaz de ler e compreender o que deve ser feito. Na equipe que trabalho atualmente, utilizamos o valor máximo de 50% dos desenvolvedores na reunião. Veja bem: máximo, há momentos em que participam menos.

É indispensável que este momento seja síncrono! De forma que estejam todos alinhados no mesmo momento, e saiam sem dúvidas quanto ao que foi discutido (as chances de restarem dúvidas são maiores em uma discussão assíncrona, por exemplo). Com um encontro síncrono, as pessoas costumam entender melhor o que está sendo discutido.

Outro dois pontos cruciais que devem andar juntos: objetivo e time box! Antes de entrar na discussão do refining deixe bem claro qual o objetivo da conversa, e qual o time box vocês terão para isso. Algo como: “Pessoal! Temos 3 user stories que precisam ser refinadas! Usaremos 20 minutos para cada uma!”. Desta forma, o time sabe que precisará otimizar seu tempo para que a discussão gere frutos dentro deste tempo definido. Outra coisa bem legal de se fazer, é deixar um computador com um timer regressivo contando este time box (basta dar um Google com o termo “timer” e pronto! Mágica realizada!). Desta maneira, a medida que o time evolui, haverá alguém atento a isso e cobrando os demais.

Lembre-se, este é o momento de entendimento do time. É onde todos devem estar comprometidos quanto ao que será entregue, e como será entregue. As user stories devem sair bem descritas para que entrem dentro do ciclo de desenvolvimento. Aconselho fortemente que, caso ao final destes 20 minutos ainda restem muitas dúvidas, incertezas ou que o time não esteja seguro quanto a entrega, que o card não entre no ciclo de desenvolvimento, e passe por um novo processo de refining. Não queremos cards com alto grau de incerteza dentro do processo, queremos?

E você, como lida com o refining dentro do seu time? Você acha que é uma reunião? Um evento? Um processo? Conta pra gente aí nos comentários como você lida com isso dentro do seu time!