Postagens

Como Lidar com Discordâncias Durante Planning Poker

Um time ágil diverso sentado ao redor de uma mesa durante uma sessão de Planning Poker, mostrando cartas com diferentes estimativas demonstrando discordância, com um scrum master facilitando a discussão Você revela as cartas. Um desenvolvedor jogou um 3. Outro jogou um 13. A sala fica em silêncio por um segundo, então todos começam a falar ao mesmo tempo. Se você tem facilitado Planning Poker por algum tempo, você conhece bem este momento. A maioria dos scrum masters a trata como um problema a ser resolvido rapidamente. Chegar a um consenso, passar para a próxima story. Mas a discordância em si é a parte mais valiosa de toda a sessão. O hiato entre um 3 e um 13 significa que seu time mantém suposições fundamentalmente diferentes sobre o trabalho, e expor essas suposições antes do sprint começar é exatamente para o que a estimativa é. Aqui está como transformar essas discordâncias em melhores resultados de sprint em vez de tempo desperdiçado.

Por que discordâncias de estimativa são valiosas

Se seu time concordasse com cada estimativa imediatamente, você não precisaria de Planning Poker de jeito nenhum. Você poderia simplesmente ter uma pessoa atribuir números. A razão pela qual a revelação simultânea existe é especificamente para expor discordância. Quando as estimativas divergem, geralmente significa uma de três coisas: Complexidade oculta. Um desenvolvedor vê uma operação CRUD direta. Outro vê um caso extremo envolvendo concorrência ou uma integração frágil que precisará de manuseio cuidadoso. Sem a discordância, o time se comprometeria com a estimativa mais baixa e descobriria a complexidade no meio do sprint. Diferentes suposições sobre o escopo. "Construir o recurso de busca" significa busca de texto completo com filtros e paginação para um desenvolvedor e um simples dropdown de correspondência de string para outro. O hiato nas estimativas revela que os critérios de aceitação precisam ser esclarecidos antes do time começar a construir. Requisitos faltantes. Uma grande dispersão muitas vezes sinaliza que a story em si está incompleta. Quando alguém estima alto porque está levando em conta incógnitas que outros não consideraram, essas incógnitas precisam ser nomeadas e resolvidas.

A técnica de discussão do outlier

O movimento de facilitação mais eficaz durante planning poker é pedir aos outliers para falar primeiro. Após revelar as cartas, sempre comece com a pessoa que estimou mais alto e a pessoa que estimou mais baixo. Isso funciona por três razões:

1. Dá aos outliers a palavra. Em muitos times, a pessoa que jogou um 2 quando todos os outros jogaram um 8 permanecerá em silêncio a menos que seja especificamente convidada a explicar. Eles podem saber algo que ninguém mais considerou, ou podem estar entendendo mal a story. De qualquer forma, você precisa ouvi-los.
2. Previne que a maioria atropele os outliers. Se cinco pessoas jogaram um 8 e uma jogou um 2, o instinto natural é pressionar o outlier para se conformar. Começar com o outlier sinaliza que sua perspectiva importa independentemente dos números.
3. Foca a discussão. Em vez de um debate livre onde todos reafirmam seu raciocínio, você obtém um debate estruturado entre os dois extremos do espectro. O resto do time ouve e ajusta seu modelo mental.

Dois desenvolvedores de software tendo uma discussão respeitosa e engajada sobre uma tela de laptop, um apontando para a tela explicando sua abordagem técnica enquanto o outro ouve atentamente, com cartas de estimativa visíveis em um quadro branco

Como facilitar a discussão do outlier

Use esses prompts específicos para guiar conversas produtivas do outlier:

• Para o estimador mais baixo: "Caminhe-nos através de sua abordagem. Como essa story se parece em sua cabeça?"
• Para o estimador mais alto: "Que riscos ou complexidade você está vendo que podem não ser óbvios?"
• Para ambos: "Que suposições você está fazendo sobre o escopo?"
• Depois que ambos falam: "Alguém quer mudar sua estimativa baseado no que você acabou de ouvir?"

Depois revote. A maioria das vezes, o time converge após uma rodada de discussão do outlier porque a conversa revelou um malentendido de escopo ou um risco técnico que muda o modelo mental de todos.

Causas comuns de discordância

Entender por que as estimativas divergem o ajuda a resolver discordâncias mais rapidamente. Aqui estão os padrões que você verá com mais frequência:

Entendimento diferente do escopo

Esta é a causa mais comum. Dois desenvolvedores leem a mesma user story e imaginam trabalho completamente diferente. Um interpreta "adicionar notificações" como uma mensagem de notificação no app. Outro a interpreta como notificações por email com templates, rastreamento de entrega e gerenciamento de cancelamento de inscrição. Como resolvê-lo: Peça ao dono do produto para esclarecer o escopo no local. Se o PO não está na sala, estacione a story e leve-a para a próxima sessão de refinamento de backlog.

Diferentes abordagens técnicas

Dois desenvolvedores podem concordar com o escopo mas discordar sobre como construí-lo. Um planeja estender um serviço existente. Outro acredita que o serviço existente não pode suportar a carga e quer construir um novo. Como resolvê-lo: Isso não é um problema de estimativa; é uma decisão de design. Deixe o time discutir brevemente os tradeoffs e escolher uma abordagem. Se precisa de mais investigação, crie um spike e estime a story na próxima sessão.

Lacunas de experiência

Um desenvolvedor senior que construiu features similares antes estima um 3. Um desenvolvedor de nível médio que nunca tocou nessa parte da codebase estima um 8. Ambos são honestos, e ambos estão certos baseado em sua própria experiência. Como resolvê-lo: Estime para o time, não para o indivíduo. Pergunte: "Se um membro típico do time pegasse isso, quanto esforço seria?" Se apenas uma pessoa pode fazer o trabalho, esse é um risco de compartilhamento de conhecimento que vale a pena sinalizar, mas não deveria inflar a estimativa. A estimativa deveria refletir a complexidade inerente, não quem acontece de estar fazendo o trabalho.

Critérios de aceitação pouco claros

Quando stories são vagas, estimativas se tornam adivinhações. "Melhorar performance" sem um número objetivo. "Tornar o dashboard mais amigável" sem mockups. Essas stories não estão prontas para estimativa. Como resolvê-lo: Mande de volta. Stories que não podem ser estimadas devem retornar ao refinamento. Se você está vendo esse padrão frequentemente, o problema pode estar em como user stories são escritas. Você também pode usar um analisador de complexidade de estimativa para sinalizar stories insuficientemente especificadas antes de chegarem à mesa de estimativa.

Faça timebox de suas discussões de estimativa

É aqui que a maioria da facilitação falha. Uma discordância surge, a discussão é produtiva por dois minutos, e então se torna um debate de arquitetura de 15 minutos. O time estima quatro stories em uma hora em vez de doze. Defina um timebox duro de cinco minutos por story. Aqui está como aplicá-lo: Um close-up de cima de uma mesa de reunião com cartas de planning poker mostrando diferentes estimativas, um temporizador e notas adesivas com texto de user story, transmitindo debate de estimativa estruturado

Por que você nunca deve fazer média das estimativas

Quando um time não consegue concordar, é tentador dividir a diferença. "Temos um 5 e um 13, vamos chamar de 8." Isso parece justo e eficiente. Não é nenhum dos dois. Fazer média oculta a discordância em vez de resolvê-la. A pessoa que disse 13 tem informações sobre riscos ou complexidade que não desaparecem porque você escreveu 8. Quando o sprint começa, esses riscos ainda estão lá, e o time se comprometeu com uma estimativa que não reflete nenhuma perspectiva com precisão. Fazer média também derrota o propósito de usar uma escala não linear como Fibonacci. Os saltos entre valores (1, 2, 3, 5, 8, 13, 21) são intencionalmente grandes para forçar times em distinções significativas. Um 5 e um 13 não são "perto o suficiente para se encontrar no meio." Eles representam entendimentos fundamentalmente diferentes do trabalho. Para mais sobre por que escalas de story points são projetadas desta forma, veja nosso mergulho profundo. O que fazer em vez de fazer média:

• Use a técnica de discussão do outlier para expor a causa raiz da discordância
• Se você deve escolher um número sem consenso, vá com a estimativa mais alta. É mais seguro superestimar do que subestimar
• Se o hiato é extremo (por exemplo, 2 vs. 21), a story não está pronta. Mande de volta para refinamento

Use revelação simultânea para prevenir viés de âncora

Viés de âncora é a tendência de confiar muito na primeira informação que você ouve. Em estimativa, isso significa que o primeiro número falado em voz alta se torna a âncora para o pensamento de todos os outros. Se um desenvolvedor senior diz "isso parece um 3" antes das cartas serem reveladas, o resto do time inconscientemente se ajusta para esse número. Planning poker anônimo resolve isso garantindo que todas as estimativas sejam enviadas antes de qualquer uma ser revelada. Ninguém vê o número de mais ninguém até que todos se tenham comprometido. Isso não é apenas um bônus; é uma proteção estrutural contra um dos vieses cognitivos mais bem documentados em tomada de decisão. Ferramentas como Kollabe aplicam automaticamente revelação simultânea. As cartas permanecem ocultas até que cada participante tenha selecionado sua estimativa. Isso é significativamente mais confiável do que cartas físicas, onde alguém inevitavelmente revela cedo ou segura a carta em um ângulo. Times que carecem de segurança psicológica se beneficiam especialmente de estimativa anônima. Quando desenvolvedores juniors sentem que sua estimativa honesta poderia ser julgada por membros seniors do time, eles voltam para o que os seniors jogaram. O anonimato remove essa dinâmica completamente.

Quando parar de discutir e dividir a story

Às vezes uma discordância não é sobre malentendido. Ambos os lados entendem completamente a story, mas o trabalho é genuinamente complexo e incerto. Quando isso acontece, a resposta não é um debate mais longo. A resposta é dividir a story. Sinais de que uma story precisa ser dividida em vez de mais discussão:

• As estimativas abrangem mais de três valores de Fibonacci (por exemplo, 3 a 21)
• A discussão continua voltando para "depende de..." múltiplos cenários
• Diferentes partes da story poderiam ser entregues independentemente
• O time identifica áreas de risco distintas que poderiam ser isoladas

Como dividir efetivamente: Divida ao longo de linhas de valor, não camadas técnicas. "Construir a API" e "Construir a UI" não são divisões boas porque nenhuma entrega valor ao usuário sozinha. Em vez disso, divida por cenário do usuário: "Buscar por nome" e "Buscar com filtros avançados" cada um entrega algo que um usuário pode realmente usar. Após dividir, reestime cada peça. Você frequentemente encontrará que a soma das partes é maior que a estimativa original, e isso é bom. A estimativa original estava errada porque a story era muito grande para estimar com precisão. Stories menores são mais fáceis de estimar, construir e verificar.

A técnica de votação de confiança

Você discutiu os outliers, revotou e chegou a um número que o time aceita. Mas aceitação não é a mesma que confiança. A votação de confiança "punho de cinco" captura a diferença. Após chegar a consenso em uma estimativa, peça a cada membro do time para simultaneamente levantar um a cinco dedos:

Dedos	Significado
5	Totalmente confiante, sem preocupações
4	Confiante, incerteza menor
3	Aceitável, algumas reservas
2	Desconfortável, preocupações significativas
1	Fortemente em desacordo, não deve se comprometer

Se alguém mostrar um 1 ou 2, eles ganham 60 segundos para explicar sua preocupação. Frequentemente revela um risco que o time deve notar mesmo se a estimativa não mude, como uma dependência em outro time ou um pedaço de código legado que pode resistir a mudanças. Isso leva 15 segundos por story quando a confiança é alta e apenas adiciona tempo quando há uma preocupação que vale a pena ouvir. É uma rede de segurança de baixo custo contra discordância silenciosa.

Juntando tudo: um checklist de facilitação

Discordâncias durante planning poker não são um sinal de disfunção. Elas são o mecanismo através do qual seu time constrói entendimento compartilhado. O objetivo não é eliminar discordância. É ter um jeito estruturado de extrair a informação que a discordância contém e transformá-la em melhores estimativas e melhores resultados de sprint. Para uma visão mais ampla de abordagens de estimativa além de planning poker, veja nosso guia de técnicas de estimativa ágil.