O que é Estimativa por Afinidade e T-shirt Sizing?

A comparação relativa de trabalho antecede a expressão Estimativa por Afinidade e não possui criador único claramente estabelecido. A Agile Alliance descreve o agrupamento silencioso por semelhança e a escala de tamanhos de camiseta como variantes de estimativa relativa.

Mike Cohn documenta uma forma de agrupar rapidamente muitos itens do Product Backlog, podendo atribuir Story Points após a ordenação. O Scrum Guide 2020 não exige essa técnica nem T-shirt Sizing: os Desenvolvedores são responsáveis pelo dimensionamento dos itens, e a escolha do método depende da decisão que o time precisa apoiar.

Coloque itens do Backlog em cartões que tragam informação suficiente para uma primeira comparação. Escolha um item conhecido como referência e organize os demais do menor para o maior tamanho percebido, ou em grupos de semelhança. Pessoas podem mover cartões sem discutir cada um desde o início. Quando duas avaliações divergem, o grupo para e pergunta que premissa está diferente. A intenção é obter uma visão de conjunto com pouco custo de conversa.

O que significa tamanho? A equipe deve combinar se avalia esforço aproximado, complexidade, incerteza ou uma composição desses aspectos. Se uma pessoa compara horas de implementação e outra compara risco de integração, os grupos parecerão inconsistentes. Isso não quer dizer que uma esteja errada: a discordância mostra que a decisão precisa de um critério mais claro. O termo tamanho não determina, por si, quanto tempo o item levará no fluxo.

Categorias amplas. T-shirt Sizing usa nomes como PP, P, M, G e GG. Pode-se trabalhar com menos grupos quando uma distinção adicional não muda a decisão. P é pequeno apenas em relação aos itens e à experiência daquele time. Não converta M automaticamente em uma semana nem compare um G de equipes diferentes. A escala é uma linguagem de planejamento local, não uma unidade física.

Preparação leve. Um item sem problema, público ou resultado minimamente claro talvez não seja estimável com responsabilidade. Marque como “precisa explorar” em vez de forçar uma categoria. Não é necessário detalhar todo o Backlog para agrupá-lo; se só uma parte entrará no planejamento próximo, dê atenção maior a ela. Itens distantes podem mudar antes de serem feitos.

Rodada silenciosa e conversa seletiva. Uma forma de conduzir é deixar as pessoas posicionarem cartões por alguns minutos, sem debate. Depois, revisam os agrupamentos e discutem principalmente os itens movidos repetidas vezes, os extremos e os que ficaram fora de qualquer grupo. Essa ordem diminui o custo de falar longamente de cada item. O facilitador deve evitar transformar silêncio em votação secreta sem explicação: quando a diferença pode alterar a decisão, pergunte o motivo.

Referências ajudam. Separe exemplos recentes que o time conhece: um item concluído pequeno, outro médio e um grande. Compare o novo trabalho com esses exemplos. Se tudo vira G, talvez o conjunto precise de fatiamento ou as referências estejam mal escolhidas. Se quase todos viram P, talvez a escala não acrescente informação e dados de fluxo sejam suficientes.

Atribuir número é opcional. Algumas equipes param nas categorias de camiseta. Outras ordenam os grupos e depois associam Story Points para uma previsão baseada em histórico. Não há obrigação de fazer essa conversão. Se um grupo M contém itens muito diferentes, atribuir cinco pontos a todos só esconde a variação. Considere dividir o grupo ou manter uma faixa de tamanhos.

Relação com Planning Poker. Planning Poker dedica mais conversa a um item e pode ser útil quando a decisão depende de compreender riscos específicos. Afinidade privilegia velocidade de agrupamento do conjunto. Um time pode usar a técnica rápida para ordenar dezenas de opções e reservar conversa detalhada a poucos itens relevantes. O verbete Estimativa Ágil explica quando dimensionamento relativo ajuda e quando histórico de fluxo responde melhor.

Da categoria ao prazo. P, M e G não fornecem uma data. Para comunicar prazo, observe capacidade, fila, dependências e desempenho passado de itens comparáveis. Uma previsão pode ser feita com throughput ou outra informação, mas precisa explicitar premissas. Dizer “são dez itens M, portanto dez semanas” não decorre da escala. Os itens podem ter esperas diferentes e a quantidade de trabalho disponível pode mudar.

Evite transformar estimativa em desempenho. Se os números são usados para cobrar velocidade individual ou comparar times, pessoas terão incentivo para escolher categorias maiores ou menores conforme a política. A conversa deixa de revelar risco. Deixe claro para que a informação será usada e revise se ela ajudou a escolher, dividir ou priorizar. Caso contrário, pare de coletá-la.

Quando faz sentido. Há muitos itens a comparar, a decisão é de alto nível e a precisão de cada um acrescentaria pouco. Por exemplo, antes de uma conversa de portfólio, pode ser útil distinguir oportunidades pequenas e grandes. Já uma mudança crítica com dependência técnica merece investigação específica, não apenas uma camiseta. Se o Backlog tem poucos itens, uma conversa direta pode ser suficiente.

A prática deve caber na rotina do time. Não precisa de sala física, software especial ou consenso numérico perfeito. Um quadro compartilhado, cartões compreensíveis e regra de discussão bastam. O resultado é uma aproximação que pode ser refeita quando itens ganham prioridade ou mudam de escopo.

Imagine um time hipotético com 15 ideias para melhorar um serviço de agendamento. Ele precisa selecionar quais investigar no próximo mês, sem especificar todas. Três itens recentes servem de referência: corrigir uma mensagem curta, P; acrescentar um novo filtro de busca, M; integrar uma agenda externa, G. As categorias e números são apenas deste exemplo.

As pessoas posicionam silenciosamente os cartões. Nove ficam em P ou M; três parecem G; os outros três se movem várias vezes entre grupos. Um deles, “avisar paciente”, parecia P para quem pensou em mensagem na tela e G para quem incluiu SMS, e-mail e regras de consentimento. O grupo não tenta tirar a média. Divide a ideia em notificação na tela e canais externos, deixando a política de consentimento como pergunta a investigar.

Antes, a equipe passaria uma reunião inteira tentando calcular pontos para os 15 itens. Depois, tem um mapa aproximado e sabe quais ideias estão incompreendidas. O Product Owner usa a visão junto com valor, urgência e riscos para decidir o que discutir mais a fundo. Nenhuma categoria, sozinha, determina prioridade.

No mês seguinte, alguns itens mudam. A integração externa, antes G, pode ficar menor depois que uma API se torna disponível; uma mensagem aparentemente P pode exigir revisão legal. O time ajusta os grupos conforme aprende. O resultado da rodada antiga era útil para a decisão daquele momento, não um compromisso eterno de tamanho.

Num contexto fora de TI, uma equipe de atendimento poderia agrupar mudanças de processo: corrigir um texto padrão, redesenhar um formulário ou negociar uma nova política com outra área. A comparação relativa continua possível, mas referências e riscos são locais. Um P da equipe de software não equivale a um P do atendimento.

Cursos K21 recomendados