Como o histórico de entrega pode apoiar previsões locais - e por que a Velocity se torna perigosa quando equipes são comparadas, pontos viram metas ou um sinal de planejamento é confundido com produtividade, valor ou sucesso
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 o que significa na prática , como o histórico de entrega pode informar previsões, por que a variação entre Sprints é normal, por que a não pode ser comparada de forma significativa entre equipes, como a explica a , por que metas de prejudicam a transparência e por que a é uma ferramenta complementar e opcional, e não uma exigência do .
Introdução: uma medida útil pode se tornar prejudicial quando as pessoas começam a persegui-la
A pode ajudar uma equipe a perceber quanto trabalho ela normalmente conclui. No momento em que a organização pede à equipe que "aumente a ", o número começa a mudar de significado.
Há muito tempo, equipes precisam de uma resposta prática para uma pergunta simples de planejamento: com base no que realmente concluímos antes, quanto trabalho poderemos concluir a seguir? A surgiu como uma das respostas. Quando as equipes estimam Items com ou outra unidade local consistente de tamanho, podem somar a quantidade de trabalho Done concluída em uma e usar esse histórico como um dos insumos para previsões futuras.
Isso é atraente porque substitui a pura intuição por evidências. Em vez de prever somente com base em otimismo, a equipe pode observar Sprints recentes e identificar um intervalo. Se normalmente conclui entre 28 e 34 pontos de trabalho Done em condições semelhantes, esse intervalo pode ajudar a informar a ou uma de prazo mais longo.
Entretanto, carrega um nome perigoso. Ele soa como velocidade. Assim que líderes veem um número chamado , podem presumir que quanto maior, melhor; que uma crescente significa melhoria; e que duas equipes podem ser classificadas por seus totais. A .org alerta repetidamente que essa não é a finalidade da métrica. é um sinal de planejamento, e não uma medida de sucesso da equipe.
O problema se aprofunda quando a se transforma em meta. Se a gestão determina que uma equipe precisa aumentar de 30 para 40 pontos por , a equipe pode fazer a métrica melhorar sem produzir mais valor. Pode estimar o mesmo trabalho com números maiores, dividir itens de outra maneira, reduzir a qualidade, selecionar trabalho mais fácil ou simplesmente redefinir o que um ponto significa.
Esse é um exemplo clássico da . O economista britânico Charles Goodhart observou, na década de 1970, que, quando uma relação estatística é usada como instrumento de controle, essa relação pode se romper. A formulação moderna popular é: quando uma medida se torna uma meta, deixa de ser uma boa medida. A redação exata surgiu mais tarde, mas o mecanismo subjacente se aplica de forma notável ao uso inadequado de métricas .
O , por si só, não exige . O Scrum Guide de 2020 nem sequer utiliza esse termo. O Guia afirma, porém, que, em ambientes complexos, apenas o que já aconteceu deve ser usado para decisões voltadas ao futuro e que o conhecimento sobre o desempenho passado pode aumentar a confiança nas previsões da . A é apenas uma possível forma de representar esse histórico.
Portanto, a pergunta profissional não é " é boa ou ruim?". A pergunta mais adequada é: "Qual decisão estamos tentando melhorar e essa métrica histórica aumenta a transparência sem distorcer o comportamento?". Este capítulo desenvolve essa distinção em profundidade.
O que é ?
é uma medida local da quantidade de trabalho dimensionado que uma equipe conclui como Done durante um , normalmente uma . Quando são utilizados, as equipes geralmente calculam a da somando os dos Items que alcançaram Done durante aquela .
Por exemplo, se uma conclui PBIs dimensionados em 3, 5, 8, 5 e 3 pontos, sua observada naquela é de 24 pontos. Se outro item de 8 pontos foi iniciado, mas não atendeu à , ele não deve ser contado como concluída.
A é histórica. Ela descreve o que aconteceu. O valor pode, então, ser utilizado como um indicador do desempenho passado ao formar previsões futuras.
Essa distinção é importante. A , em si, não é a . A é um julgamento voltado ao futuro, informado pela histórica juntamente com a capacidade futura, a compreensão do , a , dependências, incertezas e evidências atuais do produto.
Definição essencial
é uma indicação opcional de quanto trabalho dimensionado do uma equipe concluiu como Done durante uma . É evidência histórica, não uma nota de produtividade.
Entrega histórica: por que o passado é útil
O Scrum Guide afirma que, em ambientes complexos, apenas o que já aconteceu pode ser utilizado para decisões voltadas ao futuro. Essa é a base filosófica dos sinais históricos de planejamento.
A entrega passada não é uma evidência perfeita, mas geralmente é mais fundamentada do que a aspiração. Uma equipe que concluiu aproximadamente entre 25 e 35 pontos em Sprints recentes comparáveis possui evidência mais forte para sua próxima do que um gestor que simplesmente determina que a equipe deveria concluir 50.
A histórica também pode revelar instabilidade. Se uma apresenta 42 pontos, a seguinte 18, depois 37 e depois 21, essa ampla variação deve despertar curiosidade. As causas podem incluir disponibilidade, mudança no tipo de trabalho, divisão inadequada dos itens, dependências, incidentes, alterações na ou uma escala de estimativa instável.
O objetivo não é necessariamente eliminar toda variação. Trabalho complexo é variável. O objetivo é compreender a variação o suficiente para tomar decisões responsáveis.
Entrega histórica por
Pontos Done
Contexto
1
29
Capacidade normal
2
33
Capacidade normal
3
31
Capacidade normal
4
22
Dois indisponíveis; incidente em produção
5
34
Capacidade normal
O contexto é melhor do que a média cega
A 4 não deve redefinir automaticamente a expectativa futura da equipe. Números históricos são interpretados em contexto, e não calculados mecanicamente por média.
e
A é mais defensável quando usada como um insumo local de planejamento. A .org descreve de forma consistente seu papel útil como auxílio às equipes na de quanto trabalho poderá ser concluído em Sprints futuras ou de como uma trajetória de release pode evoluir.
Suponha que uma equipe tenha concluído entre 30 e 35 pontos na maioria das Sprints recentes comparáveis. Se restarem 100 pontos de trabalho com nível de entendimento semelhante, uma aproximada pode sugerir algo em torno de três a quatro Sprints. Isso não é uma garantia. O pode mudar, as estimativas podem evoluir, a capacidade pode ser diferente e novos aprendizados podem remover ou adicionar trabalho.
Uma profissional, portanto, comunica premissas e intervalos em vez de transformar uma média em promessa. "Com base nas últimas seis Sprints comparáveis, atualmente esperamos de três a quatro Sprints" é mais honesto do que "A release será concluída em exatamente 3,2 Sprints".
A também pode ser um dos insumos da . O Scrum Guide afirma especificamente que a confiança aumenta quando os compreendem o desempenho passado, a capacidade futura e a .
Entretanto, equipes utilizam cada vez mais alternativas como ,, previsões probabilísticas ou simulação de Monte Carlo. O não privilegia a em relação a esses métodos. O que importa é se a técnica melhora a tomada de decisão empírica.
Regra de
Use a para informar uma , e não para transformar uma média histórica em compromisso.
Por que a varia naturalmente entre Sprints
Uma expectativa gerencial comum é que uma equipe madura deva produzir a mesma ou uma maior a cada . Essa suposição interpreta incorretamente o trabalho complexo.
A de uma para outra pode variar porque o próprio trabalho do produto varia. Uma pode conter mudanças familiares; outra pode envolver uma integração difícil ou alto grau de incerteza. A pode evoluir. Um incidente em produção pode consumir atenção. Férias ou treinamentos podem reduzir a disponibilidade. Uma dependência crítica pode atrasar o progresso.
Mesmo quando a equipe é altamente eficaz, é improvável que a seja exatamente consistente. Uma equipe pode melhorar significativamente em qualidade, colaboração, frequência de deployment, resultados para clientes ou redução de riscos enquanto seu total de pontos permanece estável.
Da mesma forma, uma crescente não comprova melhoria. A equipe pode simplesmente estar atribuindo valores maiores em pontos para trabalhos equivalentes.
Diferentes padrões de complexidade, incerteza, risco ou dependência.
Critérios de qualidade mais fortes podem aumentar o trabalho real necessário para concluir.
Aprendizado sobre o produto
O escopo pode diminuir, aumentar ou ser reordenado à medida que as evidências mudam.
Ambiente técnico
Incidentes, ferramentas instáveis, atrasos de fornecedores ou infraestrutura.
Comportamento de estimativa
Itens de referência ou calibração de podem se deslocar ao longo do tempo.
Por que comparar entre equipes é problemático
A só é significativa dentro do sistema local de estimativa que a produziu. não são unidades padronizadas.
A Equipe A pode chamar uma capacidade ponta a ponta familiar de 5 pontos, enquanto a Equipe B pode chamar um item de tamanho semelhante de 8 pontos porque suas histórias de referência, habilidades, , arquitetura, automação e calibração histórica são diferentes.
Portanto, a Equipe A concluir 40 pontos e a Equipe B concluir 28 não estabelece que a Equipe A seja mais rápida, mais produtiva ou mais valiosa.
Isso é semelhante a comparar temperaturas medidas em duas escalas arbitrárias sem conhecer a conversão. Os números possuem significado interno, mas não compartilham uma unidade externa comum.
A comparação entre equipes torna-se especialmente prejudicial quando recompensas, promoções, financiamento ou atenção da gestão dependem do resultado. As equipes podem melhorar imediatamente sua classificação aumentando as estimativas, em vez de melhorar a entrega do produto.
Nunca deduza desempenho a partir da entre equipes
Uma equipe de 40 pontos não é inerentemente mais rápida ou melhor do que uma equipe de 25 pontos. As escalas de pontos são locais e incomparáveis.
: por que métricas se deterioram quando viram metas
A é uma das ideias mais úteis para compreender a gestão disfuncional da . A observação original de Charles Goodhart, de 1975, tratava de política monetária: quando uma regularidade estatística antes útil se torna objeto de controle, as pessoas se adaptam e a relação pode deixar de funcionar.
A formulação moderna popular costuma ser expressa assim: quando uma medida se torna uma meta, deixa de ser uma boa medida.
Aplicada à , a mecânica é direta. Quando a é apenas observada, a equipe tem pouco incentivo para manipulá-la. O número pode permanecer como um registro aproximado de quanto trabalho dimensionado alcançou Done.
Quando a liderança declara uma meta como "aumentar a em 20%", o comportamento muda. As estimativas aumentam. Itens menores podem ser divididos de outra maneira para gerar mais trabalho pontuável. Trabalho de qualidade pode ser ignorado. Equipes podem evitar ajudar outras porque o suporte entre equipes reduz seu próprio número. A ordenação do pode migrar para produção de alto volume de pontos, em vez de resultados de alto valor.
A métrica não ficou apenas imprecisa. A meta mudou o sistema que estava sendo medido.
Efeitos do uso da
Uso
Exemplo
Efeito provável
observada
Equipe percebe 30-35 pontos/
Pode ajudar a prever trabalho futuro local.
como meta
Gestão exige 40 pontos/
A equipe ganha incentivo para alterar estimativas ou seleção de trabalho.
recompensada
Bônus vinculado a >45 pontos/
Manipular a métrica torna-se economicamente racional.
em ranking
Equipes comparadas publicamente
Escalas locais inflam e a colaboração pode diminuir.
Goodhart aplicado ao
Se as pessoas forem recompensadas por tornar a maior, tornar o número maior passa a ser o objetivo racional - mesmo quando valor para o cliente, qualidade e previsibilidade não melhoram.
Por que "aumentar a " é uma meta ruim
é um sinal de planejamento relacionado a output. Metas de produto deveriam concentrar-se em valor, outcomes, qualidade, risco ou capacidade - e não em aumentar uma métrica de planejamento.
Uma meta não cria uma definição estável de "melhor". Se a equipe passa de 30 para 40 pontos porque dobrou todas as estimativas, o número melhorou enquanto nada mais mudou. Se passa de 30 para 24 porque a automação permite dividir o trabalho de maneira diferente, o número pode cair mesmo que a entrega se torne mais rápida.
A meta também pode incentivar erosão da qualidade. Quando a é vista como obstáculo para atingir uma meta de pontos, as pessoas podem adiar testes, documentação, segurança, ou integração. A aparente aumenta porque trabalho de qualidade inacabado está sendo escondido em outro lugar.
Uma meta de melhoria mais adequada pergunta qual é o problema real. Se os stakeholders precisam de maior previsibilidade, melhore a confiabilidade das previsões. Se clientes precisam de entrega mais rápida, examine e frequência de release. Se o valor está fraco, inspecione outcomes e progresso em direção ao . Se a qualidade é baixa, fortaleça a e as práticas de engenharia.
não é produtividade
Produtividade tenta relacionar output útil aos recursos consumidos. A não faz isso. Ela soma estimativas locais de trabalho concluído.
Uma equipe pode aumentar o valor para o cliente ao concluir menos pontos. Por exemplo, uma pequena mudança de configuração pode remover uma grande barreira de conversão. Em outra , a equipe pode concluir muitos recursos internos de alta pontuação que os clientes nunca utilizam.
A também não considera a qualidade do outcome. Um recurso que aumenta receita, reduz fraude, melhora segurança ou elimina custo operacional pode ter menos do que um recurso grande e de baixo valor.
Usar como produtividade, portanto, confunde tamanho estimado do trabalho com benefício. O atribui ao a accountability pela maximização de valor e exige que a crie Increments valiosos e úteis - não que maximize a produção de pontos.
não é uma medida de melhoria da equipe
Uma equipe pode melhorar sem aumentar a . Uma engenharia melhor pode reduzir defeitos, encurtar , melhorar manutenibilidade, fortalecer segurança, permitir releases mais frequentes ou reduzir incidentes operacionais enquanto os totais de pontos permanecem estáveis.
Na verdade, melhorar a divisão dos itens e reduzir seu tamanho pode fazer os números de mudarem de forma imprevisível mesmo quando o fluxo real melhora.
Por isso, Retrospectives não deveriam perguntar automaticamente "Como aumentamos a ?". Devem inspecionar eficácia e qualidade. A pode ser uma parte da evidência, mas nunca deve definir sozinha o que significa melhorar.
e a
A só é útil quando o trabalho concluído possui um significado confiável. É por isso que a importa.
Se as equipes contam pontos quando a codificação termina, mas antes da integração ou dos testes, a histórica superestima o progresso real do produto. Uma fase posterior de hardening acaba absorvendo o trabalho oculto.
Se a se torna mais forte, a pode diminuir temporariamente porque a equipe agora contabiliza o trabalho concluído de maneira mais honesta. Isso pode ser um sinal de maior transparência, e não de queda de desempenho.
Somente Items que atendem à devem contribuir para uma baseada em Done utilizada em previsões.
e capacidade
A reflete trabalho concluído no passado sob condições passadas. Capacidade descreve o que será diferente na próxima .
Uma equipe que normalmente conclui 30 pontos não deve prever mecanicamente 30 quando vários estarão indisponíveis, uma grande migração de produção estiver planejada ou houver restrição de capacidade de especialistas.
Da mesma forma, aumentar o tamanho da equipe não produz imediatamente um aumento proporcional de . Pessoas novas precisam de onboarding, os padrões de comunicação mudam e o trabalho pode não ser divisível linearmente.
A histórica, portanto, é apenas um insumo. Capacidade e contexto ajustam o nível de confiança que a equipe deve depositar nesse histórico.
como intervalo, não como média mágica
As equipes costumam calcular a média das últimas três Sprints e chamar o resultado de "a ". Médias podem ser convenientes, mas podem ocultar variabilidade.
Considere Velocities de iguais a 20, 40, 22, 38, 21 e 39. A média é 30, mas a equipe raramente conclui algo próximo de 30. Uma baseada apenas na média pode ser enganosa.
Um intervalo ou uma distribuição pode comunicar melhor a incerteza: "Sprints recentes comparáveis concluíram entre 20 e 40, com dois padrões distintos de trabalho". A pergunta seguinte é por que o sistema se comporta dessa maneira.
Essa é uma das razões pelas quais previsões probabilísticas baseadas em fluxo podem superar médias de pontos em alguns contextos. O permite essas técnicas complementares.
Quando a pode ser útil
Usos úteis da
Uso útil
Por quê
Insumo da
Trabalho Done passado pode informar o que os consideram realista, ajustado à capacidade e ao trabalho atual.
A conclusão histórica local pode ajudar a estimar um intervalo de Sprints para trabalho restante dimensionado de forma semelhante.
Conversa de transparência
Variação inesperada pode motivar investigação de dependências, qualidade, divisão de itens ou capacidade.
Continuidade do planejamento local
Uma equipe estável pode desenvolver uma referência histórica compartilhada para trabalho estruturado de modo semelhante.
Usos inadequados da
Uso inadequado
Por quê
Ranking de desempenho
não é padronizada entre equipes.
KPI de produtividade
Ela mede trabalho estimado local, não valor nem eficiência.
Meta para bônus
Cria incentivos fortes para manipular estimativas e escopo.
Proxy de qualidade
Pontuações maiores não dizem nada confiável sobre qualidade.
Métrica de valor para o cliente
Pontos descrevem tamanho do trabalho, não outcomes.
Exemplo prático - uma meta de que melhora o número e piora o produto
Imagine uma responsável por uma plataforma de APIs bancárias digitais. Ao longo de seis Sprints, a equipe normalmente concluiu entre 28 e 34 de trabalho Done. O usa esse histórico, junto com a capacidade futura e o conhecimento do , para comunicar uma .
Um gestor sênior vê o dashboard e decide que uma equipe experiente deve melhorar continuamente. É introduzida uma meta: a deve aumentar 15% a cada trimestre. Espera-se que a equipe alcance 38 pontos por .
No início, nada muda tecnicamente. O mesmo trabalho continua sendo necessário. Mas a métrica virou meta.
Durante o refinement, um item que a equipe anteriormente chamaria de 5 pontos passa a ser discutido como 8. A justificativa é fácil de defender porque são subjetivos e relativos. Várias outras estimativas também sobem. Na seguinte, a reportada chega a 39.
A gestão celebra a melhoria, mas os clientes não receberam mais valor. O não mudou. A frequência de release não mudou. O número aumentou porque a escala local mudou.
A meta então cria uma segunda pressão. Uma grande migração de segurança provavelmente reduzirá a quantidade de itens concluídos, por isso os se sentem tentados a adiar alguns testes não funcionais para a próxima . O questiona essa decisão porque a qualidade não deve diminuir e a não pode ser tratada como opcional.
O também percebe que PBIs pequenos e de alto valor fazem a equipe parecer menos produtiva do que PBIs grandes e carregados de pontos. Se a meta dominar a atenção, a ordenação do pode se distorcer em direção à produção de pontos, e não à geração de valor.
Na Retrospective, a torna a disfunção transparente. Mostra que as estimativas em pontos aumentaram enquanto outcomes para clientes, e de release não melhoraram. A meta de é removida.
A equipe devolve a ao seu papel original: um sinal privado e local de planejamento. Usa intervalos recentes para informar previsões de , ajusta pela capacidade e complementa a métrica com e outcomes do produto.
No trimestre seguinte, a permanece aproximadamente entre 29 e 33. Ainda assim, a frequência de deployment melhora, incidentes de segurança diminuem e um é alcançado mais cedo porque o remove escopo de baixo valor após feedback da .
A equipe tornou-se mais eficaz sem "aumentar a ". É exatamente por isso que a nunca deve ser confundida com sucesso.
Métricas alternativas e complementares
As equipes não precisam de para fazer previsões. pode contar itens Done ao longo do tempo quando o trabalho possui tamanho razoavelmente uniforme. mostra quanto tempo o trabalho leva do início à conclusão. Work-item aging expõe o risco atual do fluxo. Métodos de Monte Carlo podem construir previsões probabilísticas a partir de dados históricos de fluxo.
Métricas de produto respondem a outra pergunta: se o trabalho cria valor. Outcomes de clientes, confiabilidade, conversão, redução de risco, custo, adoção, qualidade e progresso em direção ao podem revelar se a equipe está resolvendo o problema certo.
Nenhuma métrica isolada é suficiente. Um sistema saudável de medição utiliza diversos sinais e mantém cada um vinculado à decisão que ele pretende melhorar.
Anti-patterns comuns de
Anti-patterns comuns de
Anti-pattern
Por que é prejudicial
Meta de
Cria incentivos para inflar estimativas ou otimizar a métrica em vez dos outcomes.
Ranking entre equipes
Compara escalas locais incompatíveis de .
individual
Destrói a natureza de equipe do trabalho colaborativo de produto.
Crédito parcial de pontos
Conta trabalho inacabado e enfraquece a evidência histórica.
= produtividade
Confunde tamanho estimado com output útil por recurso.
= valor
Confunde quantidade de trabalho estimado com benefício para clientes ou stakeholders.
Expectativa de tendência sempre crescente
Trata a variação normal do trabalho complexo como falha.
Média tratada como promessa
Transforma evidência histórica em falsa certeza.
Qualidade sacrificada por pontos
Torna a métrica mais importante do que a .
Reestimativa para proteger a tendência
Altera a escala histórica para fazer o desempenho parecer consistente.
Falso. A variação é normal e um número maior não é inerentemente melhor.
mede o desempenho da equipe.
Falso. No máximo, é um sinal local e opcional de planejamento/.
mede valor para o cliente.
Falso. representam tamanho local, não valor.
Equipes com maior são mais produtivas.
Falso. Equipes diferentes usam escalas locais diferentes.
O define uma meta de .
Não é uma accountability do e, em geral, é uma gestão de métricas prejudicial.
determina o compromisso da .
Falso. Os PBIs selecionados são uma ; o é o compromisso do .
Todos os pontos iniciados contam para .
Falso para baseada em Done; PBIs inacabados não contribuem para o .
Uma menor sempre indica problema.
Falso. Capacidade, mix de trabalho, mudanças na ou melhorias deliberadas de qualidade podem explicar a queda.
pode substituir .
Falso. Técnicas de nunca substituem transparência, inspeção e adaptação.
O é responsável por melhorar a .
Falso. O é accountable pela eficácia da , não pelo crescimento de pontos.
é o único método válido de .
Falso. O permite várias técnicas complementares de .
Um framework de raciocínio para questões da sobre
Prática opcional: a resposta preserva o fato de que não é exigida pelo ?
Histórico: a é tratada como evidência sobre trabalho passado concluído, e não como promessa futura?
Done: somente trabalho que atende à contribui para um histórico significativo de conclusão?
: a histórica é apenas um insumo ao lado de capacidade, trabalho atual e incerteza?
Variação: a resposta permite mudanças entre Sprints sem presumir falha?
Escala local: evita comparar em entre equipes?
Goodhart: evita transformar em meta, KPI, gatilho de bônus ou mecanismo de ranking?
Valor: o sucesso do produto é medido por outcomes, e não por totais de pontos?
Qualidade: a resposta se recusa a sacrificar a para proteger uma métrica?
: a métrica permanece subordinada à transparência, inspeção e adaptação?
Heurística rápida para a prova
A pode ajudar uma equipe a prever com base em seu próprio histórico de trabalho Done. Ela não é uma exigência do , uma métrica de produtividade, uma medida de sucesso nem uma ferramenta de comparação entre equipes.
Conclusão: a é mais saudável quando ninguém quer que ela fique maior
A pode ser um sinal útil de planejamento porque transforma trabalho histórico concluído em evidência. Uma equipe estável pode observar o que normalmente conclui e usar esse intervalo, juntamente com a capacidade futura e o conhecimento atual do , para formar previsões mais fundamentadas.
Sua utilidade depende de manter a interpretação restrita. não mede valor para o cliente, produtividade, qualidade nem sucesso da equipe. Ela apenas reflete uma quantidade local de trabalho dimensionado que alcançou Done sob condições passadas.
A variação de uma para outra, portanto, é normal. Trabalho complexo muda. A capacidade muda. Definitions of Done evoluem. Dependências surgem. Aprendizado sobre o produto remove e adiciona escopo. Uma equipe saudável deve explicar a variação, e não tratar toda queda como um problema de desempenho.
A comparação entre equipes é especialmente inválida porque as escalas de são locais. Uma equipe de 40 pontos não pode ser classificada de forma significativa acima de uma equipe de 25 pontos sem uma unidade padronizada comum - e os , por definição prática, não fornecem essa unidade.
A explica o perigo mais profundo. Quando a se transforma em meta, a estrutura de incentivos muda. As equipes podem satisfazer a meta alterando estimativas, divisão dos itens, seleção de trabalho ou comportamento em relação à qualidade. A métrica sobe enquanto o sistema que deveria descrever se torna menos transparente.
A resposta correta não é necessariamente banir a . É dar à métrica um trabalho estreito. Use-a se ela melhorar a local. Pare de usá-la quando começar a orientar comportamentos, distorcer decisões de valor ou criar pressão para fabricar uma tendência.
O não exige e deliberadamente deixa abertas as técnicas de .,, previsões probabilísticas e métricas de outcome do produto podem oferecer evidências melhores dependendo do contexto.
Na minha visão, o melhor sinal de que a está sendo usada corretamente é quando a organização não celebra o número em si. As pessoas se importam com a utilidade das previsões, com a criação de Increments Done e valiosos, com o progresso dos Product Goals e com o atendimento melhor aos clientes. A pode apoiar discretamente essas conversas. No momento em que vira manchete, geralmente deixa de ajudar.
Principais pontos
é uma medida histórica e local de quanto trabalho dimensionado alcançou Done durante uma .
é comumente expressa usando concluídos, mas o não prescreve essa unidade.
A entrega histórica pode informar previsões futuras de e release.
é evidência sobre o passado, não garantia sobre o futuro.
As previsões devem considerar capacidade futura, , compreensão do e incerteza.
A variação de entre Sprints é normal em trabalho complexo.
Uma maior não significa automaticamente melhor desempenho ou mais valor.
Uma menor não indica automaticamente um problema.
em não pode ser comparada de forma significativa entre equipes porque as escalas são calibradas localmente.
A explica por que uma métrica se deteriora quando pessoas são recompensadas ou controladas pela meta.
Metas de podem incentivar inflação de estimativas, redução de qualidade, divisão distorcida de trabalho e otimização de output.
não deve ser usada como métrica de produtividade individual.
Somente trabalho Done deve contribuir para uma baseada em conclusão utilizada em previsões.
Uma mais forte pode reduzir a aparente enquanto melhora a transparência e a qualidade do produto.
pode ser complementada ou substituída por ,, previsões probabilísticas e métricas de outcome.
não aparece como elemento obrigatório no Scrum Guide atual.
Use como possível ferramenta de planejamento, nunca como definição de sucesso.
