Pontos de Historia no Agile: O Guia Completo para Estimativa Relativa

Pontos de historia sao uma unidade de medida para expressar o tamanho geral de um item do Product Backlog ou historia de usuario. Eles combinam esforco, complexidade e incerteza em um unico numero relativo - e sao um dos conceitos mais mal compreendidos no agile. Equipes que os utilizam bem entregam de forma mais previsivel. Equipes que os utilizam mal criam disfuncao. Este guia aborda como os pontos de historia realmente funcionam, como atribui-los, como se conectam com a velocidade e previsao, e os erros que voce precisa evitar.

Resposta Rapida: Pontos de Historia em Resumo

Aspecto	Pontos de Historia
O que medem	Tamanho relativo: esforco + complexidade + incerteza combinados
O que nao medem	Tempo em horas, produtividade individual ou valor de negocio
Escalas comuns	Fibonacci (1, 2, 3, 5, 8, 13, 21), Fibonacci Modificado (1, 2, 3, 5, 8, 13, 20, 40, 100)
Quem estima	Os Developers do Time Scrum (nao o Product Owner ou gestores)
Quando estimar	Durante o refinamento do Product Backlog ou Sprint Planning
Resultado principal	Velocidade - a media de pontos de historia concluidos por Sprint
Proposito principal	Planejamento de capacidade da Sprint e previsao de datas de release

O Que Sao Pontos de Historia?

Pontos de historia sao uma unidade de medida relativa. Eles nao correspondem a horas, dias ou qualquer quantidade fixa de tempo. Em vez disso, expressam o tamanho de um trabalho comparado a outros trabalhos que a equipe ja realizou antes.

Pense nisso como comparar distancias. Voce pode nao saber exatamente quantos quilometros separam duas cidades, mas pode afirmar com confianca que "a viagem ate a Cidade B e aproximadamente o dobro da distancia ate a Cidade A." Esse julgamento comparativo e o que os pontos de historia capturam.

Mike Cohn, que popularizou os pontos de historia no inicio dos anos 2000, os descreve como uma forma de expressar o tamanho geral de uma historia de usuario - combinando quanto trabalho esta envolvido, quao complexo o trabalho e, e quanta incerteza ou risco existe.

As Tres Dimensoes de um Ponto de Historia

Toda estimativa em pontos de historia reflete tres fatores:

1. Esforco (Volume de Trabalho)

Quanto trabalho bruto esta envolvido? Uma historia que exige alteracoes em 15 arquivos tem mais esforco do que uma que toca em 2 arquivos, mesmo que ambas sejam diretas.

2. Complexidade (Dificuldade)

Quao dificil e o trabalho? Uma historia envolvendo um algoritmo complexo ou tecnologia desconhecida e mais complexa do que uma que usa padroes bem conhecidos, mesmo que o volume de codigo seja similar.

3. Incerteza (Risco)

Quanto voce nao sabe? Uma historia que depende de uma API de terceiros que voce nunca usou carrega mais incerteza do que uma que usa seu proprio servico interno, mesmo que o esforco e a complexidade parecam iguais.

Um unico numero de ponto de historia combina todas as tres dimensoes. Por isso, duas historias com o mesmo esforco mas complexidade diferente devem ter valores de pontos diferentes. E por isso uma historia com alta incerteza recebe uma estimativa maior mesmo que o "caminho feliz" pareca pequeno - porque os caminhos infelizes podem ser caros.

Dimensao	Baixo	Medio	Alto
Esforco	Alteracoes em 1-2 arquivos, trabalho direto	Escopo moderado, 5-10 arquivos ou modulos	Escopo grande, preocupacoes transversais
Complexidade	Padroes bem conhecidos, equipe ja fez antes	Alguns padroes novos, curva de aprendizado moderada	Tecnologia desconhecida, desafios algoritmicos
Incerteza	Requisitos claros, sem dependencias externas	Algumas incognitas, mas delimitadas	Incognitas sobre incognitas, riscos de terceiros

Por Que a Estimativa Relativa Funciona Melhor Que Horas

Equipes que migram de horas para pontos de historia geralmente veem sua precisao de previsao melhorar em 4-6 Sprints. Eis o motivo:

Seres humanos sao ruins em estimativa absoluta. Se eu perguntar "Quantas horas essa funcionalidade vai levar?", sua resposta depende de quem faz o trabalho, quais interrupcoes acontecem e como os requisitos evoluem. Pesquisas em psicologia cognitiva mostram consistentemente que as pessoas superestimam tarefas simples e subestimam tarefas complexas ao estimar em termos absolutos.

Seres humanos sao bons em comparacao relativa. Se eu perguntar "Essa funcionalidade e maior ou menor que a funcionalidade de login que construimos na Sprint passada?", voce consegue responder rapida e precisamente. O efeito de ancoragem trabalha a seu favor - voce tem um ponto de referencia concreto.

Pontos de historia sao especificos da equipe, e isso e uma vantagem. Uma historia de 5 pontos na Equipe A pode levar 2 dias. A mesma historia de 5 pontos na Equipe B pode levar 4 dias. Tudo bem - cada equipe tem sua propria velocidade, que considera o ritmo especifico da equipe. Voce nunca compara pontos de historia entre equipes.

Pontos de historia absorvem naturalmente a incerteza. Quando voce estima em horas, sente pressao para ser preciso: "Isso vai levar exatamente 6 horas." Quando estima em pontos de historia, a escala e deliberadamente grosseira: "Isso tem mais ou menos o mesmo tamanho daquela outra historia de 5 pontos." A grossura e intencional - ela evita falsa precisao.

Escalas de Pontos de Historia

Escala Fibonacci

A escala padrao de pontos de historia segue a sequencia de Fibonacci: 1, 2, 3, 5, 8, 13, 21

Os intervalos entre os numeros crescem conforme os numeros aumentam. Isso reflete uma verdade fundamental sobre estimativa: quanto maior algo e, menos precisamente voce consegue estima-lo. A diferenca entre uma historia de 1 ponto e uma de 2 pontos e significativa e detectavel. A diferenca entre uma historia de 20 pontos e uma de 21 pontos nao e - por isso a sequencia de Fibonacci pula de 13 para 21 em vez de oferecer 14, 15, 16, 17, 18, 19, 20.

Escala Fibonacci Modificada

Muitas equipes usam uma versao modificada: 1, 2, 3, 5, 8, 13, 20, 40, 100

Essa escala substitui 21 por 20 (mais facil de raciocinar) e adiciona 40 e 100 para itens muito grandes que precisam ser divididos. No Planning Poker, as cartas tipicamente incluem 0 (sem esforco), 1/2 (trivial), e cartas especiais como infinito (grande demais) e ? (precisa de mais informacao).

Potencias de 2

Algumas equipes usam potencias de 2: 1, 2, 4, 8, 16, 32

Essa escala oferece menos opcoes, o que acelera a estimativa mas reduz a granularidade na faixa inferior. E menos comum que Fibonacci, mas funciona bem para equipes que desejam maxima simplicidade.

Como Atribuir Pontos de Historia: Passo a Passo

Passo 1: Escolha Sua Historia de Referencia

Escolha uma historia bem compreendida que a equipe ja tenha concluido. Deve ser de tamanho pequeno a medio - nao a coisa mais simples que voce ja fez, nem a mais complexa. Atribua um valor base, tipicamente 3 ou 5 pontos.

Essa historia de referencia se torna sua regua. Toda estimativa futura e uma comparacao com ela.

Passo 2: Defina Seus Pontos de Ancoragem

Crie 3-4 historias de ancoragem ao longo da escala:

Pontos	Exemplo de Ancoragem	Caracteristicas
1	"Adicionar uma tooltip a um botao existente"	Esforco trivial, complexidade zero, sem incerteza
3	"Adicionar um novo campo a um formulario existente com validacao"	Esforco moderado, baixa complexidade, incerteza minima
5	"Construir um novo endpoint de API com autenticacao"	Esforco significativo, complexidade moderada, alguma incerteza
8	"Integrar com um provedor de pagamento de terceiros"	Esforco grande, alta complexidade, incerteza notavel
13	"Redesenhar o sistema de notificacoes com push em tempo real"	Esforco muito grande, alta complexidade, incerteza significativa

Passo 3: Estime Usando Comparacao

Para cada nova historia, pergunte: "Comparada com nossas historias de referencia, qual o tamanho dessa?"

• "E maior ou menor que a historia de 5 pontos do endpoint de API?"
• "Tem mais ou menos a mesma complexidade que a integracao de pagamento de 8 pontos?"
• "E mais simples que a historia de 3 pontos do campo de formulario?"

Use Planning Poker para a sessao de estimativa. Cada Developer seleciona uma carta simultaneamente para evitar vies de ancoragem, e entao a equipe discute os valores discrepantes.

Passo 4: Discuta os Valores Discrepantes

Quando as estimativas divergem (digamos que uma pessoa mostra 3 e outra mostra 13), nao faca media - discuta. A divergencia quase sempre revela que os membros da equipe tem premissas diferentes sobre escopo, abordagem ou riscos.

Peca aos valores discrepantes que expliquem seu raciocinio:

• Estimador alto: "Que risco ou complexidade voce esta enxergando que o restante de nos nao esta?"
• Estimador baixo: "Que simplificacao voce esta assumindo que deveriamos saber?"

Essas conversas sao frequentemente a parte mais valiosa da estimativa - elas revelam requisitos ocultos e alinham o entendimento da equipe antes do trabalho comecar.

Passo 5: Defina um Limite de Divisao

Estabeleca um valor maximo de pontos acima do qual as historias devem ser divididas. A maioria das equipes define isso em 13 pontos. Qualquer coisa estimada em 13 ou acima e dividida em historias menores antes de entrar em uma Sprint.

Por que? Historias grandes tem alta incerteza por definicao. Dividi-las reduz o risco e melhora o fluxo. Uma historia de 13 pontos pode nao ser concluida em uma Sprint, mas tres historias de 5 pontos da mesma funcionalidade provavelmente verao pelo menos duas concluidas.

Pontos de Historia e Velocidade

Como a Velocidade Funciona

Velocidade e o numero total de pontos de historia concluidos em uma Sprint. Apenas historias que atendem a Definicao de Pronto contam. Historias parcialmente concluidas contribuem com zero para a velocidade.

Sprint	Pontos Planejados	Pontos Concluidos	Media Acumulada
Sprint 1	30	24	24
Sprint 2	28	28	26
Sprint 3	26	22	24,7
Sprint 4	25	27	25,3
Sprint 5	26	25	25,2
Sprint 6	25	26	25,3

Apos 6 Sprints, essa equipe tem uma velocidade media estavel de aproximadamente 25 pontos por Sprint.

Usando Velocidade para Sprint Planning

Durante a Sprint Planning, a equipe usa o "clima de ontem" - sua velocidade media recente - para decidir quanto trabalho puxar para a Sprint. Se a media e de 25 pontos, selecionam aproximadamente 25 pontos de itens do Product Backlog.

Velocidade e uma ferramenta de planejamento, nao uma metrica de desempenho. Ela informa quanto a equipe pode realisticamente realizar, para que voce planeje adequadamente. Ela nao informa se a equipe esta trabalhando duro o suficiente, rapido o suficiente ou bem o suficiente.

Usando Velocidade para Previsao de Release

Com velocidade estavel, voce pode prever datas de release:

Backlog restante: 100 pontos de historia Velocidade media: 25 pontos por Sprint Duracao da Sprint: 2 semanas Previsao: 4 Sprints (8 semanas) para completar o backlog restante

Adicione um buffer para incerteza. A maioria das equipes planeja entregar 80% de sua capacidade estimada, tornando a previsao realista de 5 Sprints (10 semanas).

Para previsoes mais sofisticadas, use uma faixa de velocidade (melhor caso, media, pior caso) para produzir uma faixa de datas em vez de uma unica data. Isso da aos stakeholders uma imagem mais honesta.

Pontos de Historia vs. Horas vs. Dias Ideais

Atributo	Pontos de Historia	Horas	Dias Ideais
Tipo de unidade	Relativa	Absoluta	Semi-relativa
O que mede	Tamanho (esforco + complexidade + incerteza)	Tempo de calendario para completar	Dias de trabalho ininterrupto
Precisao	Deliberadamente grosseira (escala Fibonacci)	Falsamente precisa ("exatamente 6 horas")	Moderada ("cerca de 2 dias ideais")
Depende da pessoa	Nao - equipe estima em conjunto	Sim - depende de quem faz o trabalho	Parcialmente - "ideal" e interpretado de forma diferente
Rastreamento de velocidade	Soma de pontos concluidos por Sprint	Soma de horas gastas (ou restantes)	Soma de dias ideais concluidos por Sprint
Melhor para	Planejamento de Sprint, previsao de release	Rastreamento no nivel de tarefa (dentro de uma historia)	Equipes em transicao do waterfall
Maior risco	Tratar pontos como horas	Microgerenciamento, pressao por "utilizacao"	Confusao entre dias ideais e reais

Pontos de historia e horas podem coexistir. Muitas equipes estimam historias em pontos de historia para fins de planejamento e depois dividem as historias em tarefas estimadas em horas durante a Sprint Planning. A estimativa em pontos de historia direciona a pergunta no nivel da Sprint "quanto conseguimos fazer?", enquanto a estimativa em horas direciona a pergunta "como devemos fazer?".

Tecnicas de Estimativa Que Usam Pontos de Historia

Tecnica	Melhor para	Tempo por item	Tamanho da equipe
Planning Poker	Refinamento no nivel de Sprint de 5-15 historias	2-5 minutos	3-9
Estimativa por Afinidade	Dimensionamento inicial de 50-200 historias	10-20 segundos	5-9
T-Shirt Sizing	Estimativa no nivel de roadmap	15-30 segundos	Qualquer
Sistema de Baldes	Dimensionamento em larga escala de 50-200 historias	10-30 segundos	5-15

Planning Poker e a tecnica mais comum para estimativa em pontos de historia. A equipe discute uma historia, cada Developer revela simultaneamente uma carta com sua estimativa, e o grupo converge para um valor consensual atraves de discussao.

Exemplos por Industria: Pontos de Historia na Pratica

Equipe de Produto SaaS

Uma equipe SaaS com velocidade estavel de 32 pontos por Sprint (Sprints de 2 semanas) usa pontos de historia para prever releases trimestrais. Suas historias de referencia incluem: correcoes de bug de 1 ponto, ajustes de funcionalidade de 3 pontos, novas funcionalidades de 5 pontos, integracoes de 8 pontos e mudancas arquiteturais de 13 pontos. Eles dividem qualquer coisa acima de 13 e usam faixas de velocidade (28-36) para previsao de datas de release.

Equipe de App Mobile

Uma equipe mobile estima separadamente para iOS e Android quando as funcionalidades diferem significativamente. Sua historia de referencia de 5 pontos e "adicionar uma nova tela com integracao de API e componentes de UI padrao." Eles rastreiam velocidade por plataforma e descobriram que iOS consistentemente apresenta velocidade 15% maior devido a ferramentas mais maduras, o que consideram no planejamento de release multiplataforma.

Equipe de Engenharia de Dados

Uma equipe de dados usa pontos de historia modificados para trabalho de pipeline. Suas historias de referencia sao especificas de pipeline de dados: 2 pontos para um novo conector de fonte de dados, 5 pontos para um pipeline de transformacao, 8 pontos para uma migracao de dados entre sistemas, 13 pontos para um novo dashboard analitico com feeds em tempo real. Descobriram que problemas de qualidade de dados adicionam incerteza que equipes de funcionalidades regulares nao enfrentam, entao sua velocidade e mais variavel.

Equipe Regulamentada de Saude

Uma equipe de saude inclui esforco de conformidade em suas estimativas de pontos de historia. Uma funcionalidade que toca em informacoes de saude do paciente (PHI) automaticamente recebe +3 pontos adicionados para documentacao HIPAA, logs de auditoria e revisao de seguranca. Sua velocidade e menor que equipes nao regulamentadas comparaveis, mas suas previsoes sao precisas porque o trabalho de conformidade esta embutido nas estimativas.

Equipe de Plataforma Empresarial

Uma equipe de plataforma que atende 5 equipes internas consumidoras rastreia pontos de historia mas tambem rastreia throughput (historias concluidas por Sprint) como metrica secundaria. Descobriram que suas estimativas de pontos de historia eram inconsistentes porque as historias variavam de mudancas de infraestrutura a desenvolvimento de API, entao mantem historias de referencia separadas para cada tipo de trabalho e reconciliam durante o planejamento.

Startup Remote-First

Uma startup totalmente remota de 6 desenvolvedores usa Planning Poker assincrono via Parabol. Cada desenvolvedor revisa as historias independentemente, submete estimativas dentro de uma janela de 24 horas, e apenas historias com divergencia significativa acionam uma discussao sincrona. Essa abordagem leva 30 minutos de tempo sincrono por semana em vez das 2 horas que seu Planning Poker presencial anterior exigia.

Modelo de Maturidade de Pontos de Historia

Estagio 1: Comecando (Sprints 1-4)

Caracteristicas:

• Sem dados historicos de velocidade
• Estimativas parecem arbitrarias - "isso e um 3 ou um 5?"
• Equipe superestima ou subestima consistentemente
• Historias frequentemente se arrastam para a proxima Sprint

No que focar:

• Estabeleca 3-5 historias de referencia e use-as em toda sessao
• Nao se preocupe com precisao - foque em consistencia
• Rastreie velocidade mas nao dependa dela ainda

Estagio 2: Calibrando (Sprints 5-10)

Caracteristicas:

• Dados de velocidade estao surgindo mas sao ruidosos
• Equipe esta comecando a concordar mais rapidamente nas estimativas
• Algumas historias ainda surpreendem (muito maiores ou menores que o estimado)
• Historias de referencia estao sendo atualizadas com base na experiencia

No que focar:

• Compare estimativas com resultados reais nas retrospectivas
• Identifique padroes: "Nos consistentemente subestimamos historias que envolvem X"
• Comece a usar velocidade para planejamento de capacidade da Sprint

Estagio 3: Estavel (Sprints 11-20)

Caracteristicas:

• Velocidade e previsivel dentro de uma faixa de 15-20%
• Sessoes de estimativa sao mais rapidas - a maioria das historias converge rapidamente
• Arrasto e raro (menos de 1 historia por Sprint)
• Equipe tem senso intuitivo do que cada valor de ponto significa

No que focar:

• Use faixas de velocidade para previsao de release
• Refine o limite de divisao com base nos padroes de conclusao
• Treine novos membros da equipe usando o catalogo de historias de referencia

Estagio 4: Otimizado (Sprint 20+)

Caracteristicas:

• Coeficiente de variacao da velocidade esta abaixo de 15%
• Estimativa leva tempo minimo - equipe frequentemente concorda sem discussao
• Previsoes sao precisas dentro de 10-15%
• Equipe pode comecar a questionar se a estimativa formal ainda e necessaria

No que focar:

• Considere migrar para previsao baseada em throughput (#NoEstimates)
• Use simulacao Monte Carlo para previsao probabilistica
• Concentre o tempo de estimativa apenas em historias de alta incerteza

10 Erros Comuns com Pontos de Historia

Erro #1: Tratar Pontos de Historia como Horas

O que acontece: A equipe ou gestao converte pontos em horas ("1 ponto = 4 horas"). Uma historia de 5 pontos deve levar 20 horas.

Por que e prejudicial: Isso destroi a natureza relativa dos pontos de historia. Reintroduz todos os problemas que a estimativa baseada em horas cria - estimativas dependentes do individuo, pressao para rastrear tempo e falsa precisao.

Solucao: Nunca defina uma conversao de pontos para horas. Se alguem perguntar "quantas horas tem uma historia de 5 pontos?", a resposta correta e "depende de quem trabalha nela, do que mais esta acontecendo e do que descobrirmos. A velocidade nos diz quantos pontos a equipe completa por Sprint."

Erro #2: Comparar Velocidade Entre Equipes

O que acontece: A gestao classifica equipes por velocidade: "Equipe A faz 40 pontos por Sprint e Equipe B so faz 25 - Equipe B precisa melhorar."

Por que e prejudicial: Pontos de historia sao especificos da equipe. "5 pontos" da Equipe A e "5 pontos" da Equipe B nao medem a mesma coisa. Compara-los e como comparar pontuacoes de videogames diferentes.

Solucao: A velocidade de cada equipe so tem significado para essa equipe. Se voce precisa de comparacoes entre equipes, use throughput (numero de historias concluidas) ou tempo de ciclo (tempo do inicio ate a conclusao), que sao medidas objetivas.

Erro #3: Usar Pontos de Historia como Metrica de Desempenho

O que acontece: Velocidade individual e rastreada ("Sarah completou 18 pontos nesta Sprint, mas Carlos so completou 12").

Por que e prejudicial: Cria incentivos perversos. Desenvolvedores inflam estimativas para parecerem mais produtivos. Colaboracao cai porque ajudar outra pessoa nao aumenta seu total pessoal de pontos. A confianca da equipe se deteriora.

Solucao: Pontos de historia medem producao da equipe, nunca producao individual. Se a gestao insiste em metricas individuais, use medidas diferentes (participacao em revisao de codigo, compartilhamento de conhecimento, taxas de defeitos) que nao distorcam o sistema de estimativa.

Erro #4: Estimar Bugs e Divida Tecnica

O que acontece: A equipe atribui pontos de historia a bugs: "Essa excecao de ponteiro nulo e um bug de 3 pontos."

Por que e prejudicial: Bugs sao inerentemente imprevisiveis. A "correcao" pode levar 20 minutos ou 2 dias dependendo da causa raiz. Atribuir pontos cria falsa previsibilidade. E se bugs contam para a velocidade, equipes sao incentivadas a criar mais bugs (mais velocidade!).

Solucao: Rastreie bugs por contagem, nao por pontos. Use uma alocacao de capacidade separada (ex.: "20% da capacidade da Sprint reservada para bugs") em vez de planejamento baseado em pontos para trabalho de defeitos.

Erro #5: Nunca Re-estimar

O que acontece: Uma historia estimada em 5 pontos durante o refinamento de backlog ainda e de 5 pontos quando entra na Sprint Planning tres meses depois, embora o entendimento da equipe tenha mudado.

Por que e prejudicial: Estimativas iniciais sao feitas com informacao limitada. Conforme a equipe aprende mais sobre o trabalho, a estimativa deve refletir esse aprendizado.

Solucao: Re-estime durante a Sprint Planning se o entendimento da equipe mudou significativamente. Isso nao e desperdicio - e empirismo.

Erro #6: Ancorar na Opiniao do Product Owner

O que acontece: O Product Owner diz "isso deveria ser facil, talvez um 2 ou 3" antes da equipe estimar.

Por que e prejudicial: A avaliacao de esforco do PO ancora o pensamento da equipe. Desenvolvedores que teriam estimado mais alto agora se sentem pressionados a concordar com o PO.

Solucao: O Product Owner apresenta a historia e responde perguntas, mas nunca sugere um valor em pontos. Apenas Developers estimam. Use revelacao simultanea (Planning Poker) para evitar que uma unica pessoa ancore o grupo.

Erro #7: Gastar Tempo Demais Estimando

O que acontece: A equipe debate se uma historia e 5 ou 8 por 15 minutos.

Por que e prejudicial: A diferenca de precisao entre 5 e 8 e minima a longo prazo - a velocidade absorve isso. Gastar 15 minutos debatendo e puro desperdicio.

Solucao: Se a equipe nao consegue concordar apos duas rodadas de Planning Poker (cerca de 3-5 minutos), va com a estimativa mais alta e siga em frente. A conversa sobre por que as estimativas divergem importa mais que o numero final.

Erro #8: Pressao por Velocidade

O que acontece: A gestao define metas de velocidade: "Precisamos atingir 35 pontos nesta Sprint."

Por que e prejudicial: Quando velocidade se torna um alvo, ela deixa de ser uma medida util. Equipes inflam estimativas para atingir o alvo (Lei de Goodhart), o que torna os dados sem sentido para previsao.

Solucao: Velocidade e descritiva, nao prescritiva. Descreve o que a equipe fez, nao o que deveria fazer. Gestores devem usar velocidade apenas para previsao, nunca para definicao de metas.

Erro #9: Ignorar Instabilidade de Velocidade

O que acontece: A velocidade de uma equipe oscila muito - 18, 35, 22, 40, 15 - mas eles planejam usando a media (26).

Por que e prejudicial: Alta variancia torna a media nao confiavel. Planejar com uma media nao confiavel leva a previsoes cronicamente nao atingidas.

Solucao: Acompanhe o coeficiente de variacao (desvio padrao / media). Se estiver acima de 25%, foque em estabilizar a velocidade antes de usa-la para previsao. Causas comuns de instabilidade: mudancas de escopo no meio da Sprint, disponibilidade inconsistente da equipe, historias que nao sao bem refinadas e definicoes variadas de "pronto."

Erro #10: Usar Pontos de Historia Sem Historias de Referencia

O que acontece: Cada sessao de estimativa comeca do zero sem ancora: "Entao... isso e um 5?"

Por que e prejudicial: Sem historias de referencia, estimativas derivam com o tempo. O que era um 5 tres meses atras se torna um 3 hoje, o que significa que tendencias de velocidade nao tem significado.

Solucao: Mantenha um catalogo de 5-8 historias de referencia nos valores chave de pontos (1, 2, 3, 5, 8, 13). Revise e atualize o catalogo trimestralmente. Novos membros da equipe devem estudar essas historias de referencia antes de sua primeira sessao de estimativa.

Quando Nao Usar Pontos de Historia

Pontos de historia nao sao a unica opcao, e nem sempre sao a melhor:

• Equipes muito pequenas (2-3 pessoas): O overhead da estimativa formal pode nao valer a pena. Essas equipes frequentemente sabem intuitivamente quanto trabalho cabe em uma Sprint.
• Trabalho altamente estavel: Se toda historia e aproximadamente do mesmo tamanho (como uma equipe de suporte processando tickets), contagem de throughput e mais simples e igualmente preditiva.
• Equipes maduras com throughput estavel: Algumas equipes experientes abandonam os pontos de historia completamente e preveem usando contagem de historias e taxas historicas de conclusao. Essa e a abordagem #NoEstimates.
• Equipes novas sem backlog: Se voce nao tem historias concluidas para referenciar, pontos de historia nao tem significado. Comece com T-shirt sizing ou estimativas baseadas em tempo, depois faca a transicao para pontos de historia apos 3-4 Sprints.

Conclusao

Pontos de historia funcionam quando as equipes entendem o que eles realmente medem - tamanho relativo, nao tempo - e os usam para seu proposito pretendido: planejamento de capacidade da Sprint e previsao de release. Eles falham quando organizacoes os tratam como metricas de produtividade, convertem para horas ou comparam entre equipes.

Principais conclusoes:

1. Pontos de historia combinam esforco, complexidade e incerteza em um unico numero relativo
2. Exigem historias de referencia - sem uma base, estimativas derivam e perdem o significado
3. Os intervalos crescentes da escala Fibonacci refletem a imprecisao inerente de estimar trabalhos maiores
4. Velocidade e a ponte entre pontos de historia e planejamento - ela informa quantos pontos a equipe realmente entrega por Sprint
5. Nunca converta pontos de historia em horas, compare velocidade entre equipes ou use pontos como metrica de desempenho
6. Historias estimadas em 13+ pontos devem ser divididas ao longo de limites funcionais antes de entrar em uma Sprint
7. Conversas de estimativa importam mais que o numero final - estimativas divergentes revelam premissas ocultas
8. Equipes maduras com throughput estavel podem superar os pontos de historia - e isso e perfeitamente aceitavel

Perguntas Frequentes (FAQs)