Nota inicial: O antigo Backlog Grooming foi alterado para Refinement pois Grooming, segundo o Cambridge Dictionary, é o aliciamento de crianças para fins sexuais.
Dado o motivo da mudança, vamos ao que interessa.
1 – Por que fazer a Refinement meeting?
Através dela o Product Owner (P.O.) pode melhorar vários pontos – pessoais e técnicos-pessoais – do desenvolvimento do produto.
Pontos técnicos:
a. O P.O. precisa estar com o seu trabalho de priorização do Backlog em dia, pois não adianta perder tempo em refinar User Stories que só serão desenvolvidas após 6 meses.
Importante: Isso não significa que a ordem das histórias não possa ser alterada por questões que surjam durante a refinement.
b. O P.O. tem a chance de melhorar suas User Stories sem a pressa com que faria durante a Planning.
c. O P.O. consegue identificar eventuais “pontos cegos” das User Stories ou identificar dependências técnicas ou de outras equipes em tempo hábil para que sejam resolvidas.
d. O P.O. pode adicionar comentários às User Stories para serem posteriormente utilizados. Ex: Falar com o @fulano pois ele já trabalhou com JWT.
e. Naturalmente o P.O. já deixa mais claro e detalhado aos presentes o que está por vir.
Importante: Esta informação apenas adiciona detalhes àquilo que deve ser passado à equipe durante a Sprint Review.
f. A equipe técnica pode tirar as dúvidas e discutir aspectos técnicos com calma
g. A equipe técnica pode solicitar para que o item seja mais detalhado, ou até dividido em mais de uma User Story.
h. A equipe técnica pode estimar e discutir com calma sobre os motivos pelo qual votaram por esforços tão diferentes.
i. Não há nenhuma obrigação de que todos os items discutidos recebam esforços associados na primeira discussão/reunião.
Pontos técnicos-pessoais:
A cada Refinement meeting…
a. O P.O. e a equipe técnica ganham proximidade e confiança.
b. O P.O. e a equipe técnica aprimoram o seu trabalho como equipe.
c. Torna-se mais claro a lógica utilizada pelo P.O. para tomar decisões.
d. A equipe técnica deixa mais claro ao P.O. os desafios técnicos envolvidos na construção do produto.
e. O P.O. deixa de ser “alguém de negócio” e passa a “fazer parte” da equipe técnica e a equipe técnica deixa de ser “pessoas que não entendem o que, como, quando e por que aquilo é importante”.
Resumindo: Aproxima as pessoas, deixa claro decisões e dificuldades, tira a pressão de fazer tudo na última hora – Sprint Planning – e transforma “dois lados” em “um só”.
2 – Quanto tempo devo dedicar à Refinement meeting?
Trazendo um pouquinho de Scrum.org à conversa, na página 15 do Scrum Guide é dito que a Refinement não pode consumir mais de 10% da capacidade da equipe de desenvolvimento.
Texto original: “Refinement usually consumes no more than 10% of the capacity of the Development Team.”
Considerando 40 horas semanais, não pode levar mais do que 4 horas por semana.
Honestamente acho que 4 horas por semana é muito tempo pelos seguintes motivos:
a. É impossível manter pessoas atentas e produtivas por 2 horas especialmente em reuniões como essas, que não passam de discussões de como produzir algo novo.
b. Fazer 4 reuniões de 1 hora por semana torna-se inviável, chato e contra-produtivo.
Desde que comecei a levar a sério a Refinement meeting dedico – no máximo – de 2:00 a 2:30 semanais para isto e posso garantir que é mais que o suficiente.
3 – Formas que já utilizei para a Refinement meeting?
Quando decidi levar este assunto a sério perguntei à equipe como eles preferiam fazer e sugeri duas opções.
Primeira: Fazermos 2 vezes por semana com 1:30 de extensão cada.
Segunda: Dedicarmos diariamente – no máximo – 30 minutos depois das Stand Up/Daily meetings.
Esta equipe escolheu a segunda opção.
Com a experiência conseguida com a Refinement acima, identifiquei que 2 horas por semana são suficientes para manter o Backlog, não completamente mas, muito bem estimado.
Todas as – aproximadamente – 7 equipes com que trabalhei depois preferiram o modelo de 2 reuniões semanais com duração de – no máximo – 1 hora cada.
4 – Qual dia/hora que utilizo para isso?
Assim como deve acontecer nas cerimônias do Scrum, utilizo o conceito de Time-Box para as Refinements. Em resumo, a reunião tem um tempo previsto não pode durar mais que isso.
Quando fiz o Refinement pós-Daily eu – P.O. neste caso – trabalhava remoto então nos mantínhamos conectados para refinar as User Stories.
No caso das 2 reuniões semanais de uma hora faço um agendamento semanal – preferencialmente – da mesma sala de reunião e sempre – obrigatoriamente – no mesmo dia e na mesma hora.
Organizo as Refinements as Terças e Quintas pois os Sprints que tenho trabalhado nos últimos tempos começam às Segundas e terminam às Sextas, assim a Refinement não se choca com nenhuma cerimônia do Scrum.
Dou preferência para as 14h para que todos consigam almoçar tranquilamente pois lembre-se, por ser uma reunião que acontece 2 vezes todas as semanas, o ideal é que ela seja incorporada ao dia de trabalho e que não crie “esforço extra” para o comparecimento. Se o horário das 14h não for bom, coloco-a por volta das 16:30 ou 17h para que não “corte” o período da tarde.
5 – Quem participa?
– O P.O. por motivos óbvios.
– Equipe de Desenvolvimento: Atualmente tenho trabalhado com P.O. para 4 equipes, por isso, acho pouco produtivo que todos participem mas temos um acordo de que, pelo menos, duas pessoas de cada equipe devem participar.
– Scrum master, se possível pois sempre trás valor.
– Qualquer pessoa que possa auxiliar no Refinamento da User Story.
6 – Como faço para que todos saibam o que vão encontrar? Muito importante para que se tenha uma boa refinement e boas estimativas!
No dia anterior à meeting envio um email à TODA A EQUIPE DE DESENVOLVIMENTO com as User Stories que farão parte da reunião. Em geral entre 4 e 7 dependendo do tamanho e complexidade que eu atribuo a elas.
As equipes tem tempo para analisar as User Stories e pensar com calma nos pontos que precisam ser discutidos/esclarecidos.
Com base nesta informação eles escolhem quem participará da Refinement. Não é necessário avisar quem estará presente.
7 – A reunião em si.
Costumo chegar a sala com 5 ou 10 minutos de antecedência para ligar o computador à tv e deixar a todas as User Stories preparadas para serem lidas, comentadas e estimadas.
Todos chegam e já começamos logo para ler/conversar sobre a primeira User Story. Eu as explico “de forma natural”. Uma conversa para que todos entendam o que eu tentei escrever nela.
Por vezes a equipe de desenvolvimento pede mudanças no texto para que fique mais claro. Já faço na hora quando possível, caso contrário adiciono um comentário à US para fazer depois mas, nestes casos, se a alteração na ideia da User Story não for muito grande, peço para que a equipe estime levando em consideração a alteração sugerida.
Caso seja grande, coloco a User Story de lado e trago ela novamente na próxima reunião.
Após a discussão “de produto” para o entendimento vamos ao processo de estimar e a equipe de desenvolvimento tem sua discussão técnica sobre o tema. Em geral uso o Planning Poker (assunto para outro Post).
Importante: A equipe técnica deve discutir de forma macro o que deve ser feito, caso eles estejam entrando em aspectos MUITO TÉCNICOS – no COMO fazer -, eu os interrompo pois este não é o objetivo da Refinement.
E seguimos este ciclo até que, as User Stories previstas para aquela Refinement terminem OU que o tempo da reunião se acabe.
Caso falte uma User Story e todos estejam conscientes que o tempo que nos resta é inferior ao necessário, terminamos a reunião antes do tempo e antes de estimarmos todas as User Stories.
8 – Considerações finais
Considero a Refinement a segunda mais importante “cerimônia do Scrum”, embora não seja oficialmente “do Scrum”.
A(s) primeira(s) Refinement(s) tendem a estenderem-se e a não estimar todas as User Stories previstas. Isso é normal e, como todo o processo Scrum melhora muito ao longo do tempo.
Já participei de Refinements em que 5 User Stories foram em 30 minutos, e de outras que a primeira levou 25 minutos e as demais foram estimados em 20 minutos.
Não se preocupe. Mantenha a regularidade das reuniões. Analise como melhorar a escrita para facilitar o entendimento. Após o final da reunião pergunte ao último desenvolvedor a sair da sala se ele acha que algo pode ser melhorado.
Interaja com todos. Aproxime-se deles. Entenda os pontos levantados por ele. Ajude para ser ajudado.
O meu mantra como P.O. é:
Tudo que eu faço na empresa, eu dependo que eles façam, portanto eles são a minha primeira preocupação. Não adianta ter as ideias mais fantásticas, o Backlog mais bonito, priorizado e estimado se você não consegue transformá-lo em realidade. Seja parceiro deles para que eles, se confiarem em ti, retribuam com parceria e claro, linhas de códigos bem feitas.
Coloquei aqui a minha ideia de Refinement Meeting e como a executo. Não é O JEITO CERTO ou como DEVE ser feita, mas posso garantir que funciona bem e foi – e é – bem aceita pelas equipes onde trabalhei.
Achou interessante? Tem dúvidas ou discorda de algo?
Me adicione ao 
e vamos conversar.
Outros dois posts relacionados à este: