Por que equipes Agile estimam, como a incerteza altera a estimativa, o que o dimensionamento relativo realmente significa, como esforço, complexidade, risco e tamanho se relacionam e por que estimativas apoiam previsões sem se tornarem promessas ou prazos
Tempo estimado de leitura: 25 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender por que a estimativa pode ser útil; distinguir estimativas de prazos e previsões; raciocinar sobre incerteza, , esforço, complexidade, risco e tamanho; compreender os limites de e estimativas baseadas em tempo; e explicar por que, no , os que executarão o trabalho são responsáveis por dimensionar os Items.
Introdução: estimar é tomar decisões melhores, não prever o futuro com perfeição
Uma estimativa é útil quando melhora uma decisão. Ela se torna perigosa quando as pessoas confundem a incerteza expressa por um número com uma certeza garantida por uma equipe.
O desenvolvimento de software e de produtos sempre envolveu estimativas. As organizações precisam decidir se uma ideia vale a pena, comparar alternativas, coordenar investimentos, compreender capacidade e comunicar possíveis janelas de entrega. Muito antes dos métodos , planos de projeto tentavam converter trabalho em horas, custos, marcos e datas de conclusão.
A dificuldade é que o trabalho complexo de produto contém incerteza que não pode ser eliminada simplesmente estimando com mais cuidado. Um requisito pode ser mal compreendido. Uma dependência pode se comportar de maneira diferente do esperado. Um desenho técnico pode revelar trabalho oculto. Um experimento com usuários pode mostrar que a funcionalidade original deixou de ser valiosa. A estimativa pode ter sido razoável quando foi criada e, ainda assim, tornar-se incorreta porque a realidade mudou.
As práticas de estimativa surgiram, em parte, como resposta a esse problema. Em vez de fingir que cada item pode ser convertido antecipadamente em uma duração precisa, muitas equipes passaram a estimar de forma relativa: este item parece menor do que aquele, maior do que outro e aproximadamente comparável a algo que já concluímos. , tamanhos de camiseta, , estimativa por afinidade e técnicas relacionadas tornaram-se comuns.
O , porém, não prescreve nenhuma dessas técnicas. O Scrum Guide atual afirma que o pode adicionar detalhes como descrição, ordem e tamanho, e que os que realizarão o trabalho são responsáveis pelo . Ele não exige , horas, números de Fibonacci, , velocity nem sequer uma definição universal de tamanho.
Essa flexibilidade é importante. Uma equipe pode usar relativo porque isso melhora as conversas sobre o . Outra pode utilizar e simplesmente garantir que os PBIs sejam pequenos o suficiente para se tornarem Done dentro de uma . Outra pode usar estimativas baseadas em tempo porque seu contexto as torna úteis. O método correto é aquele que ajuda a equipe a tomar decisões melhores sem prejudicar a transparência.
Para candidatos à , os limites essenciais são mais importantes do que qualquer técnica de estimativa: os são responsáveis pelo ; o pode influenciar por meio do contexto de valor e dos trade-offs; o escopo selecionado para a é uma , não um compromisso absoluto; o é o compromisso do ; e as previsões devem se apoiar em evidências, em vez de tratar estimativas como promessas.
Por que estimar?
A estimativa não possui valor intrínseco. Seu valor vem das decisões que ela viabiliza. Antes de estimar um PBI, uma pergunta útil é: qual decisão ficará melhor por termos esta estimativa?
Um pode precisar comparar um item pequeno e de alto valor com outro muito maior e de valor inferior. podem precisar determinar se um PBI é pequeno o suficiente para se tornar Done dentro de uma . Stakeholders podem precisar de uma . O pode querer tornar a incerteza visível antes de selecionar o trabalho.
A estimativa, portanto, pode apoiar ordenação, refinement, , discussão de riscos, decomposição, decisões de investimento e . Ela também pode revelar divergências. Se um Developer considera um PBI pequeno e outro o considera muito grande, a diferença costuma ser mais valiosa do que o número final, pois expõe pressupostos diferentes.
A estimativa se torna desperdício quando nenhuma decisão depende dela. Passar horas atribuindo números precisos a PBIs de baixa prioridade, que talvez nunca sejam construídos, cria um estoque de pressupostos em vez de transparência útil.
Princípio orientado à decisão
Estime porque a estimativa melhorará uma decisão real - não porque se espera que todo item do backlog tenha um número.
Incerteza: a razão pela qual estimativas são estimativas
Uma estimativa existe porque o futuro é incerto. Se a quantidade exata de trabalho já fosse conhecida, estimar seria desnecessário; a equipe poderia simplesmente declarar a quantidade conhecida.
A incerteza pode surgir de comportamento de produto pouco claro, tecnologia desconhecida, dependências de integração, regulamentação em mudança, restrições de desempenho, problemas ocultos em dados, fornecedores externos, conhecimento da equipe ou respostas desconhecidas dos usuários.
À medida que o trabalho se aproxima da implementação e a equipe aprende mais por meio do refinement, parte da incerteza pode ser reduzida. Ainda assim, o trabalho complexo preserva incerteza residual até que o produto seja efetivamente criado e inspecionado.
Equipes profissionais, portanto, evitam comunicar estimativas com falsa precisão. Um PBI de 13 pontos não é matematicamente 30% mais previsível do que um PBI de 10 pontos. Uma estimativa de seis dias não garante que o trabalho estará concluído exatamente em seis dias corridos.
O Scrum Guide fundamenta explicitamente decisões voltadas ao futuro em evidências: em ambientes complexos, o que acontecerá é desconhecido, e o que já aconteceu pode informar decisões futuras. Estimativas são mais fortes quando combinadas com evidências históricas, e não tratadas como previsões isoladas.
Incerteza é informação
Grande dispersão entre estimativas, muitos desconhecidos ou dificuldade para dimensionar um PBI costumam ser sinais para refinar, dividir, experimentar ou aprender - não motivos para forçar um número mais preciso.
Estimativa absoluta e relativa
A estimativa absoluta expressa um tamanho ou esforço esperado usando uma unidade definida, frequentemente horas ou dias. A compara um item com outro e expressa o tamanho usando uma escala abstrata ou comparativa.
Por exemplo, uma equipe pode dizer que um PBI tem aproximadamente o dobro do tamanho de um item de referência familiar. A equipe pode representar essa comparação com 2 e 5 , tamanhos Small e Large de camiseta ou outra escala interna.
A tornou-se popular nas comunidades porque muitas equipes consideram mais fácil comparar do que prever a duração exata de um trabalho desconhecido. Ela também reduz a tentação de interpretar cada estimativa como uma promessa pessoal de horas.
Entretanto, afirmações de que seres humanos são cientificamente comprovados como universalmente melhores em do que absoluta devem ser tratadas com cautela. A revisão histórica da Alliance observa que as pesquisas frequentemente citadas para sustentar essa afirmação não são conclusivas. A ainda pode ser útil; ela simplesmente não deve ser justificada como um fato científico incontestável.
Estimativa absoluta e relativa
Abordagem
Exemplos
Benefício potencial
Risco comum
Absoluta
Horas, dias,
Fácil de compreender; pode apoiar algum planejamento operacional
Frequentemente interpretada como prazo ou compromisso pessoal
Relativa
, tamanhos de camiseta, escalas personalizadas
Estimula comparação e discussão sobre o trabalho
Pode perder o sentido se as equipes converterem pontos novamente em horas ou compararem equipes
Fluxo / right
,, contagem de itens, teste de tamanho suficiente
Usa dados históricos de conclusão e pode reduzir o custo de estimar
Exige divisão de itens razoavelmente consistente e dados de fluxo confiáveis
O que significa tamanho?
O Scrum Guide usa a palavra size, mas deliberadamente não define uma fórmula. As equipes precisam de uma interpretação compartilhada que sustente decisões úteis.
Na prática comum com , o tamanho costuma ser tratado como uma do esforço total necessário para levar um PBI até Done. A quantidade de trabalho, a complexidade técnica, o risco e a incerteza podem influenciar esse esforço.
Esta distinção é importante: complexidade, por si só, não é tamanho. Uma alteração tecnicamente simples repetida em centenas de telas pode envolver grande volume de trabalho. Uma pequena alteração de código em um protocolo de segurança desconhecido pode envolver pouco volume, mas muita incerteza e risco. Qualquer um desses casos pode, de forma razoável, receber um tamanho maior, dependendo de como esses fatores afetam o esforço necessário para chegar a Done.
As equipes podem definir tamanho de maneira diferente ao usar outras abordagens de estimativa. O requisito crítico é a compreensão compartilhada. Se metade dos dimensiona apenas a complexidade do código, enquanto os demais incluem testes, deployment, risco e integração, os números resultantes não são transparentes.
Modelo mental útil para relativo
O tamanho relativo pode refletir o esforço para levar o PBI inteiro até Done, influenciado por quantidade de trabalho, complexidade, risco e incerteza. O próprio não prescreve essa fórmula nem .
Esforço: o trabalho necessário para chegar a Done
Esforço diz respeito ao trabalho total necessário para transformar um PBI em parte de um Done. Deve incluir mais do que codificação ou a atividade mais visível.
Se a exige testes automatizados, verificação de segurança, acessibilidade, documentação, integração, observabilidade, verificações de desempenho ou prontidão para deployment, essas atividades afetam o esforço real e devem influenciar o quando a equipe utiliza uma técnica orientada a esforço.
Ignorar a subestima sistematicamente o trabalho. Uma equipe pode aparentar estimar corretamente durante a implementação e, repetidamente, descobrir grandes quantidades de trabalho de finalização no fim da .
Esforço também deve ser distinguido da velocidade individual. O relativo normalmente tenta estimar o trabalho como um problema da equipe, supondo que com as habilidades adequadas colaborem para concluí-lo, em vez de prever quanto tempo uma pessoa específica levará.
Complexidade: dificuldade é um componente, não a estimativa inteira
Complexidade descreve o grau de dificuldade para compreender, desenhar, coordenar ou implementar o trabalho. Trabalho complexo pode exigir mais experimentação, mais raciocínio técnico, mais integração ou mais retrabalho antes que a solução correta emerja.
Mas a complexidade só importa para o na medida em que altera o trabalho necessário para chegar a Done. Um conceito pode ser intelectualmente complexo, porém rápido de implementar depois de compreendido. Outro item pode ser simples, mas enorme em volume.
Por isso, chamar de 'pontos de complexidade' pode gerar confusão. Muitas abordagens amplamente utilizadas com , incluindo a de Mike Cohn, tratam a complexidade como um fator que influencia o esforço total, e não como a única coisa medida.
Risco e incerteza: estimando o trabalho que talvez descubramos
Risco é a possibilidade de que um evento ou condição aumente o custo, o esforço ou a dificuldade de concluir o PBI. Incerteza é a ausência de conhecimento sobre aquilo que a equipe encontrará.
Uma API de terceiros pode ser instável. Uma migração de dados pode revelar registros corrompidos. Um novo mecanismo de segurança pode se comportar de forma diferente em escala. Essas possibilidades podem aumentar o esforço esperado mesmo quando a implementação do caminho feliz parece pequena.
As equipes devem ter cuidado para não esconder incerteza extrema dentro de uma estimativa muito grande. Quando a incerteza domina o número, um experimento, um PBI de aprendizado semelhante a um spike, uma prova de conceito ou uma menor pode gerar informação melhor do que simplesmente atribuir mais pontos.
O não define spikes como elemento do framework, mas trabalho de aprendizado pode ser representado no quando necessário para melhorar o produto ou reduzir a incerteza.
Entrada para o
Entrada para o
Pergunta para os
Quantidade de trabalho
Quanto precisa efetivamente ser construído, alterado, verificado, integrado, documentado ou disponibilizado?
Complexidade
Quão difícil é a solução, o raciocínio, a coordenação ou a validação?
Risco
Quais eventos podem adicionar trabalho ou causar retrabalho?
Incerteza
Quais fatos importantes ainda são desconhecidos?
Qual trabalho recorrente de qualidade é necessário antes que o item conte como concluído?
Estimativa vs. prazo
Uma estimativa descreve aquilo em que a equipe acredita atualmente sobre o trabalho. Um deadline descreve uma data ou restrição temporal imposta pelo produto ou pelo ambiente. Não são a mesma coisa.
Um deadline pode ser real: uma regulamentação entra em vigor em determinada data, um contrato expira, um evento físico ocorre ou uma janela de mercado se fecha. A estimativa pode ajudar o a compreender se um escopo desejado parece viável antes dessa data.
O padrão perigoso consiste em transformar a própria estimativa em prazo: um Developer diz que um PBI parece exigir três dias, e a gestão conclui que ele deve estar concluído três dias depois. A estimativa foi convertida de informação em promessa sem considerar filas, colaboração, incerteza, mudança de escopo ou novas evidências.
Quando existe uma data fixa, o não a elimina. O e o podem adaptar escopo, ordenação, investimento, experimentos e estratégia de release para maximizar a chance de criar o resultado mais valioso dentro dessa restrição.
Lembre-se
Estimativa = atual sobre o trabalho. Deadline = restrição de tempo. Forecast = baseada em evidências sobre uma provável entrega futura. Esses conceitos podem se informar mutuamente, mas não são sinônimos.
Estimativa vs.
A estimativa normalmente diz respeito ao tamanho ou esforço de Items individuais ou grupos de trabalho. usa evidências para prever o que pode acontecer no futuro, como quanto trabalho pode caber em uma ou quando um conjunto de resultados pode ser entregue.
Uma equipe pode usar estimativas como uma das entradas de um forecast. Por exemplo, velocity histórica pode combinar estimativas relativas com dados de conclusão anteriores. Outra equipe pode evitar inteiramente e fazer usando e .
O Scrum Guide não exige nenhuma técnica específica de . Ele menciona explicitamente práticas como burn-downs, burn-ups e cumulative flows, ao mesmo tempo em que alerta que elas não substituem o .
Durante a , os aumentam a confiança do forecast usando conhecimento de desempenho passado, capacidade futura e a . Este é um princípio importante da : evidências importam mais do que a aparente precisão de um método de .
e itens de referência
A funciona por comparação. A equipe primeiro estabelece um ou mais itens de referência conhecidos e, em seguida, pergunta se os novos PBIs são menores, semelhantes ou maiores.
Itens de referência reduzem discussões abstratas. Em vez de perguntar 'isso é cinco ou oito?', os podem perguntar: 'isso claramente representa mais trabalho e incerteza do que o item de busca de pagamentos de cinco pontos que concluímos no mês passado?'. O número é secundário; a comparação é o mecanismo.
Muitas equipes usam escalas não lineares, como 1, 2, 3, 5, 8 e 13, para desencorajar falsa precisão em tamanhos maiores. Tamanhos de camiseta como XS, S, M, L e XL podem cumprir o mesmo propósito.
Novamente, o não exige essas escalas. As equipes devem evitar gastar mais tempo calibrando o sistema de estimativa do que aprendendo sobre o trabalho do produto.
: estimativa como conversa
é uma técnica popular de cuja forma atual foi descrita por James Grenning em 2002 e posteriormente popularizada na comunidade por meio do livro Estimating and Planning, de Mike Cohn.
Os participantes escolhem um tamanho de forma independente, revelam as estimativas ao mesmo tempo e discutem grandes diferenças. A conversa é a parte valiosa. Uma estimativa alta pode revelar testes ocultos, dependências, riscos ou trabalho de migração. Uma estimativa baixa pode revelar uma abordagem mais simples ou uma capacidade já existente.
O objetivo não deve ser forçar consenso matemático. A Alliance observa que tirar médias imediatamente ou forçar convergência pode apagar informações úteis sobre incerteza.
é opcional. Não é um evento do nem uma técnica obrigatória para a .
Os são responsáveis pelo
O Scrum Guide é explícito: os que realizarão o trabalho são responsáveis por dimensionar os Items.
Essa accountability existe porque os compreendem o trabalho necessário para criar um : implementação, integração, qualidade, testes, dependências, restrições técnicas e obrigações da .
O pode influenciar os ajudando-os a compreender valor e trade-offs. Por exemplo, o pode explicar que uma versão menor produziria a maior parte do valor. Isso pode alterar o próprio item e, portanto, seu tamanho.
Influência não é atribuição. O não deve ditar pontos nem pressionar os a reduzir estimativas para fazer um plano de release parecer melhor. Managers e Masters também não devem atribuir tamanhos.
Os também não precisam de unanimidade matemática em toda estimativa. A equipe precisa de compreensão compartilhada suficiente para tornar a estimativa útil para a decisão em questão.
Âncora para a
Os que executarão o trabalho são responsáveis pelo . O fornece contexto e trade-offs, mas não atribui o tamanho.
são opcionais - e específicos da equipe
são uma das unidades mais comuns de relativo, mas o não os exige.
Os pontos são intencionalmente abstratos. Um item de cinco pontos para a Equipe A não precisa significar a mesma coisa que cinco pontos para a Equipe B, pois as equipes têm habilidades, produtos, Definitions of Done, dependências e itens de referência diferentes.
Por isso, comparar velocity entre equipes costuma ser prejudicial. As equipes podem inflar estimativas, mudar a forma de dividir o trabalho e otimizar a métrica em vez dos resultados do produto.
Os pontos também não devem ser convertidos por meio de uma equação permanente, como um ponto igual a um dia. Quando a conversão é fixa, a abstração se transforma em uma estimativa de tempo disfarçada.
Bem utilizados, os pontos podem apoiar compreensão compartilhada e no nível da equipe. Mal utilizados, podem se tornar notas de desempenho que reduzem a transparência.
Quando não estimar - ou quando estimar menos
A estimativa não é um objetivo em si. Alguns Teams conseguem tomar decisões eficazes com pouca ou nenhuma explícita.
Se os PBIs forem consistentemente pequenos e de tamanhos semelhantes, histórico pode apoiar sem atribuição de pontos. Se uma ideia de baixa ordenação provavelmente não será selecionada em breve, uma estimativa detalhada pode ser prematura. Se a estimativa não alterar ordenação, investimento, divisão ou planejamento, a conversa pode gerar pouco valor.
O Scrum Guide dá essa liberdade às equipes ao definir tamanho como um atributo, deixando as técnicas sensíveis ao contexto. O deve inspecionar se sua abordagem de estimativa melhora a transparência e a efetividade.
Exemplo prático - estimando um backlog de segurança de APIs
Imagine um responsável por uma plataforma de autenticação de APIs. O é melhorar a velocidade de onboarding de parceiros sem reduzir a segurança. O contém vários PBIs futuros.
Um item é adicionar alertas de expiração de certificados para parceiros. Outro é migrar a validação de certificados para um novo serviço de confiança. Um terceiro é adicionar um novo campo em um dashboard mostrando o status do certificado.
Os usam relativo com uma referência conhecida de cinco pontos: uma alteração de política de API concluída recentemente que exigiu implementação, testes automatizados, revisão de segurança, documentação e monitoramento em produção.
O campo do dashboard parece menor do que a referência. Ele reutiliza uma API existente e exige testes de regressão limitados. A equipe o dimensiona em dois pontos.
Os alertas de expiração de certificados exigem processamento agendado, regras de notificação, trabalho de template, monitoramento e vários edge cases. O trabalho não é tecnicamente difícil, mas há mais volume. Os o dimensionam em cinco pontos.
A migração para o serviço de confiança inicialmente parece semelhante, em volume de código, à referência de cinco pontos. Durante a discussão, um Developer explica que o comportamento de falha do serviço externo é pouco compreendido e que o desempenho em volume de produção é incerto. Outro observa que o rollback deve preservar os certificados atuais dos parceiros. A equipe reconhece risco e incerteza significativos e dimensiona o item em treze pontos.
O não pede à equipe que reduza treze para oito. Em vez disso, pergunta se um experimento menor poderia reduzir a incerteza. Os criam um PBI menor para validar o serviço de confiança com um conjunto limitado de certificados e medir a latência sob carga representativa.
Esse experimento é dimensionado em três pontos e ordenado antes. Depois de concluído, a equipe aprende que a latência é aceitável, mas a integração de rollback é mais complicada do que se esperava. O PBI de migração original é refinado e dividido em duas etapas menores e valiosas.
Essa é uma estimativa bem-sucedida, mesmo que o número original tenha mudado. A estimativa expôs a incerteza, desencadeou uma decisão de produto melhor e reduziu o risco antes que o comprometesse uma capacidade significativa.
Na , os não simplesmente somam até atingir uma meta de velocity. Eles consideram o desempenho histórico, a capacidade reduzida da próxima porque um Developer estará de licença e a . Os PBIs selecionados tornam-se uma ; o continua sendo o compromisso.
Anti-padrões comuns de estimativa
Anti-padrões comuns de estimativa
Anti-padrão
Por que enfraquece a estimativa
Estimativa = promessa
Stakeholders tratam um tamanho ou uma estimativa em horas como compromisso garantido de entrega.
Pontos convertidos em horas
O relativo vira estimativa de tempo disfarçada e perde sua finalidade.
Meta de velocity
Equipes são pressionadas a aumentar pontos em vez de melhorar valor, qualidade ou fluxo.
Comparar equipes por pontos
Escalas locais diferentes são tratadas como unidades padronizadas de produtividade.
Pontos baseados apenas em complexidade
Volume de trabalho, risco, incerteza e trabalho necessário para Done são ignorados.
atribui tamanho
A accountability dos e seu conhecimento de entrega são sobrepostos.
Estimativa sem decisão
Tempo é gasto dimensionando trabalho que não influenciará ordenação nem planejamento.
Falsa precisão
Equipes discutem 8 versus 9 como se estimar fosse matemática exata.
Ignorar a
Testes, segurança, integração ou deployment aparecem tarde, e os forecasts tornam-se pouco confiáveis.
Estimativa enorme em vez de aprendizado
Incerteza extrema é escondida dentro de um número grande em vez de ser reduzida por refinement ou experimentos.
Armadilhas comuns da sobre estimativa
Armadilhas comuns da sobre estimativa
Armadilha
Interpretação correta
exige .
Falso. não prescreve unidade de nem técnica de estimativa.
é obrigatório no .
Falso. É uma técnica complementar opcional.
O estima PBIs porque é responsável pelo .
Falso. Os que realizarão o trabalho são responsáveis pelo .
O atribui estimativas para manter a equipe consistente.
Falso. O pertence aos .
medem apenas complexidade.
Falso como regra geral. Abordagens comuns de esforço relativo consideram quantidade de trabalho, complexidade, risco e incerteza.
Um deve equivaler a um número fixo de horas.
Falso. Isso transforma uma escala relativa em estimativa de tempo disfarçada.
é uma métrica obrigatória do .
Falso. não exige a métrica velocity.
Um PBI grande deve simplesmente receber uma estimativa maior.
Incompleto. Se ele não puder se tornar Done dentro de uma , deve ser decomposto/refinado antes da seleção.
PBIs selecionados tornam-se um compromisso absoluto de escopo.
Falso. Eles são uma ; o é o compromisso.
As estimativas não devem mudar quando a compreensão melhora.
Falso. Novas informações podem alterar tamanho, escopo e forecasts.
Estimativas mais precisas sempre melhoram o planejamento.
Falso. Falsa precisão pode reduzir a transparência em vez de melhorá-la.
Estimar elimina a incerteza.
Falso. Estimativas representam incerteza; e aprendizado continuam necessários.
Um framework de raciocínio para questões da sobre estimativa
Finalidade: a estimativa ajuda uma decisão real de produto, , planejamento ou ?
Accountability: os que farão o trabalho são responsáveis pelo ?
: o influencia por meio de contexto de valor e trade-offs, em vez de atribuir números?
Liberdade de técnica: a resposta evita tornar , Fibonacci, ou velocity obrigatórios?
Done: o tamanho considera o trabalho necessário para atender à ?
Incerteza: a resposta permite que as estimativas mudem à medida que a compreensão melhora?
Tamanho vs. duração: evita supor que um tamanho relativo corresponde a uma duração fixa no calendário?
Forecast vs. compromisso: estimativas e PBIs selecionados são tratados como entradas para , e não como promessas absolutas?
Itens grandes: a equipe refina ou divide trabalho que não pode razoavelmente se tornar Done em uma ?
: desempenho histórico e resultados observados são tratados como evidências mais fortes do que precisão teórica?
Heurística rápida para a prova
O se importa que os PBIs sejam compreendidos e dimensionados o suficiente para um planejamento responsável. Ele não se importa se sua equipe usa pontos, horas, tamanhos de camiseta, ou outra técnica útil.
Conclusão: o objetivo são decisões melhores, não números mais bonitos
A estimativa existe porque o desenvolvimento de produtos exige decisões sob incerteza. As equipes precisam de maneiras de comparar trabalho, discutir riscos, compreender trade-offs, decidir se PBIs são pequenos o suficiente e criar forecasts responsáveis.
A tornou-se popular porque comparar pode ser mais simples e colaborativo do que fingir conhecer a duração exata. , tamanhos de camiseta, e técnicas semelhantes podem apoiar essas conversas, mas nenhuma delas é exigida pelo .
Tamanho não deve ser confundido apenas com complexidade. Em abordagens comuns de esforço relativo, quantidade de trabalho, complexidade, risco, incerteza e a podem influenciar o esforço necessário para concluir um PBI. A equipe precisa de uma interpretação compartilhada, não de uma fórmula universal do mercado.
Estimativas também não são deadlines. Um deadline é uma restrição de tempo. Uma estimativa é informação atual sobre o trabalho. usa estimativas, histórico, capacidade, dados de fluxo e outras evidências para prever resultados futuros prováveis.
A fronteira de accountability do é clara: os que farão o trabalho são responsáveis pelo . O contribui com valor, contexto e trade-offs, mas não dita a estimativa.
Evidências históricas devem, com o tempo, importar mais do que o ritual de estimar. O Scrum Guide orienta explicitamente os a considerar desempenho passado, capacidade futura e a ao formar forecasts para a . Uma equipe com bons dados de fluxo pode concluir que uma estimativa elaborada por acrescenta pouco valor.
Mais importante: as estimativas devem permanecer honestas sobre a incerteza. Quando uma estimativa revela divergência, risco ou um PBI grande demais para ser compreendido, a resposta correta pode ser mais refinement, um experimento menor ou decomposição - e não pressão para produzir um número mais bonito.
Na minha visão, a melhor estimativa não é o número mais próximo da realidade final. É a estimativa que fez a equipe descobrir algo importante cedo o suficiente para tomar uma decisão melhor. Estimar é valioso quando melhora o aprendizado, e não quando cria a ilusão de que a incerteza desapareceu.
Principais pontos
Estime apenas quando a estimativa apoiar uma decisão útil.
A incerteza é inerente ao desenvolvimento complexo de produtos e não pode ser eliminada com números mais precisos.
A estimativa absoluta usa unidades definidas, como horas ou dias; a compara itens entre si.
não exige ,, Fibonacci, tamanhos de camiseta, nem velocity.
O Scrum Guide identifica size como um detalhe do e atribui a responsabilidade pelo aos que executarão o trabalho.
O pode influenciar o esclarecendo valor e trade-offs, mas não atribui o tamanho.
Em abordagens comuns com , o esforço relativo pode ser influenciado por quantidade de trabalho, complexidade, risco e incerteza.
Complexidade, isoladamente, não é sinônimo de tamanho nem de .
A afeta o esforço real necessário para um PBI tornar-se completo.
Uma estimativa não é um prazo e não deve automaticamente se tornar uma promessa.
prevê entregas futuras prováveis usando evidências; a estimativa pode ser uma das entradas desse forecast.
Desempenho histórico, capacidade futura e aumentam a confiança nos forecasts da .
PBIs selecionados são uma ; o é o compromisso do .
PBIs grandes ou muito incertos podem exigir refinement, divisão ou experimentos, em vez de números simplesmente maiores.
Escalas de são específicas da equipe e não devem ser usadas para comparar produtividade entre equipes.
Evidências empíricas devem, com o tempo, importar mais do que a cerimônia de estimar.
