Como estimativas simultâneas, discordâncias estruturadas e discussões coletivas transformam o dimensionamento em uma atividade de compartilhamento de conhecimento - evitando ancoragem, consenso forçado e o erro de tratar Planning Poker como uma prática obrigatória do Scrum.
Tempo estimado de leitura: 20 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o propósito e a história do , explicar sua mecânica passo a passo, entender por que a escolha privada e a revelação simultânea importam, usar a discordância para revelar pressupostos ocultos, reconhecer como a técnica reúne o conhecimento do time, compreender suas limitações e antipadrões comuns e explicar claramente por que o é uma técnica opcional de , e não um requisito do .
Introdução: a discordância costuma ser o resultado mais valioso
Se cinco pessoas estimam um item como 3 e uma pessoa o estima como 13, o problema não é o fato de o time não ter chegado a um acordo. A oportunidade está em descobrir o que a pessoa que enxergou 13 sabe e os demais ainda não sabem.
Reuniões de estimativa podem falhar de maneiras previsíveis. O engenheiro mais sênior fala primeiro e todos tendem a se aproximar daquele número. Uma voz confiante domina enquanto especialistas mais reservados permanecem em silêncio. O time tira uma média de opiniões diferentes sem compreender por que elas divergem. Um debate prolongado tenta produzir uma estimativa irrealisticamente precisa. Por fim, as pessoas se cansam e escolhem um número apenas para seguir adiante.
O foi concebido para estruturar essa conversa de outra maneira. Sua forma moderna foi descrita por James Grenning em 2002, com base em ideias anteriores de estimativa por especialistas no estilo Delphi. Mike Cohn posteriormente popularizou a técnica por meio de Estimating and Planning. O método combina julgamento individual, revelação simultânea, discussão e nova estimativa.
A revelação simultânea é o mecanismo mais característico. Cada estimador forma um julgamento independente antes de ver a resposta de qualquer outra pessoa. Isso reduz a ancoragem - a tendência cognitiva de ajustar o próprio julgamento em direção ao primeiro número ouvido. Também torna visíveis as diferenças ocultas antes que a dinâmica do grupo as suavize.
As cartas não são o ponto central. Um baralho físico, uma ferramenta on-line, números ocultos em um chat, dedos ou outro mecanismo podem funcionar. O que importa é a escolha independente seguida de divulgação simultânea e de uma conversa significativa sobre as diferenças.
A discussão após a revelação é onde o gera a maior parte de seu valor. Uma estimativa alta pode revelar uma preocupação de segurança, um problema de migração, uma carga de testes, uma dependência externa ou uma incerteza que os demais não perceberam. Uma estimativa baixa pode revelar um componente existente ou uma implementação mais simples. O time passa a conhecer melhor o trabalho antes de chegar a um tamanho.
O também é fácil de usar de maneira inadequada. Times podem gastar tempo demais buscando consenso, calcular médias sem resolver a divergência, permitir que o vote no tamanho da implementação ou aplicar o ritual a todos os Items distantes. Nesses casos, a técnica se transforma em cerimônia em vez de aprendizado.
O não exige . O Scrum Guide estabelece que os que realizarão o trabalho são responsáveis por dimensionar os Items, deixando o método de em aberto. é uma técnica opcional que pode apoiar o quando a conversa justifica seu custo.
De onde veio o
O faz parte de uma história mais longa de estimativas estruturadas por especialistas. Na década de 1970, Barry Boehm descreveu o Wideband Delphi, uma abordagem colaborativa derivada dos métodos Delphi na qual especialistas estimam, discutem diferenças e revisam seus julgamentos.
James Grenning documentou a forma atual do em 2002. Mike Cohn então popularizou a técnica nas comunidades e , especialmente por meio de seu livro Estimating and Planning, de 2005.
O objetivo histórico não era criar uma cerimônia elaborada de estimativa. A Alliance observa que o formato estruturado e semelhante a um jogo foi concebido, em parte, para manter as discussões de estimativa em movimento, permitindo que o conhecimento de todos os membros do time influenciasse o resultado.
De onde veio o
Período
Influência
Contribuição
Década de 1970
Wideband Delphi / Barry Boehm
Estimativas estruturadas de especialistas são comparadas, discutidas e revisadas.
2002
James Grenning
Documenta a técnica moderna de .
2005
Mike Cohn
Populariza amplamente o por meio de Estimating and Planning.
Hoje
Times de produto
Usado presencialmente ou remotamente com , tamanhos de camiseta (T-shirt sizes) ou outras unidades locais de .
O objetivo do
O objetivo superficial é produzir uma estimativa de tamanho útil para um . O objetivo mais profundo é criar entendimento compartilhado.
A .org descreve o como uma prática que ajuda Teams a compreender Items e a adquirir um entendimento compartilhado de seu tamanho. Isso é importante porque uma estimativa produzida por um único especialista pode refletir apenas uma perspectiva.
Um grupo enxerga mais. Um Developer pode considerar a complexidade da implementação. Um tester pode perceber risco de regressão. Um especialista em segurança pode notar trabalho de compliance. Um designer pode revelar uma complicação no fluxo de interação. Um especialista em dados pode enxergar esforço de migração. O dá a cada uma dessas perspectivas uma voz independente inicial.
A estimativa final, portanto, não deve ser apenas um número de compromisso. Idealmente, ela representa uma visão compartilhada criada depois que diferenças importantes de entendimento foram expostas e discutidas.
Propósito central
O é valioso quando produz melhor entendimento compartilhado do trabalho, e não apenas quando produz um número.
Como funciona o
Como funciona o
Etapa
O que acontece
1. Selecionar um item
Escolha um importante e próximo o suficiente para justificar uma conversa detalhada de .
2. Esclarecer o item
O explica intenção, valor, restrições e trade-offs relevantes; os fazem perguntas.
3. Pensar de forma independente
Cada estimador escolhe um tamanho em particular, sem revelá-lo.
4. Revelar simultaneamente
Todas as estimativas tornam-se visíveis ao mesmo tempo.
5. Inspecionar a divergência
Se houver diferenças significativas, discute-se o raciocínio - especialmente as visões mais alta e mais baixa.
6. Reestimar
Cada Developer escolhe novamente em particular, usando as novas informações compartilhadas.
7. Convergir o suficiente
Registre uma estimativa útil quando o time tiver entendimento compartilhado suficiente, ou interrompa para refinar/dividir o item se a incerteza continuar alta demais.
Por que as estimativas são escolhidas em particular
O impede intencionalmente que os participantes vejam estimativas iniciais. Isso protege o pensamento independente.
Suponha que o primeiro Developer diga: 'Isso parece um 3.' Todos os demais agora têm uma âncora. Mesmo pessoas que inicialmente suspeitavam de 8 podem, inconscientemente, aproximar-se de 3. Participantes mais juniores podem evitar questionar um engenheiro sênior. Pessoas mais reservadas podem decidir que discordar não vale o custo social.
A escolha privada obriga cada estimador a formar uma posição antes de a influência social aparecer. O time obtém uma primeira distribuição de crenças muito mais informativa.
Isso não elimina todos os vieses. A conversa anterior ainda pode influenciar pressupostos, e os estimadores compartilham o mesmo contexto organizacional. Entretanto, a revelação simultânea remove uma fonte evidente e evitável de ancoragem: o primeiro número visível.
Por que a revelação simultânea importa
Ela preserva o julgamento independente tempo suficiente para que diferenças de entendimento se tornem visíveis.
Divergência é informação, não fracasso
Uma grande dispersão nas estimativas costuma ser o momento mais útil do . Ela sinaliza que os estimadores não estão imaginando o mesmo trabalho.
Se as cartas mostrarem 3, 3, 5, 5 e 13, calcular a média como 6 esconde a pergunta real: por que alguém enxergou 13? O estimador alto pode conhecer uma migração de dados difícil ou um ambiente de testes oculto. O estimador baixo pode conhecer uma biblioteca existente que elimina grande parte do trabalho.
A Alliance alerta contra transformar a convergência para um único número consensual em obrigação. Uma grande dispersão pode, por si só, comunicar incerteza. Forçar um acordo cedo demais apaga essa informação.
Um time saudável, portanto, discute primeiro os extremos significativos. A conversa deve tratar de pressupostos e do trabalho do produto, e não de convencer alguém a trocar sua carta.
Divergência é informação, não fracasso
Sinal
Possível significado
Estimativa alta pode revelar
Trabalho oculto, dependência, risco, edge cases, esforço associado à , tecnologia desconhecida ou incerteza.
Estimativa baixa pode revelar
Capacidade reutilizável, interpretação de escopo mais estreita, design mais simples, automação existente ou caminho de implementação conhecido.
Dispersão ampla e persistente pode significar
O PBI precisa de mais esclarecimento, refinamento, divisão, experimentação ou uma decisão do .
A discussão é o mecanismo de transferência de conhecimento
O é poderoso porque transforma diferenças em uma sessão estruturada de transferência de conhecimento.
Cada participante é levado a explicar o modelo mental por trás do número. Essas explicações frequentemente revelam pressupostos de produto, restrições técnicas, preocupações de teste e trabalho relacionado à que nunca estavam visíveis na descrição do PBI.
A conversa pode modificar o próprio PBI. O pode esclarecer um pressuposto. Os podem dividir um item grande. podem surgir. Um requisito desnecessário pode ser removido. Uma dependência pode ser movida para um experimento separado.
É por isso que o se encaixa naturalmente no . A técnica pode aumentar a transparência antes do , em vez de adiar a primeira conversa significativa até o início da .
Conhecimento coletivo não significa especialização igual
Um time se beneficia de muitas perspectivas, mas nem todas as pessoas têm o mesmo nível de especialização em todas as partes do trabalho.
O deve, portanto, dar voz a todos sem fingir que a especialização está uniformemente distribuída. A explicação de um especialista em segurança sobre risco criptográfico pode merecer mais peso técnico do que a intuição de um colega. Um designer pode ter evidências mais fortes sobre um problema de interação.
A finalidade da votação simultânea não é alcançar uma verdade democrática por maioria. É expor perspectivas para que o time possa raciocinar em conjunto.
Da mesma forma, a estimativa final não deve ser calculada mecanicamente pela média de todas as opiniões. Ela deve refletir o entendimento compartilhado que emerge da conversa.
Quem deve estimar?
No , os que realizarão o trabalho são responsáveis por dimensionar os Items. Essa accountability deve permanecer intacta quando o for utilizado.
O explica valor, contexto, restrições e trade-offs e pode responder a perguntas sobre o produto. Normalmente, o não vota no tamanho da implementação, a menos que também esteja atuando como Developer e realizando o trabalho.
O pode facilitar a técnica, mas não é dono da estimativa. Se o não estiver contribuindo para o trabalho do produto que está sendo dimensionado, não há motivo para acrescentar um voto de .
O termo é mais amplo do que programadores. Designers, testers, analistas, especialistas em dados, profissionais de segurança ou outras pessoas que fazem parte do e estão comprometidas em criar o utilizável podem contribuir com conhecimento de .
Limite oficial do
O não altera a accountability: os que realizarão o trabalho continuam responsáveis pelo .
e
O é frequentemente combinado com e , mas não é inseparável deles. Os times podem usar outras unidades de .
Baralhos típicos usam valores como 1, 2, 3, 5, 8, 13, 20, 40 e 100. Os intervalos crescentes reduzem a falsa precisão conforme o tamanho e a incerteza aumentam.
Um time também pode usar T-shirt sizes, ou outra escala local. A .org observa explicitamente que possíveis valores de podem incluir dedos, balas de goma ou T-shirt sizes. O símbolo específico importa menos do que uma comparação relativa consistente.
Se o time utilizar , continuam válidos todos os alertas da estimativa por pontos: pontos não são horas, não são valor do produto, não são produtividade individual e não são diretamente comparáveis entre times.
durante o
O costuma ser mais útil para Items suficientemente próximos para importar, mas ainda incertos o bastante para se beneficiarem de uma discussão coletiva.
Aplicar a técnica a todas as ideias distantes pode desperdiçar tempo. Items distantes têm maior probabilidade de mudar; portanto, um grosseiro ou até a ausência de uma estimativa detalhada pode ser mais econômico.
Para itens mais bem ordenados, o pode revelar se o PBI é pequeno e compreendido o suficiente para se tornar Done dentro de uma . Se as estimativas permanecerem enormes ou muito divergentes, mais refinamento ou divisão pode ser mais valioso do que novas rodadas.
O método, portanto, apoia o refinamento, mas não o substitui. é a atividade contínua mais ampla; é uma técnica opcional que pode ser usada dentro dessa atividade.
Não transforme em consenso forçado
O é frequentemente chamado de técnica baseada em consenso, mas 'consenso' deve significar entendimento compartilhado suficiente para usar a estimativa - e não crença universal de que um único número é perfeito.
Se cada rodada continuar até que todas as cartas sejam idênticas, o time pode gastar mais tempo otimizando a estimativa do que ela vale. Pior: a pressão social pode fazer a discordância desaparecer sem resolver a incerteza subjacente.
Um time pragmático pode aceitar uma faixa estreita depois de entender por que a diferença restante persiste. Pode selecionar uma estimativa útil, registrar uma observação sobre a incerteza, dividir a história ou realizar um pequeno item de descoberta.
O objetivo é uma decisão de suficientemente útil a um custo razoável.
Economia da estimativa
Não gaste uma hora melhorando uma estimativa que precisa apenas ser boa o suficiente para apoiar a próxima decisão de produto.
Limitações do
Limitações do
Limitação
Por que isso importa
Custo de tempo
Discutir itens um a um pode ser lento para um backlog grande.
Falso consenso
As pessoas podem se conformar apenas para encerrar a reunião.
Ritualização
O time pode se concentrar nas cartas e números enquanto o entendimento do produto continua fraco.
Itens grandes ou vagos
Poker não consegue salvar um PBI que precisa de decomposição ou esclarecimento.
Dinâmica de grupo
Personalidades fortes ainda podem dominar a discussão depois da revelação.
Fixação na estimativa
Stakeholders podem tratar o tamanho final como certeza ou compromisso.
Uso excessivo
O método pode desperdiçar tempo em itens de backlog distantes ou de baixo valor.
Atrito remoto
Ferramentas on-line ajudam, mas atenção, facilitação e qualidade da discussão continuam importantes.
Uso indevido de métricas
Quando vinculados a metas de velocity, pontos viram pressão de desempenho em vez de aprendizagem.
Quando não usar
Uma boa técnica é definida, em parte, por saber quando não utilizá-la.
Quando o PBI é obviamente pequeno e bem compreendido, uma rodada completa de poker pode não acrescentar informação significativa.
Quando o backlog contém centenas de ideias distantes, métodos mais rápidos e de granularidade mais ampla podem ser mais econômicos.
Quando o PBI é tão vago que os participantes não conseguem descrever o que está sendo estimado, o refinamento deve vir primeiro.
Quando o time já usa baseado em fluxo e PBIs dimensionados de forma adequada, uma estimativa detalhada em pontos pode acrescentar pouco valor.
Quando a discordância diz respeito a uma decisão ausente do , e não ao tamanho, obtenha a decisão em vez de votar repetidamente.
Quando uma incerteza crítica domina a estimativa, um experimento de descoberta pode gerar evidências melhores do que outra rodada de estimativa.
Exemplo prático - para uma alteração de rotação de certificados de API
Imagine um responsável por um API Gateway bancário. Durante o , o apresenta um PBI: 'Permitir que certificados de parceiros sejam rotacionados sem interromper o tráfego ativo de APIs.' O item está no topo do porque vários certificados expirarão nos próximos meses.
O explica o valor e o comportamento esperado: os parceiros devem conseguir introduzir um novo certificado antes que o antigo expire, ambos os certificados devem funcionar durante um período controlado de sobreposição, e o certificado antigo deve poder ser removido sem downtime.
Os fazem perguntas sobre audit logging, cadeias de certificados, invalidação de cache, monitoramento, rollback e se a configuração dos parceiros é armazenada centralmente. O time usa com uma escala Fibonacci modificada.
Todos escolhem em particular. As cartas revelam: 5, 5, 8, 8 e 13.
Em vez de calcular a média como 8, o time pergunta primeiro ao estimador de 13. Esse Developer explica que o gateway atualmente mantém em cache informações do Subject do certificado por vários minutos e que dois ambientes usam mecanismos diferentes de atualização do trust store. Portanto, uma rotação pode aparentar sucesso em um caminho e falhar em outro.
Um dos estimadores de 5 explica a estimativa mais baixa: recentemente eles construíram um mecanismo de chave dupla para outro recurso de segurança e acreditam que parte dele pode ser reutilizada. O time não havia considerado esse componente.
O esclarece que a primeira versão precisa dar suporte apenas a um padrão de integração de parceiro; um caminho legado mais raro pode ser tratado em um PBI posterior. Isso reduz o escopo.
O time discute o trabalho da : testes automatizados de certificados, eventos de auditoria, monitoramento, verificação de rollback e documentação são necessários. O caminho legado de trust store é dividido em outro item.
Uma segunda rodada revela 5, 5, 5, 8 e 5. O estimador de 8 restante explica uma incerteza sobre a invalidação de cache. Depois de uma breve discussão técnica, todos entendem a preocupação. O time registra 5 com uma pequena observação para verificar o comportamento do cache logo no início da implementação.
O valor do não foi o fato de cinco pessoas finalmente exibirem a mesma carta. O valor foi a divergência inicial ter revelado duas informações: um risco oculto de infraestrutura e um componente reutilizável já existente. O tornou-se menor e mais transparente.
Se o time tivesse simplesmente pedido ao Developer mais sênior uma estimativa primeiro, essas duas perspectivas talvez nunca tivessem surgido.
Antipadrões comuns do
Antipadrões comuns do
Antipadrão
Por que enfraquece a técnica
Pessoa sênior estima primeiro
Ancora todos antes que um julgamento independente seja formado.
Calcular a média das cartas
Esconde por que as pessoas enxergaram trabalhos diferentes.
Forçar consenso exato
Transforma incerteza em pressão social e desperdiça tempo.
vota no tamanho
Confunde accountability de produto com accountability dos pelo .
escolhe o número final
Transforma facilitação em estimativa de .
Usar Poker em todo
Gasta discussão cara em trabalho que provavelmente não será selecionado em breve.
Nenhuma discussão após divergência
Remove o mecanismo de compartilhamento de conhecimento que gera a maior parte do valor.
Debate longo sobre 5 versus 8
Otimiza precisão além do que a decisão exige.
Pontos ligados a metas de desempenho
As pessoas passam a estimar estrategicamente em vez de com transparência.
como requisito do
Transforma uma técnica opcional em uma falsa regra do .
Pegadinhas comuns da sobre
Pegadinhas comuns da sobre
Pegadinha
Interpretação correta do
é exigido pelo .
Falso. O não prescreve uma técnica de .
deve acontecer durante o .
Falso. Pode ser usado durante o refinamento ou sempre que os considerarem útil.
O determina a estimativa final.
Falso. Os que realizam o trabalho são responsáveis pelo .
O atribui a estimativa após a discussão.
Falso. O pode facilitar, mas não é dono do dos .
Todos os devem mostrar cartas idênticas antes de seguir em frente.
Falso. Entendimento compartilhado suficiente importa mais do que unanimidade numérica forçada.
A média de todas as cartas é a melhor estimativa.
Falso. Calcular a média pode esconder discordâncias importantes.
exige .
Falso. Ele pode usar outras unidades locais de .
exige Fibonacci.
Falso. Qualquer escala local útil pode ser escolhida.
elimina a incerteza.
Falso. Ele expõe e discute a incerteza; trabalho complexo continua incerto.
Uma grande dispersão significa que o time é ruim em estimar.
Falso. Ela pode revelar diferenças valiosas de conhecimento.
O especialista mais eloquente deve explicar primeiro em todas as rodadas.
Prática fraca. Estimativas altas e baixas devem ser ouvidas para revelar pressupostos diferentes.
substitui .
Falso. É uma técnica opcional que pode apoiar o refinamento.
Um framework de raciocínio para questões da sobre
Técnica opcional: a resposta preserva o fato de que o não exige ?
pelos : as pessoas que farão o trabalho são responsáveis pelo tamanho?
Escolha privada: cada estimador forma uma visão independente antes de ver as estimativas dos outros?
Revelação simultânea: as estimativas são expostas juntas para reduzir ancoragem?
Divergência: a discordância é tratada como informação, e não como fracasso?
Discussão: as estimativas altas e baixas explicam pressupostos, riscos e trabalho oculto?
Conhecimento coletivo: a técnica inclui perspectivas de entrega?
Sem consenso forçado: o objetivo é entendimento compartilhado suficiente, e não cartas idênticas a qualquer custo?
Refinamento: o apoia a transparência do PBI em vez de substituir o refinamento?
Economia: a técnica é usada quando o valor da discussão justifica o tempo gasto?
Heurística rápida para a prova
é uma técnica opcional de dos . Seu padrão definidor é: estimativas privadas, revelação simultânea, discussão de diferenças significativas e reestimativa.
Conclusão: as cartas são apenas um mecanismo para pensar melhor
O é memorável porque parece um jogo, mas seu desenho real é sério. Ele protege o julgamento independente tempo suficiente para que o time perceba onde seu entendimento diverge.
A história da técnica remonta a abordagens estruturadas de estimativa por especialistas, como Wideband Delphi. James Grenning documentou a forma moderna em 2002, e Mike Cohn ajudou a popularizá-la em toda a comunidade .
A mecânica é simples: esclarecer o item, estimar em particular, revelar simultaneamente, discutir divergências significativas e estimar novamente. Essa simplicidade importa porque o objetivo não é construir um processo caro de estimativa. É criar uma visão compartilhada de tamanho que seja suficientemente útil.
A revelação simultânea reduz influência prematura. O número inicial de uma pessoa sênior não consegue, silenciosamente, tornar-se a âncora do time. Membros mais reservados ganham uma voz visível antes do início da discussão.
A divergência é o motor do aprendizado. Uma estimativa alta pode revelar risco, trabalho oculto ou incerteza. Uma estimativa baixa pode revelar uma solução mais simples. Se o time calcular a média desses números sem compreendê-los, o falhou mesmo que tenha produzido um resultado organizado.
A técnica também tem limites. Pode ser lenta, ritualizada e distorcida pela dinâmica de grupo. Não deve ser usada em todo simplesmente porque o time possui cartas. Às vezes, uma conversa rápida de right-, dados de fluxo, T-shirt size ou nenhuma estimativa explícita é melhor.
Dentro do , o limite do framework é claro. Os que realizarão o trabalho são responsáveis pelo . é apenas uma das ferramentas que eles podem escolher. ,,, cartas Fibonacci e rodadas de consenso não se tornam obrigatórios porque um time utiliza .
Na minha avaliação, o é mais bem-sucedido quando o número final parece quase secundário. Se o time encerra a conversa entendendo melhor o trabalho, tendo exposto um risco importante, reduzido um pressuposto ou descoberto uma solução mais simples, a técnica já gerou valor. As cartas apenas tornaram esse aprendizado mais difícil de esconder.
Principais pontos
é uma técnica colaborativa de usada por muitos times .
Sua forma moderna foi documentada por James Grenning em 2002 e posteriormente popularizada por Mike Cohn.
A técnica tem raízes conceituais nas abordagens de estimativa por especialistas Delphi e Wideband Delphi.
O normalmente explica a intenção do PBI, seu valor e as restrições relevantes.
Os fazem perguntas até entenderem o suficiente para dimensionar com responsabilidade.
Cada estimador escolhe um valor em particular.
Todas as estimativas são reveladas simultaneamente para reduzir ancoragem e influência prematura.
Uma grande dispersão nas estimativas é informação útil sobre pressupostos diferentes ou incerteza.
Estimativas altas e baixas devem ser discutidas porque frequentemente revelam trabalho oculto ou opções mais simples.
Após a discussão, os podem reestimar.
O objetivo é obter entendimento compartilhado suficiente para uma estimativa útil, e não consenso numérico perfeito.
pode reunir conhecimento de diferentes disciplinas de entrega.
A técnica costuma ser útil durante .
pode usar , T-shirt sizes ou outras unidades locais de .
não exige , ou Fibonacci.
Os que realizarão o trabalho continuam responsáveis pelo .
deve ser usado seletivamente quando o aprendizado esperado justificar o custo da discussão.
