Como Scrum Teams planejam em ambientes complexos usando previsões, evidências históricas, capacidade, planejamento progressivo, aprendizagem contínua e decisões de release - sem transformar incerteza em falsas promessas
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 a diferença entre uma e um compromisso absoluto; explicar por que o planejamento em ambientes complexos precisa permanecer adaptativo; usar adequadamente o desempenho histórico e a capacidade futura; compreender planejamento progressivo e de releases; relacionar mudanças de planejamento à aprendizagem; e raciocinar sobre por que a apoia - mas jamais substitui - o .
Introdução: planejar é necessário - certeza é opcional
não rejeita o planejamento. Ele rejeita a crença de que um plano detalhado possa eliminar a incerteza do trabalho complexo.
As organizações precisam de planos. Clientes perguntam quando algo poderá estar disponível. Líderes precisam de expectativas sobre investimentos. Product Owners precisam decidir o que perseguir em seguida. precisam de direção suficiente para coordenar o trabalho. Uma equipe que se recusa a fazer qualquer porque “ é ” cria incerteza evitável para todos ao seu redor.
O fracasso oposto é igualmente prejudicial: tratar toda estimativa ou como uma promessa contratual. No desenvolvimento de produtos complexos, informações importantes permanecem desconhecidas até que o trabalho comece. Descobertas técnicas surgem. O comportamento do cliente difere das hipóteses. Dependências mudam. A se altera. Regulamentações e condições de mercado evoluem. Um plano preciso pode, portanto, tornar-se menos exato com o tempo, mesmo que tenha sido elaborado com responsabilidade.
lida com essa tensão por meio do e do . A equipe planeja com base no que é conhecido no momento, cria Increments utilizáveis, inspeciona evidências e atualiza o plano quando a realidade muda. A é útil justamente porque se espera que ela mude.
O Scrum Guide atual usa a linguagem de forecast ao discutir quanto trabalho os acreditam conseguir concluir dentro de uma . A confiança pode aumentar quando eles conhecem melhor o desempenho passado, a capacidade futura e a . Esses insumos reduzem a incerteza evitável, mas não eliminam a complexidade.
As orientações atuais da .org sobre tornam explícito o princípio mais amplo: uma não é uma promessa nem uma garantia. Ela deve ser atualizada à medida que mais informações se tornam transparentes. O planejamento de releases pode ser útil, mas deve permanecer subordinado ao .
Este capítulo explora o planejamento como um sistema de aprendizagem. Examinaremos a , evidências históricas, capacidade, planejamento progressivo, releases, incerteza e a diferença entre adaptar uma e quebrar um compromisso. A ideia central é simples: o planejamento profissional deve aumentar a clareza sem fingir que é possível prever aquilo que ainda não pode ser conhecido.
versus compromisso absoluto
Uma é uma estimativa informada sobre um resultado futuro com base nas evidências atualmente disponíveis. Um compromisso absoluto é uma promessa de que um resultado específico ocorrerá independentemente do que vier a ser aprendido.
Esses conceitos se comportam de forma muito diferente no trabalho complexo. Uma pode ser atualizada quando as evidências mudam. Um compromisso absoluto de escopo trata a mudança como falha, mesmo quando as hipóteses originais deixam de ser válidas.
Em , os Items selecionados para uma representam uma daquilo que os acreditam conseguir concluir. O é o compromisso associado ao . Essa distinção protege, ao mesmo tempo, a responsabilidade e a adaptabilidade.
Os devem levar sua a sério. “” não significa algo casual, opcional ou sem importância. Eles usam julgamento profissional, desempenho histórico, capacidade futura, entendimento do e a para produzir a melhor estimativa responsável possível.
Quando a realidade muda, porém, a não preserva a à custa do ou da qualidade do produto. O escopo pode ser esclarecido e renegociado com o à medida que mais informações são descobertas.
Âncora para a
PBIs selecionados são uma . O é o compromisso. A deve ser responsável e baseada em evidências, mas não é uma garantia absoluta.
Por que a complexidade torna impossível uma perfeita
foi concebido para problemas complexos, nos quais a relação entre causa e efeito nem sempre pode ser conhecida antecipadamente. Parte do conhecimento importante só emerge ao realizar o trabalho e inspecionar o resultado.
A complexidade pode decorrer de tecnologia, comportamento do cliente, dependências organizacionais, alterações regulatórias, mercados em mudança, sistemas distribuídos, restrições de integração desconhecidas ou da interação entre muitos fatores.
Uma equipe pode reduzir a incerteza por meio de pesquisa, refinement, experimentos, protótipos, evidências históricas e descoberta técnica. Ainda assim, alguma incerteza permanece irredutível até que o produto interaja com a realidade.
Por isso, uma expressa como intervalo ou nível de confiança pode, em alguns casos, ser mais honesta do que uma única data determinística. não prescreve probabilística, simulação de Monte Carlo, burn-ups, burn-downs ou análise de , mas as equipes podem usar essas técnicas quando elas aumentam a transparência.
A regra principal é que ferramentas de não substituem o . Nenhum gráfico é mais confiável do que as evidências produzidas pelo trabalho realmente concluído.
Planejamento em ambientes complexos
O planejamento em um ambiente complexo deve responder às próximas perguntas importantes sem fingir que consegue responder a todas as perguntas futuras.
No nível do produto, o fornece direção de longo prazo enquanto o permanece emergente. No nível da , o cria foco de curto prazo enquanto o se adapta durante a . Previsões de release podem criar alinhamento mais amplo, permanecendo ajustáveis à medida que as evidências do produto mudam.
Isso produz horizontes de planejamento em camadas. O trabalho de curto prazo pode ser mais detalhado porque tem maior probabilidade de acontecer e há mais informações disponíveis. O trabalho distante deve, em geral, permanecer menos preciso porque hipóteses detalhadas se deterioram com o tempo.
O resultado é o planejamento progressivo: detalhe suficiente para tomar as próximas decisões e, depois, mais detalhe quando o futuro estiver mais próximo e transparente.
Camada de planejamento
Horizonte principal
Comportamento adaptativo
Direção de longo prazo
Estável o suficiente para criar foco; pode ser cumprido ou abandonado com base em evidências.
Opções futuras emergentes
Ordenado e refinado à medida que a aprendizagem altera valor e entendimento.
Trajetória possível de entrega
Atualizada quando , escopo, evidências ou objetivos mudam.
Objetivo da atual
Compromisso que dá coerência à .
Plano acionável atual
Atualizado continuamente pelos à medida que mais é aprendido.
Evidências históricas: a melhor começa com o que realmente aconteceu
O Scrum Guide afirma que, quanto mais os souberem sobre seu desempenho passado, a capacidade futura e a , maior poderá ser a confiança em suas previsões para a .
O desempenho passado é valioso porque substitui otimismo por evidência. Uma equipe pode sentir que consegue concluir doze itens, mas, se seu histórico recente mostrar uma faixa estável de seis a nove itens de tamanho semelhante, esse histórico deve influenciar a .
Evidências históricas podem assumir formas diferentes. As equipes podem examinar ,, PBIs concluídos, resultados históricos de Sprints, envelhecimento do trabalho, defeitos que escaparam ou outras informações relevantes ao contexto.
História não é destino. Uma grande mudança de arquitetura, nova composição da equipe, dependência incomum ou alteração da pode tornar o desempenho antigo menos representativo. Evidências precisam ser interpretadas, não aplicadas mecanicamente.
O uso mais forte do histórico é, portanto, condicional: “Dado o que esta equipe concluiu em condições semelhantes e considerando o que sabemos sobre a próxima , qual é uma razoável?”
Capacidade: o que será diferente na próxima ?
O desempenho histórico descreve o passado; a capacidade ajuda a ajustar essa evidência para o futuro imediato.
Capacidade inclui disponibilidade e competência dos para a próxima . Férias, feriados, treinamentos, incidentes, suporte à produção, onboarding, disponibilidade de especialistas, obrigações organizacionais ou trabalho operacional incomum podem afetar o que a equipe consegue prever de forma razoável.
Capacidade não deve ser reduzida à contagem de horas individuais e ao preenchimento de todos a 100% de utilização. Trabalho complexo exige colaboração, solução de problemas, revisão, comunicação e aprendizagem inesperada. Um plano perfeitamente saturado geralmente não deixa espaço para adaptação.
Capacidade também inclui competência. Uma equipe de oito pessoas pode ter menor capacidade efetiva em uma com forte componente de segurança se apenas uma pessoa conhecer um sistema crítico de segurança. e compartilhamento de conhecimento podem, portanto, melhorar previsões futuras ao reduzir gargalos de especialização.
O objetivo de considerar capacidade não é otimizar recursos. É produzir uma de mais crível e maior transparência sobre riscos.
e confiança na
A é um importante insumo de porque define o custo real da conclusão.
Uma equipe que prevê apenas o esforço de codificação, ignorando testes, integração, segurança, acessibilidade, documentação, prontidão para implantação ou outras medidas de qualidade exigidas, irá superestimar sistematicamente sua capacidade de entrega.
À medida que a se torna mais clara e a aumenta sua capacidade de cumpri-la, a qualidade das previsões tende a melhorar porque o trabalho oculto de finalização diminui.
Uma mais forte pode, inicialmente, reduzir a quantidade aparente de escopo concluído por . Isso não significa que o planejamento piorou. Pode significar que a finalmente passou a refletir conclusão real de produto, em vez de trabalho parcial.
Planejamento progressivo: o detalhe deve aumentar à medida que as decisões se aproximam
Planejamento progressivo é a prática de aumentar o nível de detalhe conforme o trabalho se torna mais provável e imediato. dá suporte natural a isso por meio da emergência do , refinement, e adaptação contínua do .
Items distantes podem permanecer amplos. Itens de curto prazo são refinados em trabalhos menores e mais precisos. A cria um plano acionável para os itens selecionados. Depois, os continuam atualizando esse plano à medida que descobrem o que a implementação realmente exige.
Isso evita dois extremos: nenhum planejamento até o último momento e exaustivo de trabalho que talvez nunca aconteça.
O princípio econômico é importante. Detalhe tem custo. Se a probabilidade de o trabalho distante mudar for alta, planejamento pesado cria um estoque de hipóteses que pode se tornar obsoleto.
O planejamento progressivo trata, portanto, o esforço de planejamento como investimento. Gaste detalhe onde ele melhora uma decisão próxima; preserve flexibilidade onde a incerteza permanece alta.
Princípio do
Quanto mais próxima a decisão, mais útil se torna o detalhe. Quanto mais distante o futuro, mais valiosa se torna a flexibilidade.
O é um plano vivo
O torna o visível dentro da . Ele é um plano criado por e para os e é atualizado ao longo da conforme mais é aprendido.
Os inspecionam diariamente o progresso em direção ao e adaptam o quando necessário. Isso significa que o plano criado durante a , intencionalmente, não é final.
Novas descobertas técnicas podem alterar a abordagem de implementação. O trabalho pode ser decomposto de outra forma. Tarefas podem surgir ou desaparecer. Um pode revelar-se maior ou menor do que o esperado.
não significa que o mude casualmente. O objetivo fornece estabilidade enquanto o plano exato permanece flexível. Se o escopo precisar de ajuste, os colaboram com o preservando o .
A aprendizagem deve mudar a
Uma que nunca muda apesar de novas evidências não é necessariamente disciplinada. Ela pode estar ignorando a realidade.
Suponha que uma preveja uma release em oito Sprints. Após três Sprints, o cai porque uma nova exigência de compliance torna a mais rigorosa. Uma profissional deve mudar. Manter a data original sem reconhecer a nova informação criaria falsa transparência.
O mesmo vale quando as evidências melhoram. Automação pode aumentar o fluxo. Uma dependência arriscada pode desaparecer. Aprendizado de produto pode remover escopo de baixo valor. A pode se antecipar porque o problema de produto ficou menor ou porque a equipe se tornou mais eficaz.
Atualizar uma não é o mesmo que mover compromissos continuamente para evitar responsabilidade. A deve tornar as mudanças transparentes, explicar as evidências que as justificam e preservar a responsabilidade por objetivos e qualidade.
Planejamento de releases em
não define como evento formal, artefato ou prática obrigatória. Ainda assim, organizações de produto frequentemente precisam prever releases, coordenar marketing, administrar contratos, programar migrações, comunicar-se com clientes ou preparar operações.
Teams podem, portanto, usar como prática complementar. A .org descreve como um guia para entregar um produto por meio de releases pequenas, incrementais e frequentes, em vez de depender apenas de grandes lançamentos “big bang”.
Uma pode responder a perguntas como: quando determinado provavelmente será alcançado? Qual intervalo de datas é plausível para uma capacidade? Que trabalho provavelmente estará incluído se as tendências atuais continuarem?
A regra crucial é que previsões de release continuam sendo previsões. Elas devem ser atualizadas à medida que mais informações se tornam transparentes. Uma não é uma promessa e não substitui o .
O decide quando as releases ocorrem no contexto do produto, enquanto permite que Done Increments sejam entregues a qualquer momento de uma . A nunca é um gate obrigatório de release.
Nuance sobre
pode ser útil em , mas não é um evento formal do e uma não é uma garantia.
Releases frequentes melhoram a ao melhorar a aprendizagem
Releases pequenas e frequentes podem melhorar mais do que o time-to-market. Elas aumentam a quantidade de evidência real disponível para o planejamento futuro.
Uma equipe que faz release a cada poucos meses precisa prever longos períodos sem saber como os clientes responderão. Uma equipe que entrega pequenos Done Increments com frequência pode observar uso, defeitos, desempenho, adoção, conversão ou impacto operacional e adaptar-se mais cedo.
Isso não significa que todo produto deva ser implantado continuamente. Segurança, regulamentação, distribuição física, coordenação com clientes ou estratégia de mercado podem criar restrições legítimas de release.
O princípio é encurtar o tanto quanto o contexto do produto permitir de forma responsável. Evidências mais frequentes tornam as previsões de produto e de release menos dependentes de hipóteses.
Técnicas de : ferramentas úteis, não requisitos do
não prescreve uma única técnica de . Equipes diferentes podem usar evidências e modelos diferentes.
Técnica opcional
O que ela pode ajudar a prever
histórico
Usa o número de PBIs concluídos ao longo do tempo para inferir uma faixa futura provável.
Usa o tempo decorrido entre início e conclusão do trabalho para raciocinar sobre fluxo e probabilidade de entrega.
Burn-up / burn-down
Visualiza trabalho concluído ou restante em relação a escopo ou meta em mudança.
Cumulative flow
Mostra estados do trabalho e pode revelar desequilíbrio de fluxo ou filas crescentes.
Pode apoiar previsões locais quando usada com cuidado; não é métrica de valor nem pontuação para comparar equipes.
Simulação de Monte Carlo
Usa dados históricos de fluxo para produzir previsões probabilísticas de data ou escopo.
Nenhuma dessas técnicas é exigida para a . A lógica da prova deve permanecer ancorada em : use evidências, torne a incerteza transparente, inspecione resultados reais e adapte. Uma sofisticada construída sobre dados ruins continua sendo ruim.
Métricas também devem ser aplicadas a unidades significativas de trabalho de produto, em vez de manipuladas como metas de desempenho. Quando uma métrica de vira pontuação de produtividade, o comportamento costuma mudar de maneiras que reduzem a transparência.
Comunicando a incerteza profissionalmente
não significa responder a toda pergunta de stakeholder com “não sabemos”. profissional comunica o que é conhecido, o que é incerto e quais evidências podem alterar a estimativa.
Em vez de dizer “Será entregue em 15 de outubro”, uma equipe pode dizer: “Com base nas últimas doze Sprints e nas hipóteses atuais do , há forte probabilidade de conclusão entre meados de outubro e o início de novembro. A maior incerteza é a integração externa de compliance, sobre a qual esperamos aprender mais na próxima .”
O estilo exato de comunicação depende da organização, mas o princípio permanece: a incerteza deve ser transparente, e não escondida atrás de falsa precisão.
Stakeholders geralmente preferem um intervalo honesto acompanhado de hipóteses a uma data precisa que se move repetidamente sem explicação. Transparência constrói confiança quando as mudanças da estão conectadas a evidências observáveis.
Exemplo prático - adaptativa para uma release de migração de API
Imagine uma migrando uma API de pagamentos de alto volume de um gateway legado para uma nova plataforma em nuvem. O é mover o tráfego de pagamentos elegível para a nova plataforma, mantendo confiabilidade, segurança e controles regulatórios.
A liderança pergunta quando a migração será concluída. O e os analisam o e o histórico recente. Nas últimas oito Sprints, a equipe concluiu entre cinco e oito PBIs de migração por . Restam trinta e dois PBIs na atual do .
Uma ingênua poderia dividir trinta e dois por uma média de seis e prometer conclusão em aproximadamente cinco Sprints. A faz algo mais responsável.
Primeiro, os examinam a capacidade futura. Um especialista de segurança ficará indisponível durante parte da próxima , e um grande evento de produção deve aumentar a demanda de suporte. Eles reduzem a confiança no de curto prazo.
Segundo, eles inspecionam a incerteza. Dez dos PBIs restantes dependem de uma migração de certificados de parceiro que ainda não foi testada em escala. Esses itens são mais incertos do que o trabalho histórico.
Terceiro, eles examinam a . Um novo controle organizacional agora exige evidências adicionais de auditoria para cada API migrada. Isso aumenta o trabalho real de conclusão e torna o histórico um pouco otimista.
A comunica a como um intervalo, e não como promessa: se as evidências atuais se mantiverem, a migração provavelmente será concluída em aproximadamente seis a oito Sprints. As hipóteses são tornadas visíveis e a migração do parceiro é identificada como a maior fonte de incerteza.
Durante a seguinte, os criam um experimento em torno da integração do parceiro e descobrem que a automação de certificados funciona melhor do que o esperado. Vários PBIs podem ser simplificados. O remove trabalho redundante do .
A se antecipa. Isso não é manipulação; as evidências subjacentes mudaram.
Duas Sprints depois, uma nova exigência regulatória acrescenta trabalho de verificação. O cresce, a se torna mais rigorosa e a passa para mais tarde. Novamente, a explica as evidências em vez de fingir que a original continua válida.
Enquanto isso, a equipe faz release das APIs migradas incrementalmente assim que Done Increments estiverem seguros para entrega. Os clientes não precisam esperar o término de todo o programa de migração para receber valor e redução de risco.
Em cada , stakeholders inspecionam o progresso em direção ao e a mais recente. Eles podem escolher mudar o escopo, aumentar o investimento, aceitar uma data posterior ou alterar o com base nas evidências atuais.
Este exemplo sintetiza a adaptativa: o histórico informa a estimativa, a capacidade ajusta expectativas de curto prazo, a incerteza é explícita, a qualidade afeta o real, releases ocorrem de forma incremental e novas evidências atualizam continuamente o plano.
Anti-patterns comuns de e planejamento
Anti-pattern
Por que enfraquece o
tratada como contrato
As equipes escondem a incerteza e defendem hipóteses ultrapassadas em vez de se adaptar.
Nenhuma porque “ é ”
Stakeholders recebem incerteza evitável e o planejamento perde utilidade.
Planejamento para 100% de utilização
Deixa pouco espaço para colaboração, aprendizagem, incidentes e adaptação.
como KPI de produtividade
Estimula inflação de estimativas e prejudica a transparência.
Média histórica usada mecanicamente
Ignora mudanças de capacidade, mudanças de qualidade e novas incertezas.
Plano de release congelado por meses
Impede que o aprendizado do produto altere decisões de investimento.
Data sem hipóteses
Cria falsa precisão e faz mudanças de parecerem arbitrárias.
Dependência de release “big bang”
Atrasa feedback e aumenta risco quando releases menores de Done são possíveis.
Planejamento detalhado muito distante no futuro
Cria hipóteses caras para trabalho com grande probabilidade de mudar.
Mudar objetivos para proteger previsões
Sacrifica foco em valor apenas para alegar sucesso de cronograma.
Pegadinhas comuns da sobre
Pegadinha
Interpretação correta segundo
PBIs selecionados são um compromisso absoluto.
Falso. Eles são uma ; o é o compromisso do .
devem ignorar o desempenho histórico porque cada é única.
Falso. O desempenho passado é evidência útil para .
O determina quanto os podem concluir.
Falso. Os selecionam aquilo que acreditam conseguir concluir por meio de discussão com o .
Capacidade significa preencher toda hora disponível de cada Developer.
Falso. Capacidade informa a ; não prescreve maximização de utilização.
Uma nunca deve mudar após a .
Falso. O é adaptado à medida que mais é aprendido.
é um evento obrigatório do .
Falso. É uma prática complementar opcional.
é a data obrigatória de release.
Falso. Done Increments podem ser liberados antes da .
Burn-down charts são exigidos por .
Falso. Gráficos e técnicas de são opcionais.
é obrigatória para .
Falso. não prescreve métrica de estimativa ou .
Previsões mais precisas são sempre mais exatas.
Falso. Precisão sem evidência pode criar falsa confiança.
Mudar uma quando a evidência muda é falha.
Falso. Adaptação é esperada no planejamento empírico.
O se torna desnecessário quando existe uma estatística.
Falso. nunca substitui .
Um framework de raciocínio para questões de na
versus compromisso: os PBIs selecionados são tratados como enquanto o permanece como compromisso?
Evidência: a é informada pelo desempenho passado real, e não apenas por otimismo?
Capacidade: a resposta considera disponibilidade e competência futuras sem transformar pessoas em percentuais de utilização?
: a considera o trabalho real necessário para criar Done Increments?
Adaptação: o plano pode mudar quando novas evidências aparecem?
: a flexibilidade de escopo é usada para proteger o objetivo em vez de preservar cada item previsto?
Planejamento progressivo: mais detalhe é adicionado à medida que as decisões se aproximam?
: ele é tratado como opcional e empírico, e não como evento obrigatório do ?
Incerteza: a incerteza é tornada transparente, em vez de escondida por promessas precisas?
: as previsões apoiam decisões sem substituir inspeção e adaptação?
Atalho para a prova
Uma é a melhor estimativa atual baseada em evidências. Quando a realidade muda, atualize a - não corrompa o , a qualidade ou a transparência para proteger uma estimativa antiga.
Conclusão: um bom planejamento aprende mais rápido do que a realidade muda
e não são opostos. A oferece às pessoas uma visão responsável do que pode acontecer. A adaptação mantém essa visão conectada à realidade à medida que novas informações emergem.
Em , Items selecionados são uma , e não uma promessa absoluta. Os melhoram essa ao compreender desempenho histórico, capacidade futura, e . O fornece compromisso e coerência, enquanto escopo e planos de implementação permanecem adaptáveis.
A complexidade torna isso necessário. Descobertas técnicas, comportamento do cliente, dependências, condições de mercado, regulamentação, necessidades de qualidade e podem alterar o futuro. Um plano estático não se mantém confiável apenas porque as pessoas desejam certeza.
Evidências históricas fornecem um ponto de partida melhor do que intuição isolada. A capacidade torna esse histórico relevante para a próxima . A garante que a reflita verdadeira conclusão do produto em vez de trabalho parcial. O planejamento progressivo, então, adiciona detalhe apenas quando ele melhora uma decisão real.
A pode estender essa lógica para além de uma . não exige , burn-downs, velocity, simulação de Monte Carlo ou qualquer outra técnica de . As equipes podem usá-las quando forem úteis, mas toda deve permanecer subordinada ao .
Done Increments e releases frequentes melhoram as previsões porque geram mais evidências. Quanto mais vezes um produto interage com a realidade, menos as decisões de longo prazo dependem inteiramente de hipóteses.
Uma que muda não deve ser automaticamente considerada uma falha. A pergunta central é por que ela mudou. Se a equipe aprendeu algo real e tornou essa evidência transparente, a adaptação é sinal de que o planejamento está funcionando. Se as previsões se movem arbitrariamente porque o progresso é opaco, existe um problema de transparência.
Na minha visão, a profissional é um exercício de humildade disciplinada. Ela diz: isto é o que acreditamos no momento; estas são as evidências que sustentam essa crença; esta é a incerteza que conseguimos enxergar; e é assim que atualizaremos o plano quando a realidade nos ensinar mais. No desenvolvimento de produtos complexos, isso é muito mais útil do que fingir que uma é uma promessa.
Principais aprendizados
Uma é uma estimativa baseada em evidências, não uma garantia absoluta.
Items selecionados representam uma ; o é o compromisso do .
não significa algo opcional ou descuidado - os devem fazer a melhor estimativa responsável que conseguirem.
Ambientes complexos contêm incerteza que não pode ser totalmente eliminada antes do início do trabalho.
O desempenho histórico pode aumentar a confiança da .
A capacidade futura deve ajustar expectativas para a próxima .
A afeta a quantidade real de trabalho necessária para concluir itens previstos.
O planejamento progressivo adiciona detalhe à medida que o trabalho se aproxima e se torna mais provável.
O é atualizado continuamente à medida que os aprendem durante a .
O escopo pode se adaptar por meio da colaboração com o enquanto o e a qualidade são protegidos.
Mudanças na devem ser orientadas por evidências e tornadas transparentes.
é útil em muitos produtos, mas não é um evento formal do .
Uma não é uma promessa e deve ser atualizada quando novas informações emergem.
Done Increments podem ser liberados antes da .
Burn-downs, burn-ups, , velocity, e Monte Carlo são técnicas opcionais, não requisitos do .
A apoia o , mas nunca substitui transparência, inspeção e adaptação.
