1693228378456E Book - Desmistificando Estimativas Ágeis V2

Anderson Hummel é um Agile Coach que auxilia profissionais
na transição para o mundo da agilidade. Quase 10.000 alunos

certificados em mais de 400 aulas pela Scrum Alliance nos
últimos anos como Certified Scrum Master e Certified Scrum
Product Owner nas Américas, Europa e Ásia.
Cocriador do agilidade.org e organizador do "Agilidade em
Debate", "Agility Day", Scrum Gathering São Paulo. Criador
das ferramentas: AgileArchitectureCanvas e Radar De Praicas
Ageis. Quase 20 anos de experiência na área de tecnologia da
informação, e dez anos de experiência em Agile e Scrum.
Professor “aposentado” de graduação e pós-graduação na
área de tecnologia há mais de 10 anos e mais de 3.000 alunos
de graduação e pós-graduação.
Atualmente mora em Goiânia e trabalha como Certified
Scrum Trainer, investidor e consultor de negócios que ainda
Caricatura feita por Erick Nastari divide o tempo entre esposa, filho, 2 cachorros e um Xbox.
Desmistificando as Estimativas Ágeis: de dog points a velocidade

Versão 2 de Agosto de 2003 em Português do Brasil distribuida pela Agile Academy
Escrito por Anderson Diniz Hummel
Revisado por Marcelo Ribeiro
2
Desmistificando as Estimativas Ágeis: De Dog Points a Velocidade © 2023 by Anderson Diniz Hummel is licensed under Attribution-
ShareAlike 4.0 International. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/
Sumário
Estimativas ...............................................................................................................................................4
Precisão vs Acurácia .............................................................................................................................5
Cone da Incerteza ................................................................................................................................6
Os problemas mais comuns de estimativas no ágil .............................................................................8
Como estimar o custo de um projeto? ..................................................................................................10
Margem de Erro Inferior e Superior ..................................................................................................10
Como quantificar o tamanho de um item?............................................................................................15
Referencial Temporal .........................................................................................................................15
Comparação .......................................................................................................................................15
Como estimar vários itens rapidamente? ..............................................................................................18
Método Delphi ...................................................................................................................................18
Planning Poker ...................................................................................................................................19
Método de estimativa de três pontos ...............................................................................................20
Estimativa por afinidade / Affinity Estimation ...................................................................................21
Protocolo de ordenação.....................................................................................................................21
Dot Votting .........................................................................................................................................22
Tamanho Máximo Permitido (Maximum allowable size) ..................................................................23
Grande, Incerto e o Pequeno (Big, Uncertain, Small) ........................................................................23
Bucket Estimation ..............................................................................................................................24
Referencias.........................................................................................................................................26
Quanto trabalho podemos nos comprometer em uma janela de tempo? ...........................................27
Análise de Restrições e preparação ...................................................................................................27
Estimativa Unitária ou Estimativas dos Itens Sozinhos ......................................................................29
Avaliação de Quanto Trabalho Pode-se Entregar ..............................................................................31
Estamos atrasados? ...............................................................................................................................34
Curto Prazo.........................................................................................................................................34
Longo Prazo ........................................................................................................................................35
Referencias.........................................................................................................................................35
3
Estimativas
No mundo ágil, a capacidade de estimar de forma eficaz é crucial. Mas, o que exatamente
entendemos por "estimativa"?
Estimativas são uma tentativa de prever ou calcular, de forma aproximada, valores, quantidades,
resultados ou dimensões com base em informações limitadas ou incertas. Elas são a ponte entre o
desconhecido e o planejado, permitindo-nos preparar, organizar e ajustar as expectativas.
Não é exagero dizer que, em muitos casos, o sucesso ou fracasso de um projeto pode depender da
qualidade das estimativas feitas no início e ao longo do caminho.
Ainda que o conceito de estimar seja familiar, visto que é algo presente em diversos contextos e
situações de nosso dia a dia – desde decidir quanto tempo levará para chegar ao trabalho até quanto
dinheiro guardar para uma viagem de férias –, no ambiente ágil, ele assume características e desafios
particulares.
Neste capítulo, vamos explorar mais profundamente o universo das "Estimativas Ágeis".
Começaremos pelas "Estimativas do Dia a Dia", onde entenderemos como as previsões comuns se
relacionam e diferem das estimativas em um contexto ágil. Em seguida, abordaremos a crucial
distinção entre "Precisão vs Acurácia", a qual muitos profissionais confundem, mas que possui
implicações significativas em como avaliamos e refinamos nossas estimativas. E, por fim, navegaremos
pelo "Cone da Incerteza", um conceito fundamental que ilustra como nossas estimativas evoluem e se
tornam mais confiáveis à medida que um projeto avança.
Prepare-se para uma jornada de descoberta, onde o objetivo não é apenas prever o futuro, mas
fazê-lo com consciência, adaptabilidade e, acima de tudo, uma abordagem ágil.
Aqui estão alguns exemplos de estimativas no cotidiano:
Orçamento doméstico: As pessoas estimam suas despesas mensais, como aluguel, contas de água,
eletricidade, alimentação e transporte, para planejar e controlar seus gastos.
Tempo de viagem: Ao planejar uma viagem, as pessoas estimam quanto tempo levará para chegar
ao destino, considerando a distância, o meio de transporte e as condições de tráfego.
Previsão do tempo: Meteorologistas fazem estimativas sobre as condições climáticas futuras, como
temperatura, precipitação e velocidade do vento, usando modelos matemáticos e dados históricos.
Preço de produtos ou serviços: Empresas estimam o custo de produção e o preço de venda de seus
produtos ou serviços, levando em consideração fatores como concorrência, demanda e custos de
produção.
Tempo necessário para concluir uma tarefa: No ambiente de trabalho, pessoas estimam o tempo
necessário para concluir projetos ou tarefas específicas, o que ajuda no planejamento e na alocação
de recursos.
Estimativa de público em eventos: Organizadores de eventos estimam a quantidade de público
esperado com base em eventos anteriores, promoção e interesse geral no evento.
Esses exemplos ilustram como as estimativas são uma parte essencial da tomada de decisões e do
planejamento em várias esferas da vida.
4
Precisão vs Acurácia
Precisão e acurácia são dois conceitos importantes relacionados à estimativa e medição, e é
essencial entender a diferença entre os dois para interpretar corretamente os resultados das
estimativas.
Acurácia refere-se à proximidade de uma estimativa ou medição em relação ao valor verdadeiro ou
real. Uma estimativa ou medição altamente precisa está muito próxima do valor real. Acurácia é sobre
acertar o alvo, ou seja, estar o mais próximo possível do valor verdadeiro.
Precisão, por outro lado, refere-se à consistência das estimativas ou medições quando repetidas
várias vezes. Se várias estimativas ou medições forem feitas e os resultados estiverem muito próximos
uns dos outros, essas estimativas são consideradas precisas. A precisão está relacionada com a
dispersão dos resultados, ou seja, a consistência entre as repetições das medições.
Para entender melhor a relação entre acurácia e precisão, vamos considerar quatro arqueiros cada
um representando uma combinação diferente de precisão e acurácia.
Legolas - Alta precisão e alta acurácia Legolas, o elfo arqueiro da trilogia "O Senhor
dos Anéis", é conhecido por sua habilidade excepcional com o arco e flecha. Quando
ele atira flechas em um alvo, elas atingem consistentemente o centro. Isso indica
que Legolas tem alta precisão, pois suas flechas estão sempre agrupadas próximas
umas das outras, e alta acurácia, pois estão perto do valor real (o centro do alvo).
Katniss Everdeen - Baixa precisão e alta acurácia Katniss Everdeen, a protagonista

da série "Jogos Vorazes", tem alta acurácia, o que significa que suas flechas, em
média, atingem perto do centro do alvo. No entanto, suas flechas estão dispersas
ao redor do centro, o que indica baixa precisão.
Gavião Arqueiro - Alta precisão e baixa acurácia Gavião Arqueiro, o habilidoso

arqueiro da Marvel Comics e membro dos Vingadores, tem alta precisão, o que
significa que suas flechas estão sempre agrupadas próximas umas das outras. No
entanto, neste cenário, Gavião Arqueiro consistentemente atinge um ponto fora do
centro do alvo, demonstrando baixa acurácia.
Chapolin Colorado - Baixa precisão e baixa acurácia Chapolin Colorado, o herói

cômico da série de televisão mexicana, tem baixa precisão e baixa acurácia neste
exemplo. As flechas de Chapolin estão espalhadas por todo o alvo, e não há um
padrão claro ou consistência em seus tiros. Além disso, a média de suas flechas está
longe do centro do alvo, o que indica baixa acurácia.
Esses exemplos ilustram as diferenças entre acurácia e precisão e como elas se aplicam a
diferentes situações. No contexto de estimativas, é importante ter em mente que ambos os
conceitos são importantes para obter resultados confiáveis e úteis.
5
Ao fazer estimativas, é importante buscar tanto acurácia quanto precisão. A acurácia ajuda a
garantir que a estimativa seja "correta", enquanto a precisão ajuda a reduzir a incerteza e a
variabilidade das estimativas. No entanto, é importante lembrar que estimativas são, por natureza,
incertas e baseadas em informações limitadas. Portanto, pode ser difícil alcançar alta acurácia e
precisão em todas as situações.
Em projetos ágeis, o objetivo das estimativas é alcançar alta acurácia, garantindo que o esforço
necessário para concluir as tarefas seja previsto de forma mais próxima possível do real. No exemplo
dos arqueiros, Legolas e Katniss Everdeen são representativos de equipes ágeis com alta acurácia em
suas estimativas. Embora Legolas também tenha alta precisão, o mais importante é a acurácia, como
demonstrado por Katniss, cujas estimativas podem variar, mas ainda assim acertam a média real
necessária para concluir as tarefas. Portanto, equipes ágeis devem se esforçar para melhorar a acurácia
de suas estimativas, o que, por sua vez, leva a um melhor planejamento e execução de projetos.
Ter baixa acurácia nas estimativas em projetos ágeis, como demonstrado pelos exemplos de Gavião
Arqueiro e Chapolin Colorado, é problemático porque leva a resultados imprecisos em relação ao
esforço real necessário para concluir as tarefas. Quando as estimativas estão consistentemente fora
do alvo, isso pode causar atrasos no projeto, aumento de custos e frustração da equipe e das partes
interessadas. Além disso, a baixa acurácia torna difícil para a equipe planejar e gerenciar recursos de
forma eficiente. Portanto, é crucial que as equipes ágeis busquem melhorar a acurácia de suas
estimativas para garantir a entrega bem-sucedida e oportuna de projetos, mantendo a confiança e a
satisfação de todas as partes envolvidas.
Cone da Incerteza
O Cone da Incerteza é um outro conceito importante e que ajuda a clarificar o conceito de um
estimativa. O Cone da Incerteza é um modelo visual que representa a diminuição da incerteza ao longo
do tempo ao se fazer estimativas no geral. O modelo tem a forma de um cone que se estreita à medida
que o tempo avança, ilustrando como a incerteza diminui e a precisão das estimativas melhora
conforme o tempo passa ou o evento a ser previsto está mais próximo.
Cone da incerteza e a previsão do tempo

A previsão de tempestades e fenômenos meteorológicos também está sujeita à incerteza,
especialmente quando se trata de prever eventos futuros com antecedência.
No contexto meteorológico, o Cone da Incerteza pode ser usado para representar a incerteza na
trajetória e intensidade da tempestade à medida que se desloca do Canadá em direção à Islândia. No
6
início da previsão, quando a tempestade está se
formando, há muitas variáveis desconhecidas, como a
temperatura, a umidade, a pressão atmosférica e a
interação com outras massas de ar e sistemas
meteorológicos. Isso resulta em uma maior incerteza na
previsão da trajetória e intensidade da tempestade.
À medida que a tempestade avança e os
meteorologistas coletam mais dados e informações, a
incerteza na previsão da trajetória e intensidade da
tempestade diminui. Isso significa que o cone se
estreita, indicando uma maior precisão na previsão da
posição e intensidade da tempestade.
No entanto, é importante observar que, mesmo com o Cone da Incerteza, as previsões
meteorológicas não são perfeitas e sempre haverá algum grau de incerteza. A ideia do cone é ajudar a
comunicar essa incerteza aos tomadores de decisão e ao público em geral, permitindo que eles
compreendam os riscos associados à tempestade e tomem medidas apropriadas para se prepararem.
Em resumo, o Cone da Incerteza pode ser aplicado à previsão de tempestades, como uma
tempestade que se inicia no Canadá e pode chegar à Islândia, para ilustrar a incerteza na trajetória e
intensidade do fenômeno meteorológico à medida que mais informações são coletadas e o evento se
aproxima.
Cone da incerteza no desenvolvimento cascata

Barry Boehm, em seu livro de 1981 intitulado
"Software Engineering Economics", apresentou
o conceito Curva do Funil, precursor do do Cone
da Incerteza, como parte de seu modelo de
custo de software, o COCOMO (Constructive
Cost Model). No livro ele descreveu a curva do
funil e como o erro nas estimativas de custo e
esforço de projetos de software diminuem à
medida que o projeto avança. Esse curva é a
precursora do que conhecemos hoje como Cone
da Incerteza.
No livro "Software Project Survival Guide", de
Steve McConnell, o Cone da Incerteza é
apresentado como uma ferramenta para entender e gerenciar a incerteza nas estimativas de projetos
de software. O conceito é semelhante ao descrito por Barry Boehm, mas McConnell enfatiza a
importância do Cone da Incerteza na comunicação das estimativas e na gestão do projeto.
Conforme descrito pelo Steve McConner, a incerteza é maior na fase de concepção, quando a
equipe possui pouco conhecimento sobre o escopo, a complexidade e os desafios do projeto.
Consequentemente, o cone é mais largo nesta etapa.
À medida que o projeto avança para a fase de planejamento, a incerteza diminui à medida que a
equipe detalha os requisitos, a arquitetura e as funcionalidades do projeto. Como resultado, as
estimativas se tornam mais precisas e o cone se estreita. Durante a fase de execução, a equipe ganha
7
mais informações e experiência, o que leva a uma diminuição adicional da incerteza e a uma melhoria
na precisão das estimativas.
A fase de teste e integração apresenta ainda menos incerteza, pois a equipe tem uma visão clara
do progresso e dos desafios enfrentados. As estimativas são ajustadas e o cone se estreita ainda mais.
Finalmente, na fase de implantação e manutenção, a incerteza é mínima, e as estimativas são as mais
precisas possíveis, com o cone no seu ponto mais estreito.
Os problemas mais comuns de estimativas no ágil

A seguir são descritos os problemas mais comuns relacionados a estimativas de desenvolvimento
de software e o impacto no dia a dia das equipes
Como estimar o custo de um projeto?

Em uma empresa de desenvolvimento de software, uma nova solicitação de projeto é recebida para
construir um aplicativo de gestão de estoque. A equipe precisa estimar o custo do projeto, mas o
escopo e os requisitos ainda não estão bem definidos. Isso pode levar a estimativas imprecisas,
resultando em orçamentos inadequados, falta de recursos e possíveis atrasos no projeto. A falta de
clareza nos custos pode causar tensão entre a equipe, os stakeholders e os clientes. Além disso, se os
custos não forem estimados corretamente, a empresa pode perder dinheiro ou ter dificuldades em
cumprir os prazos estabelecidos.
Como quantificar o tamanho de um item?

Uma equipe de desenvolvimento está trabalhando em um projeto com várias funcionalidades
interdependentes. Eles enfrentam dificuldades para estimar o tamanho de um item específico devido
ao nível de detalhe e ao impacto que terá em outros itens do projeto. A incapacidade de estimar
adequadamente o tamanho de um item pode levar a problemas de planejamento, priorização e na
gestão de expectativas da área de negócio. Isso pode causar atrasos, retrabalho e possíveis conflitos
entre os membros da equipe.
Como estimar vários itens rapidamente?

Um projeto de software envolve o desenvolvimento de várias funcionalidades e a integração de
diversos sistemas. A equipe tem dificuldades em estimar o tamanho de todos os itens, já que alguns
são dependentes de outros e podem ter impactos desconhecidos, além do tempo necessário para
estimar os itens de um projeto pode ser tão grande que ao finalizar a estimativa as prerrogativas da
estimativa não faz mais sentido.
Quanto trabalho podemos nos comprometer em uma janela de tempo?

Em uma equipe de desenvolvimento, os membros estão trabalhando em vários projetos
simultaneamente. Eles têm dificuldades em estimar a quantidade de trabalho que podem assumir sem
sobrecarregar a equipe e comprometer a qualidade do projeto. A incapacidade de estimar
adequadamente a carga de trabalho pode levar à sobrecarga dos membros da equipe, o que pode
resultar em baixa qualidade do trabalho, atrasos e possíveis falhas no projeto.
Estamos atrasados?
Um projeto de desenvolvimento de software está em andamento há algum tempo, e a equipe
começa a perceber que não está progredindo conforme o esperado. Eles têm dificuldades em
determinar se estão atrasados e em identificar as causas do atraso. Quando a equipe não consegue
8
identificar se está atrasada, pode haver falta de comunicação e responsabilização. Isso pode levar a
problemas com os stakeholders e os clientes, que esperam entregas pontuais e de alta qualidade. Além
disso, a incerteza sobre o progresso do projeto pode causar estresse e desmotivação entre os membros
da equipe.
9
Como estimar o custo de um projeto?
No âmbito das estimativas ágeis, entender o custo de um projeto não é apenas uma questão de
calcular despesas financeiras, mas sim de prever recursos, tempo e esforço necessários para alcançar
os objetivos desejados. Este capítulo se dedica a fornecer uma visão aprofundada de como abordar a
estimativa de custos de um projeto, mesmo quando se está munido de informações limitadas.
Estimativas precisas não são apenas números em um papel; são instrumentos de planejamento,
guias para tomada de decisão e referências para avaliar o progresso. Ao considerar a variação inerente
em estimativas - representada aqui através das margens de erro superior e inferior - este capítulo
apresenta uma metodologia robusta que integra técnicas consolidadas, como uma adaptação do
Método Delphi, com abordagens contextualizadas de cálculo de margem de erro.
Através deste capítulo, você ganhará insights sobre:
• Como estruturar e realizar estimativas baseadas em consensos colaborativos, com foco no
custo dos itens de um projeto.
• Abordagens diferentes para calcular a margem de erro, que podem ser ajustadas conforme
o estágio do projeto e a quantidade de informações disponíveis.
• Exemplos práticos que ilustram a aplicação dessas técnicas em cenários reais de projetos.
Ao final desta leitura, espera-se que você esteja mais bem equipado para enfrentar os desafios de
estimar custos em ambientes ágeis, com uma abordagem sistemática que respeita a dinâmica e a
incerteza dos projetos modernos.
Margem de Erro Inferior e Superior

A seguir será descrito uma forma para estimar custo em um escopo de um projeto e tendo pouca
informação. Basicamente o custo de cada item será estimado da seguinte maneira.
𝐶𝑢𝑠𝑡𝑜 𝑑𝑜 𝐼𝑡𝑒𝑚 ± 𝑀𝑎𝑟𝑔𝑒𝑚 𝑑𝑒 𝐸𝑟𝑟𝑜
Para estimar o custo do item será utilizado uma adaptação do Método Delphi e para estimar
margem de erro vão ser explicados diferentes estruturas de referência
Custo do Item
Uma adaptação do método Delphi para estimar vários itens de um projeto em seu início pode ser
feita da seguinte forma:
1. Seleção de especialistas: Identifique um grupo diversificado de especialistas com
conhecimento e experiência relevantes no domínio do projeto, incluindo áreas específicas
relacionadas aos itens que precisam ser estimados. O tamanho ideal do grupo varia, mas
geralmente varia de 5 a 50 participantes.
2. Criação de uma lista de itens: Liste todos os itens do projeto que requerem estimativas,
incluindo requisitos, funcionalidades e componentes do sistema. Certifique-se de que os itens
sejam claros e compreensíveis para os especialistas envolvidos.
3. Primeira rodada de questionários: Crie um questionário anônimo no qual os especialistas
sejam solicitados a fornecer suas estimativas individuais para cada item da lista. As perguntas
devem abordar aspectos como tempo, custo e recursos necessários para cada item. Pode se
10
optar por perguntar apenas o tempo e depois converter o tempo em custo. Pode ser utilizada
a unidade de medida de semanas de desenvolvimento de uma equipe inteiramente alocada.
4. Coletar e analisar respostas: As respostas são coletadas e analisadas por um facilitador.
Estatísticas como média, mediana e intervalos são calculadas para cada item do questionário.
5. Segunda rodada de questionários: O facilitador fornece um resumo dos resultados da
primeira rodada, incluindo as estatísticas calculadas para cada item, e solicita que os
especialistas revisem suas estimativas iniciais à luz das respostas agregadas. Os especialistas
podem ajustar suas estimativas e fornecer justificativas para suas escolhas.
6. Rodadas adicionais: Repita as rodadas de questionários e análise até que um consenso seja
alcançado ou que as rodadas adicionais não resultem em mudanças significativas nas
estimativas para os itens listados.
7. Consolidar resultados: Calcule a média ou mediana das estimativas finais para obter uma
estimativa consensual para cada item do projeto. Essas estimativas podem ser usadas para
planejar e gerenciar o projeto de forma mais eficaz.
Pode se optar por executar apenas uma vez a depender da diferença das estimativas ou da
necessidade de pouca precisão nos cálculos.
Cálculo da Margem de Erro

A seguir são listadas algumas formas de se calcular a margem de erro de estimativas em projetos.
Estimativa de ordem de magnitude

A técnica de estimativa de ordem de magnitude, mencionada no PMBoK (Project Management
Body of Knowledge), é uma abordagem de alto nível usada nas fases iniciais de um projeto para
fornecer uma estimativa aproximada dos custos, duração e recursos necessários.
A ordem de magnitude aceitável para as estimativas varia dependendo do contexto do projeto e
da fase do projeto em que as estimativas estão sendo feitas. No entanto, em geral, uma estimativa de
ordem de magnitude é aceitável se estiver dentro de uma faixa de -25% a +75% do valor real. Isso
significa que, nas fases iniciais do projeto, é aceitável se a estimativa estiver entre 25% abaixo e 75%
acima do valor real.
Dessa forma:
𝑀𝑎𝑟𝑔𝑒𝑚 𝑑𝑒 𝐸𝑟𝑟𝑜 𝑆𝑢𝑝𝑒𝑟𝑖𝑜𝑟 = 𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑣𝑎 × 175%
11
Cone da Incerteza
Embora o Cone da Incerteza não forneça uma margem de erro específica que seja aceitável durante
a fase inicial de um projeto, ele destaca que a incerteza é maior nesse estágio e que as estimativas
estão sujeitas a uma ampla variação. Na fase inicial, a margem de erro pode variar de -75% a +300%,
dependendo da complexidade do projeto, dos requisitos e das informações disponíveis. Dessa forma:

Base Histórica da Empresa
Para calcular a margem de erro percentual mínima e máxima de estimativas de esforço com base
em dados históricos de estimativas e realizações de uma empresa, siga os passos abaixo:
Coletar dados históricos: Obtenha os dados históricos de estimativas e realizações de projetos
anteriores da empresa.
1. Coletar os dados históricos: Colete os dados históricos da empresa para criar uma base de
dados.
2. Calcular diferenças percentuais: Calcule a diferença percentual entre a estimativa e a
realização para cada projeto. Use a seguinte fórmula:
(𝑅𝑒𝑎𝑙𝑖𝑧𝑎𝑑𝑜 − 𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑣𝑎)
𝐷𝑖𝑓𝑒𝑟𝑒𝑛ç𝑎 𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑢𝑎𝑙 =
𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑣𝑎
3. Encontrar o percentual de erro superior e inferior: Determine os valores mínimo e máximo
das diferenças percentuais calculadas no passo anterior.
4. Calcule as margens de erros: Esses valores correspondem à margem de erro superior e
inferior, respectivamente.
𝑀𝑎𝑟𝑔𝑒𝑚 𝑑𝑒 𝐸𝑟𝑟𝑜 𝑆𝑢𝑝𝑒𝑟𝑖𝑜𝑟 = 𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑣𝑎 × (1 + 𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑢𝑎𝑙 𝑑𝑒 𝐸𝑟𝑟𝑜 𝑆𝑢𝑝𝑒𝑟𝑖𝑜𝑟)
𝑀𝑎𝑟𝑔𝑒𝑚 𝑑𝑒 𝐸𝑟𝑟𝑜 𝐼𝑛𝑓𝑒𝑟𝑖𝑜𝑟 = 𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑣𝑎 × (1 + 𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑢𝑎𝑙 𝑑𝑒 𝐸𝑟𝑟𝑜 𝐼𝑛𝑓𝑒𝑟𝑖𝑜𝑟)
Vamos considerar um exemplo com cinco projetos anteriores e seus respectivos esforços estimados
e realizados. E vamos seguir os passos mencionados acima:
1. Coletar os dados históricos
Projeto Estimativa Realizado

1 20 18
2 30 33
3 25 22
4 15 16
5 40 44
2. Calcular diferenças percentuais
Projeto Estimativa Realizado Diferença

1 20 18 -10%
2 30 33 10%
3 25 22 -12%
4 15 16 6%
12
5 40 44 4%
3. Encontrar o percentual de erro superior e inferior
Percentual de Erro Superior = 10%
Percentual de Erro Inferior = −12%
4. Calcule as margens de erros
Com base neste exemplo, o percentual de erro superior é de -12% e o percentual de erro inferior é
de 10%. Esses valores podem ser usados para informar a tomada de decisão e ajustar as estimativas
futuras com base no histórico da empresa.
𝑀𝑎𝑟𝑔𝑒𝑚 𝑑𝑒 𝐸𝑟𝑟𝑜 𝐼𝑛𝑓𝑒𝑟𝑖𝑜𝑟 = 𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑣𝑎 × 88%
Estimativas de diferentes profissionais
Para calcular o percentual da margem de erro mínimo, médio e máximo de estimativas de esforço
a partir de várias estimativas de diferentes profissionais para um item, siga os passos abaixo:
1. Coletar estimativas: Obtenha estimativas de esforço de diferentes profissionais para o item
em questão.
2. Calcular estatísticas: Calcule a estatísticas básicas, como mínimo, médio e máximo das
estimativas coletadas.
3. Calcular a margem de erro: A margem de erro é geralmente expressa como um percentual da
média. Para calcular a margem de erro mínimo e máximo, siga estas etapas:
𝑀í𝑛𝑖𝑚𝑜 − 𝑀é𝑑𝑖𝑎
Margem de Erro Inferior =
𝑀é𝑑𝑖𝑎
𝑀á𝑥𝑖𝑚𝑜 − 𝑀é𝑑𝑖𝑎
Margem de Erro Superior =
𝑀é𝑑𝑖𝑎
Dessa forma, você obterá a margem de erro inferior e superior para as estimativas de esforço
fornecidas pelos diferentes profissionais. Esses valores podem ajudá-lo a entender a incerteza
associada às estimativas e ajudar a tomada de decisão. Quanto maior for a variação desses dados,
maior é a incerteza da estimativa.
Vamos supor que você pediu a cinco profissionais para estimar o esforço necessário para concluir
uma tarefa específica em um projeto de desenvolvimento de software. Agora, siga os passos
mencionados na resposta anterior:
1. Coletar estimativas: abaixo as estimativas dos cinco profissionais.
Profissional Estimativa
Alberto 18 horas
Barbara 22 horas
Carlos 22 horas
Daniela 25 horas
Eraldo 28 horas
2. Calcular estatísticas:
13
(18 + 22 + 22 + 25 + 28) 120
𝑀é𝑑𝑖𝑎 = = = 23 horas
5 5
𝑀í𝑛𝑖𝑚𝑜 = 18 ℎ𝑜𝑟𝑎𝑠
𝑀á𝑥𝑖𝑚𝑜 = 28 horas
3. Calcular a margem de erro:
18 − 23
Margem de Erro Inferior = = −21%
23
28 + 23
Margem de Erro Superior = = 21%
23
14
Como quantificar o tamanho de um item?
No ágil, uma das questões centrais é: "Quão grande é isso?". Esta pergunta permeia as discussões
de planejamento e priorização, sendo fundamental para entender a sequência de trabalho e o esforço
requerido. A resposta, no entanto, não se resume a uma unidade universal ou métrica rígida. Ao
contrário, envolve uma combinação de experiência, contexto e técnicas especializadas de avaliação.
Dentro deste capítulo, mergulharemos profundamente em duas metodologias principais utilizadas
para estimar o tamanho de um item: o "Referencial Temporal", que se baseia em métricas
quantificáveis de tempo e esforço, e a "Comparação", que emprega a avaliação relativa entre itens.
Ambas as abordagens têm o objetivo comum de atribuir um "peso" ou "tamanho" a cada item,
ajudando as equipes a navegarem no universo complexo das estimativas ágeis. Entenda esses
métodos, aplique-os em seus projetos e refine seu processo de estimativa para obter melhores
resultados.
Referencial Temporal
As técnicas de estimativa baseadas em tempo visam quantificar a quantidade de esforço de
trabalho necessário para concluir uma tarefa ou projeto, geralmente expresso em horas, dias ou
semanas. Essas técnicas incluem:
Horas Ideais
As estimativas são feitas em termos de horas ideais de trabalho, que representam a quantidade de
tempo que um desenvolvedor levaria para concluir uma tarefa sem interrupções ou distrações. Essas
estimativas são idealizadas porque desconsideram fatores externos que podem afetar a produtividade
e as diferenças de produtividade entre profissionais.
Dias Ideais
Similar às horas ideais, as estimativas são feitas em termos de dias ideais de trabalho. Um dia ideal
representa um dia de trabalho completo e produtivo, sem interrupções.
Semanas de uma Equipe

As estimativas são feitas em termos de semanas de trabalho de uma equipe inteira. Esta técnica é
útil quando se lida com projetos grandes, que envolvem várias equipes trabalhando juntas, ou sem
detalhamento dos itens.
Comparação
Estimativas por comparação são um conjunto de técnicas de estimativa que se baseiam na
comparação entre itens de trabalho semelhantes.
Uma forma de realizar a estimativa por comparação é utilizar uma escala numérica que segue a
sequência de Fibonacci, na qual cada número na sequência é a soma dos dois números anteriores. A
sequência de Fibonacci pode ser usada para atribuir um número a cada item a ser estimado, com base
na comparação com itens semelhantes que já foram concluídos anteriormente.
Por exemplo, imagine que você precisa estimar o tamanho de três prédios na Avenida Paulista em
São Paulo. Usando a escala de Fibonacci, poderíamos atribuir valores aos prédios da seguinte forma:
• Prédio A: é ligeiramente menor que o prédio de referência, portanto pode ser estimado em 5.
15
• Prédio B: é ligeiramente maior que o prédio de referência, portanto pode ser estimado em 13.
• Prédio C: é significativamente maior que o prédio de referência, portanto pode ser estimado
em 21.
A sequência de Fibonacci é útil para estimativas por comparação porque os números da sequência
têm uma proporção dourada, o que significa que cada número é aproximadamente 1,618 vezes maior
que o número anterior. Isso permite estimativas relativas que levem em conta a diferença de tamanho
entre os itens, ao mesmo tempo em que mantém uma proporção consistente entre os números. Além
disso, a sequência de Fibonacci é fácil de lembrar e usar, o que a torna uma ferramenta útil.
É importante lembrar que comparações em diferentes contextos, diferentes projetos, diferentes
equipes tendem a criar discrepâncias e comparações que fazem pouco sentido. Como exemplo a
mesma técnica foi aplicada em outro cenário.
As principais técnicas de estimativas baseadas em comparação são Story Points, Dog Points e T Shirt
Size.
Story Points
Os story points são uma medida relativa de tamanho de uma história de usuário em comparação
com outras histórias de usuário. Os story points são atribuídos a cada história de usuário com base em
fatores como dificuldade, risco e esforço necessário para a implementação.
Dog Points
Dog points é uma técnica de estimativa semelhante aos story points, mas em vez de usar uma
escala numérica, utiliza uma escala de tamanho de raças de cães (pequeno, médio e grande) para
representar a complexidade das tarefas.
16
T-Shirt Size
A técnica T-shirt size é outra abordagem relativa que utiliza tamanhos de camisetas (P,M,G,GG,
GGG) para categorizar a complexidade e o esforço das tarefas. As tarefas são agrupadas em categorias
com base no tamanho da camiseta, que representa uma faixa de esforço.
P M G GG GGG
Como comparar o tamanho dos itens

Para comparar itens é necessário se levar em conta diferentes fatores como a quantidade de
trabalho a fazer, risco e incerteza, dificuldade. Como exemplo:
• Quantidade de Trabalho a Fazer Certamente, se há mais a fazer de algo, a estimativa de
tamanho deve ser maior. Pense em desenvolver duas aplicações móveis. A primeira aplicação
possui apenas uma tela de boas-vindas. A segunda tem 20 telas, cada uma exigindo diferentes
interações do usuário. A segunda aplicação não é necessariamente mais complexa em termos
de cada tela individualmente. No entanto, globalmente, há mais trabalho a ser feito. Ela
provavelmente não exigirá 20 vezes mais esforço, mesmo tendo 20 vezes mais telas, devido às
economias de escala. Talvez desenvolver a segunda aplicação demande apenas 5 ou 6 vezes
mais trabalho que a primeira.
• Risco e Incerteza: O grau de risco e incerteza em um item deve influenciar a estimativa
atribuída ao item. Se uma equipe é instruída a estimar um item e o stakeholder não fornece
especificações claras, essa ambiguidade deve ser refletida na estimativa. Por exemplo, se uma
funcionalidade envolve a integração com um sistema de terceiros desconhecido, esse risco
deve ser considerado na estimativa com um valor maior do que para que se tem todos os
detalhes.
• Dificuldade: A dificuldade também é crucial ao se estimar itens por comparação. Pense em
uma aplicação que tem uma tela com 10 botões simples que levam a diferentes páginas.
Agora, imagine outra aplicação com 10 botões, mas cada botão desencadeia uma série de
ações, como sincronização com a nuvem, atualizações de banco de dados e animações
personalizadas. Esta última aplicação, mesmo com o mesmo número de botões, tem
elementos mais desafiadores para implementar. As funcionalidades são mais difíceis, exigirão
mais reflexão e potencialmente mais revisões. As chances de erros e revisões também são
mais altas. Essa dificuldade adicional deve ser refletida na estimativa fornecida.
Para finalizar, é importante entender que a comparação de itens não se resume a um único
parâmetro. É uma avaliação multifacetada que considera a quantidade de trabalho, a dificuldade
intrínseca e os riscos associados. Estas considerações são importantes para prover comparações
realistas.
17
Como estimar vários itens rapidamente?
Dentro do mundo das estimativas ágeis, a capacidade de avaliar rapidamente um volume
significativo de itens é uma competência inestimável para qualquer equipe. Ao lidar com backlogs
extensos e ciclos de desenvolvimento ágeis em rápida evolução, perder tempo em processos de
estimativa prolongados pode ser contraproducente. Este capítulo oferece uma exploração
aprofundada de técnicas ágeis eficazes que foram desenvolvidas com um objetivo em mente: agilidade
na estimativa!
Desde o tradicional "Método Delphi" até abordagens mais contemporâneas como "Estimativa por
Afinidade", mergulharemos nas nuances, vantagens e desafios de cada técnica. Ao final deste capítulo,
você terá em mãos uma variedade de ferramentas e métodos, capacitando-o a escolher a técnica mais
apropriada para o contexto de sua equipe e projeto.
Prepare-se para uma viagem exploratória por métodos como "Planning Poker", que transforma a
estimativa em uma atividade colaborativa e divertida; o "Método de estimativa de três pontos", que
considera o melhor, o mais provável e o pior cenário para uma estimativa mais holística; o "Protocolo
de ordenação", que se concentra na comparação relativa entre tarefas; e muitos outros.
Cada subseção deste capítulo é dedicada a uma técnica específica, permitindo a você entender
profundamente cada método e decidir qual se encaixa melhor nas necessidades específicas de sua
equipe. Seja você um novato em estimativas ágeis ou um profissional experiente buscando aprimorar
seus métodos, este capítulo será um recurso valioso em sua jornada ágil.
Método Delphi
O método Delphi é uma técnica de previsão e estimativa desenvolvida na década de 1950 pela
RAND Corporation, originalmente para uso em projetos militares e de defesa dos Estados Unidos.
Desde então, o método tem sido amplamente utilizado em diversas áreas, incluindo estimativas de
projetos de software. O objetivo do método Delphi é obter consenso entre especialistas por meio de
várias rodadas de questionários e feedback anônimo.
A técnica Delphi foi criada por Olaf Helmer e Norman Dalkey, pesquisadores da RAND Corporation,
como uma forma sistemática de combinar opiniões de especialistas para chegar a previsões mais
precisas e reduzir o viés e as influências de grupo.
Como deve ser feito para estimar:
1. Seleção de especialistas: Identifique um grupo diversificado de especialistas com
conhecimento e experiência relevantes no domínio do projeto. O tamanho ideal do grupo
varia, mas geralmente varia de 5 a 50 participantes.
2. Primeira rodada de questionários: Crie um questionário anônimo com perguntas relacionadas
ao escopo, requisitos e esforço necessários para o projeto. Os especialistas fornecem suas
estimativas individualmente.
3. Coletar e analisar respostas: As respostas são coletadas e analisadas, geralmente por um
facilitador ou coordenador. Estatísticas como média, mediana e intervalos são calculadas para
cada pergunta.
4. Segunda rodada de questionários: O facilitador fornece um resumo dos resultados da primeira
rodada e solicita que os especialistas revisem suas estimativas iniciais à luz das respostas
18
agregadas. Os especialistas podem ajustar suas estimativas e fornecer justificativas para suas
escolhas.
5. Rodadas adicionais: Repita as rodadas de questionários e análise até que um consenso seja
alcançado ou que as rodadas adicionais não resultem em mudanças significativas nas
estimativas.
6. Consolidar resultados: Calcule a média ou mediana das estimativas finais para obter uma
estimativa consensual para o projeto.
Restrições para fazer uma estimativa:
• Disponibilidade e comprometimento de especialistas: A eficácia do método Delphi
depende da disponibilidade e do comprometimento dos especialistas em participar das
várias rodadas de questionários.
• Conhecimento dos especialistas: Os especialistas devem saber como fazer o trabalho
• Viés do facilitador: O facilitador deve garantir que suas opiniões e preferências não
influenciem a análise e a apresentação dos resultados.
• Estimativas independentes e anonimato: A técnica Delphi exige anonimato e evitar a
comunicação indireta entre os especialistas para evitar viés e influências de grupo. Isso
limita a troca de ideías e esclarecimentos.
• Ganho: Deve se evitar fornecer incentivos as pessoas que vão fazer a estimativa tendo em
vista que isso pode alterar o resultado das estimativas
• Tempo e esforço: O método Delphi pode ser demorado e trabalhoso, especialmente
quando várias rodadas de questionários são necessárias para alcançar o consenso.
• Apesar dessas restrições, o método Delphi é uma ferramenta valiosa para estimar o
trabalho a ser feito em projetos de software, pois permite combinar a experiência e o
conhecimento de diversos especialistas e chegar a uma estimativa consensual.
Um caso real de uso da técnica Delphi ocorreu na década de 1970, quando a técnica foi empregada
para estimar o custo e o cronograma de desenvolvimento do projeto de software para o Sistema de
Controle de Tráfego Aéreo da França (CTA 4A). O projeto envolvia o desenvolvimento de um sistema
complexo e inovador, e a equipe enfrentava incertezas significativas em termos de tecnologia,
requisitos e recursos. Em um exemplo mais recente relacionado ao desenvolvimento de software, a
técnica Delphi foi aplicada em um estudo publicado em 2019 por Aregbesola et al., intitulado "An
expert-based cost estimation model for mobile applications in Nigeria" (Um modelo de estimativa de
custo baseado em especialistas para aplicativos móveis na Nigéria). O objetivo do estudo era criar um
modelo de estimativa de custo específico para projetos de desenvolvimento de aplicativos móveis na
Nigéria, levando em consideração fatores locais e regionais.
Planning Poker
Planning Poker é uma técnica baseada em consenso para estimativas ágeis. É uma maneira
divertida e envolvente das equipes aplicarem estimativas relativas ao trabalho planejado. O planning
poker é baseado no método Delphi descrito anteriormente. A seguir é explicado o passo a passo:
1. Preparação das Cartas: Certifique-se de que cada estimador tenha um conjunto de cartas do
Planning Poker, seja físico ou virtual. Essas cartas devem exibir valores específicos: 1, 2, 3, 5,
19
8, 13, 20, 40 e 100. Estes são valores da sequência de Fibonacci modificada, representando
diferentes tamanhos na unidade de estimativa escolhida.
2. Definição Protocolo de decisão: Antes de começar o Planning Poker, decida um protocolo ou
método para tomar decisões. Por exemplo, você pode decidir que, se após três rodadas não
houver consenso, o item será adiado.
3. Discussão do Item: Antes de fazer qualquer estimativa, a equipe deve discutir detalhadamente
o item em questão, esclarecendo todas as dúvidas e aspectos.
4. Seleção Individual de Carta: Uma vez que o item foi completamente debatido, cada estimador
deve, de maneira privada, selecionar uma carta que acredita representar a estimativa mais
precisa para esse item.
5. Revelação das Cartas: Todos os estimadores revelam suas cartas simultaneamente. Isso evita
que as escolhas de um influenciem os outros.
6. Análise das Estimativas: Se todos escolherem o mesmo valor, esse se torna a estimativa final.
Se diferentes valores são escolhidos, uma discussão adicional é necessária. Os estimadores
que escolheram os valores mais altos e mais baixos devem, em particular, explicar sua lógica.
7. Nova Rodada de Estimativa: Após a discussão, os estimadores escolhem novamente uma
carta, em privado, e as revelam simultaneamente.
8. Alcançando o Consenso: Este processo de discussão e reavaliação continua até que a equipe
chegue a um consenso sobre a estimativa tendo em vista o protocolo de decisão selecionado.
Lembre-se, o objetivo do Planning Poker não é apenas chegar a uma estimativa, mas garantir que
todos na equipe entendam a tarefa da mesma forma. É um exercício colaborativo que promove a
discussão e garante que todos os membros da equipe estejam alinhados em suas expectativas.
Estudos mostram que equipes que estimam utilizando o planning poker consistentemente relatam
que chegam a estimativas mais precisas do que com qualquer técnica que usaram anteriormente. Um
motivo pelo qual o Planning Poker leva a estimativas melhores é porque reúne várias opiniões de
especialistas, assim como o método delphi.
Pesquisadores descobriram que o diálogo que acontece durante planning poker entre os
estimadores para justificar suas estimativas melhora a precisão da estimativa, especialmente em itens
com muita incerteza.
Método de estimativa de três pontos

A estimativa de 3 pontos é um método de estimar o trabalho considerando três diferentes
estimativas: a mais otimista, a mais pessimista, a mais provável.
A estimativa otimista assume que tudo ocorre conforme o planejado. A estimativa pessimista
considera os riscos que podem atrasar o projeto. A estimativa mais provável situa-se entre as opções
otimista e pessimista e baseia-se no melhor julgamento do estimador. O Método de Três Pontos
encoraja os membros da equipe a discutirem cenários otimistas e pessimistas, ajudando a identificar
possíveis problemas precocemente. Considere usar o Método de Três Pontos se sua equipe tende a
ser excessivamente otimista ou frequentemente encontra obstáculos inesperados.
Para usar o Método de Estimativa Três Pontos, pergunte à sua equipe:
• Quanto tempo este item levará se tudo correr bem? (Otimista)
20
• Quanto tempo este item levará se você encontrar obstáculos? (Pessimista)
• Com base nessas informações, qual é o mais provável? (Provável)
Uma vez que você tenha as respostas, calcule a distribuição beta que dá mais peso ao valor mais
provável. A metodologia beta é mais precisa porque segue a curva de distribuição beta típica. Na
distribuição beta pesam o valor mais provável conforme mostrado na formula abaixo:
𝑂𝑡𝑖𝑚𝑖𝑠𝑡𝑎 + 𝑃𝑒𝑠𝑠𝑖𝑚𝑖𝑠𝑡𝑎 + 4 × 𝑃𝑟𝑜𝑣á𝑣𝑒𝑙
Estimativa =
6
Como exemplo:
Otimista = 2
Pessimista = 10
Provável = 6
Logo:
2 + 10 + 4 × 6 36
Estimativa = = =6
6 6
Estimativa por afinidade / Affinity Estimation

A Estimativa por Afinidade é uma técnica que muitas equipes ágeis usam para estimar rapidamente
e facilmente muitos itens.
1. Preparação: Marque uma extremidade com "Menor" e a outra com "Maior" para estabelecer
uma escala horizontal.
2. Distribuição das Histórias: Os itens são apresentados para a equipe.
3. Dimensionamento Relativo Silencioso: Cada membro da equipe estima o item
individualmente sem nenhum tipo de discussão e coloca o item na escala entre "Menor" e
"Maior" no lugar que acredita fazer sentido.
4. Alterando os itens: Uma vez que cada item é colocada na escala, os membros da equipe
alteram os tamanhos relativos. Para isso, a equipe discute sobre os itens em relação a design,
implementação ou quaisquer outros desafios. A equipe também esclarece todas as dúvidas
que ainda existirem. Com base no entendimento feito durante a discussão, a equipe rearranja
os itens na escala, se necessário.
5. Colocando itens no bucket correto: A escala "Menor" para "Maior" é dividida e marcada
adequadamente com os marcadores da unidade de tamanho. A equipe agora coloca suas
histórias, que estavam na escala "Menor" para "Maior", no bucket apropriado da escala
convertida.
Protocolo de ordenação
Esta técnica oferece uma maneira simples de visualizar itens em relação uns aos outros e fornece
uma boa visão geral do que precisa ser priorizado. O facilitador coloca os itens em linha de forma
aleatória - em uma parede ou mesa se estiver no mesmo local, ou usando um quadro branco digital se
estiver trabalhando remotamente. O objetivo é reordená-los de baixo para alto. Os membros da
equipe se revezam, cada um movendo um item de sua escolha para cima ou para baixo na linha por
21
um lugar. O movimento é baseado no esforço necessário para aquele item em comparação com os
itens de ambos os lados dele.
1. Preparação: Inicie preparando uma escala que varie de baixo para alto. Esta escala pode ser
física, como em uma parede ou mesa, ou digital, usando um quadro branco digital.
2. Posicionamento Inicial: Coloque todos os itens do backlog do produto na escala de forma
aleatória.
3. Reordenação: O objetivo principal é reordenar os itens de acordo com a sua prioridade ou
esforço estimado, movendo-os de baixo para alto.
4. Tomada de Decisão: Os membros da equipe se revezam na decisão. Em cada turno, um
membro da equipe move um item de sua escolha na escala, seja para cima, para baixo ou
decide passar a vez para o próximo participante. O critério para mover um item é o esforço
necessário para aquele item, comparando-o com os itens adjacentes na escala.
5. Critérios de Finalização: O processo continua até que todos os participantes estejam
satisfeitos com a ordenação e não desejem fazer mais movimentos.
6. Análise Final: Uma vez concluído, a escala não apenas refletirá os tamanhos relativos precisos
de cada item do backlog do produto, mas também fornecerá uma ordem de prioridade clara
para a equipe seguir.
7. Atribuir um tamanho (opcional): é possível atribuir um tamanho final para o item.
A técnica do Protocolo de ordenação Método de Ordenação é especialmente útil quando se tem
muitos itens a serem ordenados e uma equipe relativamente pequena. Para melhor eficácia, é
aconselhável que a equipe esteja familiarizada com técnicas de estimativa, já que a decisão é baseada
no julgamento individual de cada membro.
Dot Votting
Dot Voting é uma maneira divertida e direta de estimar itens, sendo frequentemente usada
também em retrospectivas. Esta técnica permite que as equipes expressem esforço de forma rápida e
visual, tornando-se uma maneira eficiente de abordar vários itens em um tempo limitado.
Para usar o Dot Voting:
1. Preparação: Separe os itens de usuário que precisam ser estimadas e organize-as de maneira
visível em um espaço, seja ele físico (como uma parede ou quadro branco) ou virtual. Atribua
uma cor diferente de adesivo ou marcador para cada membro da equipe. Isso ajudará a
identificar quem deu quantos pontos a cada item.
2. Definição da Escala: Em grupo, discutam e escolham uma escala de esforço baseada nos votos
a serem distribuidos, que pode variar, por exemplo, de um a cinco.
3. Votação: Cada membro da equipe deve adicionar pontos (ou adesivos) aos itens, de acordo
com a escala definida anteriormente. Inicialmente, mantenha os votos ocultos para evitar
influências externas e viés de ancoragem.
4. Revelação e Análise: Uma vez que todos tenham votado, revele todos os pontos
simultaneamente. As histórias com mais pontos são consideradas mais trabalhosas, enquanto
as com menos pontos são vistas como menos exigentes.
22
Esta técnica permite identificar rapidamente quais histórias são vistas como mais complexas pela
equipe e quais são vistas como menos desafiadoras.
O Dot Voting tem suas desvantagens. Ele pode ser propenso a vieses cognitivos, como ancoragem.
Quando todos veem os pontos aparecendo, o pensamento de grupo pode prevalecer. Para combater
isso, oculte os votos inicialmente e, em seguida, revele-os simultaneamente. Fazer isso melhora a
precisão de suas estimativas.
Tamanho Máximo Permitido (Maximum allowable size)

A técnica de estimativa Tamanho Máximo Permitido ajuda a encontrar e dividir itens grandes no
product backlog, assim como peneirar a farinha para remover grumos para uma mistura de bolo suave.
TMP identifica épicos e grandes ideias que precisam ser reduzidas para itens menores mais
gerenciáveis.
1. Definindo a Escala de Estimativa: Escolha uma escala de estimativa que sua equipe esteja
familiarizada. Isso pode ser em horas ideais, dias ideias ou até T-Shirt Size.
2. Estabeleça um limite para essa escala: Por exemplo, se você está usando horas, pode
determinar que as histórias de usuários não devem exceder 16 horas.
3. Revisão do Product Backlog: Examine todos os itens presentes no seu Product Backlog.
Identifique e separe aqueles que a equipe acredita que ultrapassarão o limite estabelecido.
4. Desmembrando Itens Grandes: Para os itens identificados como acima do Tamanho Máximo
Permitido, organize uma discussão com a equipe. Decidam juntos a melhor forma de dividir
estes grandes itens em itens menores que estejam dentro do limite estabelecido.
Recomenda-se usar a técnica TMP quando a equipe frequentemente não conclui tarefas dentro de
um sprint ou quando o backlog tem muitos itens grandes que parecem desafiadores. Ao ajustar o
tamanho dos itens, você otimiza o processo de estimativa e planejamento de sprints.
Grande, Incerto e o Pequeno (Big, Uncertain, Small)

O método Grande, Incerto, Pequeno rapidamente destaca itens que merecem discussão. Você
coloca de lado os itens pequenos sem mais conversas, enquanto os itens excessivamente grandes são
sinalizados para uma estimativa mais detalhada posteriormente. Com esses resolvidos, sua equipe
pode se concentrar em discutir histórias incertas.
Esta técnica permite que os membros da equipe reconheçam sua incerteza sobre se uma tarefa é
grande ou pequena. A incerteza pode sinalizar que o item está no meio ou em áreas onde a equipe
não tem habilidades, conhecimento ou experiência.
1. Introdução e Preparação: Apresente a técnica para a equipe, explicando os três possíveis
rótulos: "Grande", "Incerto" e "Pequeno".
2. Selecionar os itens que serão estimados: Organize os itens do Product Backlog a serem
avaliados.
3. Identifique os itens pequenos: Se a equipe acredita que um item é claramente simples e
direto, classifique-o como "Pequeno".
4. Identifique os itens grandes: Se o item parece grande e requer muito trabalho, classifique-o
como "Grande".
23
5. Identifique os itens incertos: Para itens onde há dúvidas ou incertezas quanto ao tamanho e
como fazer o item, classifique-os como "Incerto".
6. Abordando Itens Incertos: Discuta cada item incerto parar identificar: pontos desconhecidos;
falta de conhecimento técnico que estão impedindo decisões claras; falta de informação
necessária para esclarecer as incertezas; informações que alguma outra pessoa pode fornecer.
7. Reavaliação e Classificação Final: Após a discussão, reavalie os itens "Incertos". Com base nas
novas informações ou clareza obtida, classifique-os como "Grande" ou "Pequeno".
Bucket Estimation
A técnica de "Bucket Estimations" é uma técnica de estimativa que agrupa os itens de trabalho em
"buckets" ou "caixas", com base em suas características comuns, como incerteza, dificuldade ou
esforço. Essa técnica foi criada por Alistair Cockburn, um dos autores do Manifesto Ágil, e apareceu
pela primeira vez no livro "Agile Software Development: The Cooperative Game" publicado em 2001.
As principais vantagens da técnica de "Bucket Estimations" são: fácil de entender e usar,
especialmente para equipes ágeis iniciantes; ajuda a identificar padrões e tendências nos itens de
trabalho, o que pode ajudar a equipe a estimar com mais precisão e eficiência; ajuda a promover
discussões construtivas e colaborativas entre a equipe durante o processo de estimativa. As principais
desvantagens incluem: Pode ser subjetiva e enviesada, dependendo das opiniões e experiências
individuais dos membros da equipe; pode levar a estimativas imprecisas e inconsistências se as
características dos buckets não estiverem claramente definidas.
A técnica de "Bucket Estimations" pode ser realizada em várias rodadas, cada uma com diferentes
buckets. Uma das formas mais eficientes é associar em rodadas distintas o mesmo item para buckets
de incerteza, dificuldade e esforço.
Aqui está um exemplo de como a técnica deve ser realizada em 3 rodadas:
1. Alocação nos Buckets de Incerteza: Incerteza refere-se ao nível de desconhecimento ou
ambiguidade em torno do item a ser estimado.
2. Alocação nos Buckets de Dificuldade: A dificuldade refere-se ao nível de habilidade e
experiência necessários para concluir o item.
3. Alocação nos Buckets de Esforço: O esforço refere-se ao nível de trabalho necessário para
concluir o item, independentemente da sua dificuldade ou incerteza. O esforço pode incluir
atividades como codificação, testes, revisões de código, deployment, documentação e outros.
4. Associação de estimativa de tempo ao bucket: Deve ser associado uma unidade de tamanho
para cada um dos buckts sendo que cada item dentro do bucket tem aquele tamanho
associado.
Itens com alta incerteza geralmente têm mais riscos associados e tentem a ter maior margem de
erro nas estimativas. Itens com baixa incerteza tem menos riscos e tendem a ter menor margem de
erro. Itens com alta dificuldade exigem mais habilidade e experiência do profissional que irá fazer o
trabalho. Itens com baixa dificuldade são geralmente mais simples e podem ser concluídos por
profissionais com menos habilidade e experiência do profissional. Itens que exigem mais esforço levam
mais tempo para serem concluídos. Itens que exigem menos esforço levam menos tempo para serem
concluídos.
Vamos considerar o exemplo para um item de pagamento com cartão de crédito.
24
1. Alocação nos Buckets de Incerteza
Dessa forma em uma primeira rodada temos 3 buckets de incerteza:
• Bucket 1 ( I- ):itens de trabalho com baixa incerteza I
• Bucket 2 ( I ): itens de trabalho com incerteza média
• Bucket 3 ( I+ ): itens de trabalho com alta incerteza
Como exemplo o Pagamento por Cartão de Crédito foi associado ao Bucket 2 (I).
2. Alocação nos Buckets de Dificuldade

Dessa forma em uma segunda rodada temos 4 buckets de dificuldade:
• Bucket 1 (D--): itens de trabalho de baixa dificuldade
• Bucket 2 (D-): itens de trabalho de dificuldade média-baixa
• Bucket 3 (D+): itens de trabalho de dificuldade média-alta
• Bucket 4 (D++): itens de trabalho de alta dificuldade
Como exemplo o Pagamento por Cartão de Crédito foi associado ao Bucket 3 (D+).
3. Alocação nos Buckets de Esforço

Dessa forma em uma terceira rodada temos 5 buckets de dificuldade:
• Bucket 1 (E--): itens de trabalho de baixo esforço
• Bucket 2 (E-): itens de trabalho de esforço médio-baixo
• Bucket 3 (E): itens de trabalho de esforço médio
• Bucket 4 (E+): itens de trabalho de esforço médio-alto
• Bucket 5 (E++): itens de trabalho de alto esforço
Após a terceira rodada, a cada bucket é associado a um tamanho e os itens recebem o tamanho de
acordo com o bucket ao qual pertence. Esse tamanho pode ser medido em Story Points, T Shirt Size
ou qualquer outra unidade de medida que a equipe decida usar.
Como exemplo o Pagamento por Cartão de Crédito foi associado ao Bucket 2 (E-) e foi estimado
com o tamanho M.
25
4. Associação de estimativa de tempo ao bucket:
É associado o tamanho de 2 semanas ao bucket E--
Referencias
https://www.mountaingoatsoftware.com/agile/planning-poker
https://www.sciencedirect.com/science/article/abs/pii/0030507383901228
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6774376
https://www.parabol.co/blog/agile-estimation-techniques/#Affinity-Estimation
https://www.techagilist.com/agile/scrum/affinity-estimation-agile-estimation-method/
26
Quanto trabalho podemos nos comprometer em uma janela
de tempo?
Em um mundo onde a rapidez e adaptabilidade são valorizadas, a habilidade de estimar o trabalho
com precisão se torna cada vez mais vital. No entanto, as estimativas em si não são suficientes:
precisamos entender quanta carga de trabalho podemos assumir real e efetivamente em uma janela
de tempo predeterminada. Dentro do ambiente ágil, esta questão assume um papel central, sendo um
dos pilares de um planejamento bem-sucedido. Neste capítulo, mergulharemos fundo no tema
"Quanto trabalho podemos nos comprometer em uma janela de tempo?", explorando métodos,
técnicas e considerações que permitem às equipes otimizarem suas estimativas e, ao mesmo tempo,
garantir a entrega de valor.
Começaremos com uma profunda "Análise de Restrições e Preparação", onde avaliaremos todos
os fatores internos e externos que podem influenciar nossa capacidade de trabalho. Avançaremos para
entender a "Estimativa Unitária ou Estimativas dos Itens Sozinhos", destacando a importância de cada
item de trabalho ser avaliado individualmente para maior precisão. E, finalmente, faremos uma
"Avaliação de Quanto Trabalho Pode-se Entregar", garantindo que nossa capacidade e compromisso
estejam alinhados com o que é realmente possível.
Ao final deste capítulo, você terá um entendimento claro de como alinhar expectativas, capacidade
e compromissos, equilibrando realismo e ambição, para maximizar a entrega de valor em cada janela
de tempo.
Análise de Restrições e preparação

O primeiro passo envolve a identificação e análise das restrições que podem afetar a capacidade
de trabalho da equipe. Algumas restrições comuns incluem férias, folgas, disponibilidade de recursos
e conhecimento técnico necessário para concluir as tarefas. Além disso, a definição de pronto
(Definition of Done) deve ser levada em consideração, pois estabelece os critérios que devem ser
cumpridos para que uma tarefa seja considerada concluída.
Na perspectiva da preparação é importante deixar claro as técnicas que vão ser utilizadas nessa
reunião, o protocolo de decisão a ser utilizado. A seguir algumas técnicas para ajudar em cada um dos
pontos descritos acima.
Cálculo de Horas produtivas Individuais

A técnica de cálculo de horas produtivas individuais busca proporcionar uma avaliação mais precisa
da quantidade de trabalho que um indivíduo pode comprometer-se durante um Sprint. Ela leva em
consideração não apenas as horas padrão de trabalho, mas também outras variáveis essenciais, como
reuniões, interrupções comuns no dia a dia e a alocação em múltiplos projetos. Esta abordagem ajuda
a identificar possíveis sobrecargas e proporciona uma base mais sólida para as decisões tomadas para
planejar a capacidade produtiva.
A seguir o passo a passo da técnica.
5. Defina a Timebox e as Horas de Trabalho Diárias: Suponha uma timebox de 2 semanas, ou
seja, 10 dias úteis. Estime que uma pessoa possa ser produtiva por cerca de 6 horas em um
dia de trabalho de 8 horas.
27
6. Horas Produtivas Possíveis: Multiplique os dias de trabalho (10) pelas horas produtivas por
dia (6) para obter o total possível de horas produtivas no Sprint.
7. Desconte o Tempo de Reuniões: Como exemplo de reuniões Sprint Planning, Daily Scrum,
Sprint Review, Sprint Retrospective, Product Backlog Refinement, e outras reuniões. Faça o
somatório do tempo de reuniões agendado e desconte o tempo de reuniões.
8. Desconte Outras Interrupções: Anote o tempo gasto em reuniões permanentes, dias de férias
ou doença, correções de emergência, consultas médicas/dentárias, treinamento, e quaisquer
outras interrupções especiais. Subtraia o total de horas dessas interrupções das horas
produtivas possíveis após descontar o tempo de reuniões.
9. Reveja as Horas Produtivas Revisadas: Após descontar o tempo em reuniões e outras
interrupções, o número restante é o total revisado de horas produtivas possíveis para a
timebox.
10. Considere a Alocação do Projeto: Se a pessoa estiver 100% alocada a esse projeto, o total
revisado de horas produtivas é o tempo que ela pode se comprometer. Se a pessoa estiver
alocada em vários projetos, determine a porcentagem de tempo dedicada a este projeto.
Multiplique as horas produtivas revisadas por essa porcentagem.
11. Ajuste para a Troca de Contexto: Se a pessoa estiver trabalhando em múltiplos projetos,
desconte um adicional de 10% das horas calculadas no passo anterior para levar em
consideração a troca de contexto entre projetos.
12. Resultado Final: O número resultante é a capacidade total que a pessoa pode comprometer.
Ao seguir esses passos, cada membro da equipe pode determinar com mais precisão sua
capacidade para o Sprint, permitindo que a equipe faça previsões mais realistas e evite sobrecargas.
Conhecimentos individuais
A matriz de competência (Competency Matrix) é uma ferramenta de desenvolvimento de
habilidades e gerenciamento de talentos proposta no Management 3.0, um conjunto de práticas e
princípios de liderança e gestão desenvolvidos por Jurgen Appelo. A matriz de competência ajuda a
visualizar e analisar as habilidades e competências dos membros da equipe, identificando áreas de
melhoria e criando um plano de desenvolvimento para cada pessoa.
A matriz de competência é geralmente apresentada como uma tabela ou planilha, onde as colunas
representam os membros da equipe e as linhas representam as habilidades ou competências
relevantes para o trabalho em questão. Cada célula na matriz indica o nível de habilidade ou
competência de um membro da equipe em uma determinada área.
Para criar uma matriz de competência, siga estas etapas:
1. Identifique as habilidades e competências relevantes: Liste as habilidades e competências
que são importantes para o sucesso do projeto ou da organização. Isso pode incluir habilidades
técnicas, habilidades de gerenciamento, habilidades de comunicação, entre outras.
2. Avalie os membros da equipe: Peça aos membros da equipe que avaliem suas próprias
habilidades e competências usando uma escala de classificação (Iniciante, Praticante
e Expert).
3. Preencha a matriz: Insira as avaliações de cada membro da equipe na matriz, preenchendo as
células apropriadas.
28
4. Analise a matriz: Identifique as áreas em que a equipe é forte e as áreas que precisam de
melhoria. Isso pode ajudar a determinar onde concentrar os esforços de desenvolvimento e
treinamento.
5. Desenvolva planos de ação: Com base na análise da matriz, crie planos de ação
individualizados para os membros da equipe para melhorar suas habilidades e competências.
Isso pode incluir treinamento, mentoria, atribuição de novas responsabilidades ou outras
atividades de desenvolvimento.
A matriz de competência é uma ferramenta útil pois ajuda a identificar lacunas nas habilidades e
competências da equipe e a criar planos de ação para melhorar o desempenho e a eficácia da equipe.
Além disso, pode ajudar a promover a comunicação e a colaboração entre os membros da equipe e a
incentivar o crescimento e o desenvolvimento pessoal.
Estimativa Unitária ou Estimativas dos Itens Sozinhos

Neste passo, a equipe deve estimar o tamanho dos itens de trabalho em uma unidade de medida
comum, como horas ideais, dias ideais, semanas de desenvolvimento, dog points ou t-shirt sizes. O
ideal é que a estimativa seja feita em grupo, utilizando uma técnica como o Planning Poker.
No Planning poker cada membro da equipe recebe um conjunto de cartas com números baseados
na sequência de Fibonacci. Para cada item, os membros da equipe selecionam uma carta que
represente sua estimativa de tamanho e a revelam simultaneamente. As discrepâncias nas estimativas
são discutidas, e o processo é repetido até que um consenso seja alcançado.
Protocolo de Decisão
O Protocolo de Decisão é um conjunto de regras e diretrizes que orienta a tomada de decisões em
grupos ou organizações. Ele ajuda a garantir que as decisões sejam tomadas de maneira eficiente, justa
e inclusiva, considerando as opiniões e perspectivas de todos os envolvidos. Um protocolo de decisão
bem definido pode melhorar a comunicação, promover a colaboração e reduzir conflitos, levando a
decisões mais informadas e eficazes.
Existem várias formas de tomada de decisão, incluindo consenso, voto majoritário, maior risco e
menor risco, misto. Cada método tem suas vantagens e desvantagens, e a escolha do método mais
adequado depende do contexto e das metas do grupo.
De forma exemplificada, em um contexto em que os developers estimam o item Pagamento por
Cartão de Crédito com os seguintes tamanhos: 3, 5, 8, 8, 8, 13
Consenso
A tomada de decisão por consenso busca o acordo de todos os membros do grupo. Este método
promove a colaboração e garante que todas as opiniões sejam ouvidas e levadas em consideração. O
consenso pode levar a decisões mais sólidas e bem fundamentadas, pois incorpora diversas
perspectivas. Ele também pode aumentar o comprometimento e a satisfação dos membros do grupo,
29
já que todos se sentem envolvidos no processo de decisão. A tomada de decisão por consenso pode
ser demorada e, em alguns casos, pode levar a um impasse se o grupo não conseguir chegar a um
acordo.
No cenária do Pagamento por Cartão de Crédito e com o protocolo de decisão por Consenso os 6
desenvolvedores trabalhariam juntos para discutir as estimativas e chegar a um consenso sobre a
estimativa final. Dessa forma não é possível inferir uma estimativa final apenas com a informação das
estimativas, pois o resultado sairia após mais discussão.
Voto majoritário ou Voto democrático

Neste método, a decisão é tomada com base na opção que recebe a maioria dos votos. Geralmente,
é um processo rápido e simples de tomada de decisão. O voto majoritário é eficiente e fácil de
implementar, e geralmente leva a decisões rápidas. O voto majoritário pode excluir opiniões
minoritárias e levar a uma falta de comprometimento por parte daqueles que não concordam com a
decisão tomada. Caso tenha um número par de desenvolvedores, pode ser necessário definir um
critério de desempate. Se houver um empate pode ser necessário escolher um outro critério para
desempate.
No cenária do Pagamento por Cartão de Crédito e com o protocolo de Voto Majoritário ou Voto
Democrático como a estimativa mais frequente é 8 que aparece 3 vezes. Dessa forma estimativa final
seria de 8 pontos.
Maior risco
A tomada de decisão baseada no maior risco envolve a escolha da opção que apresenta o maior
potencial de recompensa, mesmo que também apresente um risco significativo. O método do maior
risco pode levar a resultados mais significativos e inovadores, pois estimula a tomada de riscos e a
busca por soluções ambiciosas. Escolher opções de maior risco pode aumentar a probabilidade de
fracasso e pode não ser adequado para organizações ou projetos com tolerância limitada ao risco.
No cenária do Pagamento por Cartão de Crédito e com o protocolo de decisão de Maior Risco, a
estimativa final seria baseada na estimativa do desenvolvedor que identificou mais riscos. Dessa forma
a estimativa final seria 13 pontos.
Menor risco
Neste método, a decisão é tomada com base na opção que apresenta o menor risco, mesmo que a
recompensa potencial seja menor. A tomada de decisão com base no menor risco pode ser mais segura
e estável, reduzindo a probabilidade de fracasso. A abordagem de menor risco pode limitar a inovação
e o crescimento, já que o grupo pode evitar tomar decisões ambiciosas e criativas.
No cenária do Pagamento por Cartão de Crédito e com o protocolo de decisão de Menor Risco a
estimativa final seria baseada na estimativa do desenvolvedor que identificou menor riscos. Dessa
forma estimativa final seria 3 pontos.
Protocolo Misto
Poderíamos ter um protocolo de decisão misto que combina várias técnicas de tomada de decisão
em grupo. Nesse caso, poderíamos seguir as seguintes etapas:
1. Cada desenvolvedor fornece sua estimativa individualmente.
2. Os 6 desenvolvedores discutem as estimativas e trabalham juntos para chegar a um consenso
sobre a estimativa final. Se não for possível chegar a um consenso, passamos para a etapa 3.
30
3. Os 6 desenvolvedores fornecem uma segunda estimativa individualmente.
4. Os 6 desenvolvedores discutem novamente as estimativas e trabalham juntos para chegar a
um consenso sobre a estimativa final. Se ainda não for possível chegar a um consenso,
passamos para a etapa 5.
5. Os 6 desenvolvedores fornecem uma terceira e última estimativa individualmente.
6. Se ainda não for possível chegar a um consenso sobre a estimativa final, aplicamos uma das
técnicas de tomada de decisão em grupo restantes, com base em um dos critérios: Maior risco,
Menor risco, Voto majoritário
Essa abordagem mista permite que a equipe explore diferentes opções de tomada de decisão e
trabalhe juntos para chegar a uma estimativa final precisa e confiável. É importante enfatizar a
importância da colaboração, do diálogo aberto e da consideração de múltiplas perspectivas durante
todo o processo de estimativa.
Avaliação de Quanto Trabalho Pode-se Entregar

Algumas abordagens para avaliar a quantidade de trabalho uma equipe pode entregar: capacidade,
velocidade, comprometimento.
Capacidade (Capacity Driven)

Correlaciona o tempo estimado por item com a capacidade produtiva individual de cada membro
da equipe, considerando a disponibilidade e habilidades.
A maior vantagem é que é semelhante ao modelo em cascata. As maiores desvantagens dessa
técnica é que os seres humanos são péssimos em entender o tamanho em tempo, e a capacidade
produtiva varia e que pode encorajar a equipe a trabalhar mais horas em vez de aumentar a
produtividade.
A seguir um passo a passo de como se facilitar compromisso de uma equipe com foco na
capacidade.
1. Divisão de Tarefas: Para cada item, defina as tarefas específicas necessárias para a conclusão.
2. Estime Horas Ideais: Determine as horas ideais de engenharia necessárias para cada tarefa
individual. Estas são as horas que um membro da equipe levaria para concluir a tarefa sem
interrupções.
3. Quebre tarefas grandes: quebre as tarefas que tenham uma duração maior que oito horas
ideias. Para isso divida as tarefas grandes em passos, cada passo se torna uma tarefa e deve
ser reestimado.
4. Total de Horas Ideais Estimado: Some as horas ideais de engenharia para todas as tarefas. Isso
fornece uma visão abrangente do esforço total necessário para os itens selecionados.
5. Capacidade Individual: Cada membro da equipe calcula a quantidade realista de horas que
pode contribuir. Esta etapa leva em consideração todas as reuniões, folga, férias, e quaisquer
outras restrições de tempo potenciais. Utilize a Capacity Calculator do David Prior para
melhores resultados.
6. Capacidade Total da Equipe: Colete as horas de todos os membros da equipe para obter uma
visão coletiva das horas ideais totais que a equipe pode investir.
31
7. Reajustando o Escopo: Compare os resultados de Total de Horas Ideais Estimado e a
Capacidade Total da Equipe. Se Total de Horas Ideais Estimado é maior que a Capacidade
Total da Equipe a equipe pode estar se comprometendo em excesso. Isso significa um possível
rearranjo dos itens ou uma redução do escopo dos itens. Se Total de Horas Ideais Estimado é
menor que a Capacidade Total da Equipe, a equipe pode ter espaço para incluir itens
adicionais.
Velocidade (Velocity Driven)

A Velocidade representa a quantidade de trabalho concluído pela equipe em cada timebox. A
velocidade é calculada somando a unidade de medida dos itens ou a quantidade de itens concluídos
no final da timebox. Vale destacar que a velocidade é o output e não mede o resultado.
Como vantagens temos que uma abordagem matemática e rápida para determinar a quantidade
de trabalho e baseia-se em dados históricos, o que pode aumentar a precisão das estimativas. Como
desvantagens para calcular a velocidade é necessário ter uma base histórica e estabilidade para ser
eficaz, difícil aumentar a produtividade, pois pode estabelecer um máximo com base na velocidade
anterior e não leva em consideração mudanças na equipe, como novos membros ou mudanças nas
habilidades.
O Yesterday Weather pode ser o número de itens entregues na última timebox ou a soma da
unidade de medida de todos os itens entregues. Estudos indicam que o Yesterday Weather é a técnica
de previsão com a menor margem de erro para a próxima timebox.
A Velocidade Média calcule a média do número de itens entregues na última timebox ou a média
da soma da unidade de medida de todos os itens entregues.
Utilize o Yesterday Weather ou a Velocidade Média como um guia para definir quanto trabalho
pode ser comprometido na próxima timebox.
Comprometimento (Commitment Driven)

O compromisso é considerado antes de planejar o volume de trabalho. Ou seja, a equipe se
compromete com um item do backlog do produto de cada vez, identificando e estimando
aproximadamente as tarefas envolvidas, e parando quando sentem que terminaram (e se terminaram,
não podem aceitar mais).
A maior vantagem é que permite ajustes conforme as necessidades e aumenta a confiança e o
envolvimento da equipe, já que eles participam diretamente do processo de comprometimento. A
maior desvantagem é que requer confiança e entendimento entre os membros da equipe e uma forma
mais subjetiva, o que pode levar mais facilmente a imprecisões e maior margem de erro.
A seguir um passo a passo de como se facilitar compromisso de uma equipe com foco no
compromisso.
1. Identificar o objetivo do Sprint: Antes de qualquer coisa o objetivo deve ser claramente
estabelecido, em outras palavras o que se deve esperar ao final da timebox. Isso define a
direção e o foco, garantindo que todos estejam alinhados com uma meta em comum.
2. Selecionar um item do backlog do produto: A equipe, juntamente com o Product Owner,
revisa o backlog do produto e seleciona um item (normalmente, uma história de usuário) que
esteja alinhado com o objetivo do Sprint. Este item deve ser prioritário e relevante para a meta
definida.
32
3. Dividir histórias em tarefas: Depois de selecionada a história, é importante dividi-la em tarefas
menores e mais gerenciáveis. Cada tarefa deve ser clara, concisa e diretamente relacionada à
história de usuário em questão.
4. Estimar tarefas: A equipe realiza uma estimativa para cada tarefa, considerando o esforço, a
complexidade e quaisquer outros fatores relevantes. As técnicas de estimativa podem variar,
incluindo o uso de pontos de história, horas ideais, entre outras.
5. Pedir compromisso da equipe: Após a estimativa, a equipe reflete sobre a quantidade de
trabalho e decide coletivamente se pode se comprometer com ele para o Sprint. O
compromisso aqui é fundamental, pois é uma promessa da equipe de que fará o seu melhor
para concluir o trabalho dentro do prazo do Sprint.
6. Repetir o processo conforme necessário: Se a equipe concordar em se comprometer com a
história e suas tarefas, ela então volta ao backlog do produto para selecionar a próxima
história. As etapas 2 a 5 são repetidas até que a equipe sinta que atingiu sua capacidade
máxima para o Sprint, ou seja, até que sintam que não podem comprometer-se com mais
trabalho.
Referencias
https://drunkenpm.blogspot.com/2013/02/individual-capacity-calculator.html
https://www.dropbox.com/s/ffk3pq2f9e33c12/Capacity%20Calculator%20w%20Corrected%20Meeti
ng%20Times-icloud.xlsx?dl=0
https://www.mountaingoatsoftware.com/blog/why-i-prefer-capacity-driven-sprint-planningcom
https://www.linkedin.com/pulse/velocity-driven-planning-vs-commitment-jayaram-hegde/
https://techbeacon.com/app-dev-testing/noestimates-debate-unbiased-look-origins-arguments-
thought-leaders-behind-movement
https://netmind.net/en/does-noestimates-really-work/
33
Estamos atrasados?
No universo das metodologias ágeis, a estimativa tem um papel central. Enquanto as equipes ágeis
perseguem a entrega contínua de valor, a necessidade de prever a conclusão do trabalho é tanto um
imperativo quanto um desafio. Mas, a questão que frequentemente ronda a mente de todos, desde o
Scrum Master até o Product Owner, é: "Estamos atrasados?" Para responder a esta pergunta, este
capítulo se debruçará sobre duas perspectivas temporais: o curto e o longo prazo. Através dessas
lentes, examinaremos técnicas de estimativa e como elas se aplicam para proporcionar uma resposta
informada e realista à pergunta em destaque.
Curto Prazo
Para o curto prazo a técnica de Yesterday Weather e a técnica de velocidade média são uteis para
extrapolar a capacidade de entrega para a próxima Sprint.
Yesterday's Weather é uma técnica de estimativa ágil que se baseia na premissa de que a melhor
previsão do desempenho futuro de uma equipe é seu desempenho recente. Ao usar o desempenho
passado como base, a técnica Yesterday's Weather ajuda a prever a quantidade de trabalho que uma
equipe pode realizar na próxima iteração ou sprint.
A velocidade média é uma métrica que indica a quantidade média de trabalho concluído por uma
equipe em uma iteração ou sprint. Ela pode ser calculada somando o número de itens concluídos em
várias sprints e dividindo o total pelo número de sprints.
Tendo em vista o cenário:
Sprint Entrega
Alberto 2
Barbara 3
Carlos 3
Daniela 4
Para calcular o Yesterday Weather para a Sprint 5 no cenário fornecido é 4. Portanto, o Yesterday
Weather sugere que a equipe provavelmente concluirá cerca de 4 itens na Sprint 5, assumindo que as
condições sejam semelhantes a sprint anterior.
Para calcular a Velocidade Média para a Sprint 5 no cenário fornecido:
𝑆𝑜𝑚𝑎 𝑑𝑎𝑠 𝐸𝑛𝑡𝑟𝑒𝑔𝑎𝑠
Velocidade Média =
𝑁𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝐸𝑛𝑡𝑟𝑒𝑔𝑎𝑠
Dessa forma:
2 + 3 + 3 + 4 12
Velocidade Média = = =4
4 4
Com base nesses cálculos, a velocidade média da equipe é de 3 itens por sprint. Portanto, a
velocidade média sugere que a equipe provavelmente concluirá cerca de 3 itens na Sprint 5,
assumindo que as condições sejam semelhantes às sprints anteriores.
34
No entanto, é importante lembrar que a técnica Yesterday's Weather e a Velocidade Média são
apenas uma estimativa e pode não ser precisa em todos os casos, especialmente se houver mudanças
significativas nas condições do projeto ou na equipe.
Longo Prazo
Para longo prazo, https://www.infoq.com/articles/noestimates-monte-carlo/
Referencias
https://www.infoq.com/articles/noestimates-monte-carlo/
https://scrumage.com/blog/2015/09/agile-project-forecasting-the-monte-carlo-method/
35

1693228378456E Book - Desmistificando Estimativas Ágeis V2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1693228378456E Book - Desmistificando Estimativas Ágeis V2

Enviado por

Direitos autorais:

Formatos disponíveis

Anderson Hummel é um Agile Coach que auxilia profissionais

na transição para o mundo da agilidade. Quase 10.000 alunos

Desmistificando as Estimativas Ágeis: de dog points a velocidade

Katniss Everdeen - Baixa precisão e alta acurácia Katniss Everdeen, a protagonista

Gavião Arqueiro - Alta precisão e baixa acurácia Gavião Arqueiro, o habilidoso

Chapolin Colorado - Baixa precisão e baixa acurácia Chapolin Colorado, o herói

Cone da incerteza e a previsão do tempo

Cone da incerteza no desenvolvimento cascata

Os problemas mais comuns de estimativas no ágil

Como estimar o custo de um projeto?

Como quantificar o tamanho de um item?

Como estimar vários itens rapidamente?

Quanto trabalho podemos nos comprometer em uma janela de tempo?

Margem de Erro Inferior e Superior

Cálculo da Margem de Erro

Estimativa de ordem de magnitude

𝑀𝑎𝑟𝑔𝑒𝑚 𝑑𝑒 𝐸𝑟𝑟𝑜 𝑆𝑢𝑝𝑒𝑟𝑖𝑜𝑟 = 𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑣𝑎 × 75%

𝑀𝑎𝑟𝑔𝑒𝑚 𝑑𝑒 𝐸𝑟𝑟𝑜 𝑆𝑢𝑝𝑒𝑟𝑖𝑜𝑟 = 𝐸𝑠𝑡𝑖𝑚𝑎𝑡𝑖𝑣𝑎 × 25%

Projeto Estimativa Realizado

Projeto Estimativa Realizado Diferença

Semanas de uma Equipe

Como comparar o tamanho dos itens

Método de estimativa de três pontos

Estimativa por afinidade / Affinity Estimation

Tamanho Máximo Permitido (Maximum allowable size)

Grande, Incerto e o Pequeno (Big, Uncertain, Small)

2. Alocação nos Buckets de Dificuldade

3. Alocação nos Buckets de Esforço

É associado o tamanho de 2 semanas ao bucket E--

Análise de Restrições e preparação

Cálculo de Horas produtivas Individuais

Estimativa Unitária ou Estimativas dos Itens Sozinhos

Voto majoritário ou Voto democrático

Avaliação de Quanto Trabalho Pode-se Entregar

Capacidade (Capacity Driven)

Velocidade (Velocity Driven)

Comprometimento (Commitment Driven)

Você também pode gostar