No final do ano passado, durante um dos encontros da comunidade de Produto em Recife, estive em uma conversa com Thyago Thompson Veras Oliveira, especialista em agilidade, e Avelino Alonso, líder técnico da Clin, sobre as cerimônias de refinamento que ocorrem ao longo da sprint. Uma fala de Thyago ficou em minha mente: “O refinamento é uma cerimônia do time técnico, o Product Manager é apenas consultivo”.
Anteriormente, nossas cerimônias de refinamento funcionavam da seguinte forma:
- Eu abria o board;
- Abríamos uma das PBIs (Product Backlog Items) e eu explicava rapidamente aos desenvolvedores o que estávamos desenvolvendo, juntamente com os critérios de aceite;
- Com base nisso, o time de desenvolvimento discutia rapidamente o que precisava ser feito e o grau de complexidade;
- Ao final, o time estimava o esforço e passávamos para a próxima PBI.
Identificamos os seguintes problemas principais:
- Embora discutíssemos rapidamente o que precisava ser feito, não detalhávamos as PBIs em tasks claras;
- Aumento do risco de negligenciarmos complexidades que precisavam de uma discussão mais aprofundada, o que poderia causar problemas no meio da sprint e afetar a estimativa de esforço;
- O time como um todo não tinha uma visão clara de todo o trabalho necessário para completar uma task, o que resultava em dependência do desenvolvedor responsável pela task, já que os outros membros do time não compreendiam o caminho lógico que estava sendo seguido no código;
- A cerimônia ficava muito dependente de mim, como Product Manager.
Após conversas com Avelino e Thyago, iniciei um processo de transição em nosso refinamento. O primeiro passo foi começar a usar o refinamento para discutir a quebra de cada PBI em tasks. Expliquei aos desenvolvedores que queria mudar nossa dinâmica do refinamento e por que queria fazer isso. Durante esse período de transição, os desenvolvedores discutiam entre si e listavam as tasks, enquanto eu apenas as criava no board. O primeiro impacto que observei foi que, enquanto antes refinávamos 5 PBIs em uma hora, passamos a levar 1 hora para refinar apenas 1 ou 2 PBIs.
Continuei conduzindo os refinamentos dessa forma por cerca de 3 semanas, até que o time se familiarizasse mais com a nova dinâmica. Após esse período, em um dos refinamentos, Avelino se propôs a conduzir a cerimônia e detalhar ainda mais as tasks com o time, em vez de apenas escrever o título delas. Avançamos mais um nível, passando a quebrar as PBIs em tasks extremamente claras, com rascunhos ilustrativos de comunicação entre as partes da aplicação, definição de estrutura de tabelas, prints de cada componente do front-end, entre outros. “Repentinamente”, eu não era mais tão essencial na cerimônia e o time ganhou mais autonomia.
Principais benefícios
Os principais benefícios da abordagem descrita são:
Sprints mais fluídas
Com o novo refinamento, o time conseguiu mapear complexidades não previamente identificadas, o que possibilitou discussões sobre como contorná-las. Isso permitiu que o time enfrentasse desafios de forma mais eficiente durante a sprint. Além disso, como todos os membros estavam bem informados sobre as PBIs, suas dependências e o trabalho que precisava ser feito, caso algum desenvolvedor iniciasse o trabalho em uma PBI mas tivesse que se ausentar, outro membro poderia facilmente assumir o trabalho, garantindo a continuidade das atividades.
Maior autonomia do time
Com o PM atuando apenas em um papel consultivo nas cerimônias de refinamento, o time ganhou mais autonomia para tomar decisões e avançar com as atividades da sprint. Isso possibilitou que o time tocasse o trabalho mesmo em situações em que eu estivesse ausente ou ocupado com outras responsabilidades. Como resultado, o time se sentiu mais empoderado e dono do quadro de tarefas, o que melhorou a gestão das sprints e promoveu um maior senso de responsabilidade por parte dos membros do time.
Próximos passos
Acredito que ainda há espaço para aprimoramento em nosso processo. Um próximo ponto de melhoria que pretendo abordar refere-se a fornecer mais contexto ao time sobre o motivo pelo qual estamos desenvolvendo determinada funcionalidade. Durante conversas com os desenvolvedores, eles expressaram o desejo de entender melhor o porquê das funcionalidades e melhorias estarem sendo priorizadas.
Durante minhas interações com Caio Brandão, Product Manager no Passei Direto, ele compartilhou uma abordagem que achei sensacional. Basicamente, ele cria uma apresentação em PowerPoint com tópicos bem estruturados, seguindo um modelo sugerido pela Reforge, para apresentar o contexto ao time. Pretendo experimentar essa abordagem nas próximas semanas.
Leia também:
