Como o coração do Scrum cria uma cadência fixa de aprendizado, contém os demais eventos do Scrum, protege a qualidade e o Sprint Goal, permite a adaptação do escopo e melhora a previsibilidade no trabalho complexo de produto.
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 como o evento que contém os demais eventos do , por que ela dura um mês ou menos, como as Sprints começam e terminam sem intervalos, como o cria foco, por que a qualidade não pode diminuir, como o refinamento e a adaptação do escopo funcionam dentro da e como ciclos mais curtos melhoram o aprendizado, a previsibilidade e o controle de riscos.
Introdução: a é o ritmo que torna o empírico
O não exige que uma equipe planeje perfeitamente, desde o início, todo um produto complexo. Ele exige que a equipe estabeleça um ritmo disciplinado no qual ideias sejam repetidamente transformadas em valor utilizável e em novas evidências.
A é o evento que cria esse ritmo. O Scrum Guide atual chama as Sprints de coração do . A metáfora é precisa: assim como os batimentos cardíacos estabelecem uma cadência biológica regular, uma estabelece uma cadência regular para o desenvolvimento de produto. O trabalho é planejado, executado, inspecionado e adaptado dentro de um período delimitado que se repete continuamente.
As raízes históricas da são inseparáveis do próprio . O foi desenvolvido no início da década de 1990 e apresentado publicamente em conjunto por Ken Schwaber e Jeff Sutherland em 1995. Ao longo do tempo, o framework evoluiu, mas a ideia central de um ciclo curto e recorrente de desenvolvimento permaneceu. O Scrum Guide de 2020 expressa isso com mais clareza do que nunca: ideias são transformadas em valor dentro de Sprints de duração fixa, de um mês ou menos, e a seguinte começa imediatamente após a anterior.
Essa estrutura não existe apenas por conveniência de gerenciamento de projetos. Ela existe porque o trabalho complexo não pode ser controlado de forma eficaz por meio de feedback distante. Quanto mais uma organização espera para inspecionar um produto, uma decisão técnica, uma hipótese sobre clientes ou uma abordagem de entrega, mais tempo e dinheiro podem se acumular por trás de uma ideia equivocada. As Sprints reduzem a distância entre decisão e evidência.
A também é mais do que uma iteração de desenvolvimento. Ela é o contêiner de todos os outros eventos do . A inicia a . As Daily Scrums sustentam a inspeção e a adaptação diárias. A inspeciona o resultado com os stakeholders. A encerra a ao identificar melhorias de qualidade e efetividade. Esses eventos não são cerimônias separadas orbitando um projeto; são partes de um único ciclo empírico.
Para candidatos à , a contém diversas regras sutis que podem ser facilmente confundidas. Sua duração máxima é de um mês, mas Sprints mais curtas são permitidas. A duração é fixa para aquela . Uma nova começa imediatamente após a anterior. A qualidade não diminui. O escopo pode mudar à medida que mais se aprende, mas as mudanças não devem colocar o em risco. O refinamento do pode ocorrer durante a . O pode se tornar obsoleto, mas somente o pode cancelar a . Compreender as razões por trás dessas regras é muito mais confiável do que memorizá-las como fatos isolados.
A como contêiner de todos os outros eventos do
O contém cinco eventos: a própria , além de ,, e . A é o evento que contém os demais. Tudo o que é necessário para avançar em direção ao durante aquele ciclo - inclusive os quatro outros eventos formais e o próprio trabalho de produto - acontece dentro da .
Esse modelo de contêiner cria coerência. A não é uma reunião antes da ; ela inicia a . A não é uma atividade posterior à ; ela a encerra. A ocorre nos dias de trabalho dentro dela. A acontece perto do fim, mas ainda dentro da . Não existe, no , um período definido entre Sprints para testes, estabilização, preparação ou aprovação.
Esse último ponto é especialmente importante. Algumas organizações criam uma 'semana de hardening', uma semana de release ou um intervalo de planejamento entre Sprints. Essas práticas podem refletir restrições organizacionais reais, mas não fazem parte do . Se o trabalho precisa ser estabilizado depois da antes de poder ser utilizado, a pode estar fraca demais ou a equipe pode não estar realmente criando um Done dentro da .
Conter todos os eventos na cria um ciclo completo de feedback. O planejamento estabelece um objetivo e um plano inicial. A inspeção diária altera o plano conforme necessário. A Review inspeciona os resultados do produto e o ambiente. A Retrospective inspeciona a efetividade da equipe. Em seguida, a próxima começa imediatamente, já com o novo conhecimento disponível.
Âncora para a
A não é apenas um evento entre vários eventos equivalentes. Ela é o contêiner que abriga , Daily Scrums, , e todo o trabalho necessário para criar valor.
Duração fixa: um mês ou menos
Uma é um evento de duração fixa de um mês ou menos. Esse é um limite máximo, e não uma duração-padrão recomendada. As equipes podem utilizar Sprints de duas semanas, uma semana, três semanas ou outras durações, desde que não ultrapassem um mês.
O conceito importante é o tempo delimitado. Um fixo força as decisões de produto a caberem em um horizonte administrável. Em vez de perguntar 'Quando todo este trabalho ficará pronto?', a equipe pergunta 'Qual objetivo valioso podemos avançar durante este período fixo, considerando o que sabemos agora?'. O tempo permanece estável, enquanto o trabalho detalhado é previsto e adaptado dentro dele.
A consistência é valiosa porque durações repetidas criam ciclos de aprendizado comparáveis. A equipe aprende sobre sua capacidade de criar Increments Done dentro de um horizonte familiar. Os stakeholders sabem quando ocorrerão oportunidades formais de inspeção. A complexidade do planejamento diminui porque o calendário não precisa ser reinventado continuamente.
Um erro comum é estender uma porque o trabalho selecionado não foi concluído. O não apoia essa prática. Estender a enfraqueceria o e adiaria a inspeção. A resposta correta é inspecionar o que aconteceu, devolver ao apenas o trabalho futuro legítimo e melhorar , fatiamento, colaboração ou práticas de qualidade.
Da mesma forma, a equipe não escolhe a duração da de acordo com a quantidade de trabalho solicitada. O trabalho é selecionado para caber na ; a não é esticada para caber no trabalho. Isso protege a cadência e preserva a economia do feedback frequente.
Lógica do
Fixe a duração; adapte a e o plano. Não estenda a para resgatar escopo inacabado.
Por que Sprints mais curtas podem aumentar o aprendizado e reduzir riscos
O Scrum Guide explica que Sprints mais curtas podem gerar mais ciclos de aprendizado e limitar o risco de custo e esforço a um período menor. Isso não significa que quanto mais curta, melhor em qualquer situação. Significa que a frequência de feedback muda de acordo com a duração da .
Considere uma de um mês. O aprendizado formal da e da ocorre pelo menos mensalmente. Em uma de duas semanas, esses ciclos formais acontecem aproximadamente duas vezes mais. Em uma de uma semana, cerca de quatro vezes mais. Mais ciclos podem revelar hipóteses equivocadas mais cedo.
Sprints mais curtas podem ser valiosas quando a incerteza é alta, as condições de mercado mudam rapidamente, hipóteses de produto precisam de validação ou o risco técnico é significativo. Se uma equipe descobre depois de uma semana que uma suposição está errada, a exposição econômica pode ser muito menor do que descobrir isso após um mês.
Entretanto, reduzir a duração da também cria desafios. Os itens do precisam ser fatiados com mais eficiência. A precisa ser atingível com frequência. Testes automatizados, integração, deployment e acesso a stakeholders talvez precisem amadurecer. Uma equipe que não consegue criar valor utilizável em duas semanas não necessariamente se beneficiará apenas por declarar Sprints de uma semana.
Portanto, a duração da é uma escolha de desenho que equilibra frequência de aprendizado, custos de transação, contexto do produto e capacidade técnica da equipe. O estabelece apenas o limite superior de um mês.
Início e fim: não há intervalo entre Sprints
Uma nova começa imediatamente após a conclusão da anterior. Essa continuidade é uma característica definidora da cadência do .
A anterior termina com a . Em seguida, a próxima começa com a . O não define nenhum período de espera para aprovação da gestão, , coordenação de release ou reinicialização da equipe.
Por que isso é importante? Porque o produto continua existindo entre os ciclos de planejamento. As necessidades dos clientes continuam evoluindo. A tecnologia continua mudando. Questões operacionais podem surgir. Um grande intervalo entre Sprints criaria tempo morto no ciclo empírico.
Sprints contínuas também desencorajam o pensamento por fases de projeto. A equipe não 'termina o desenvolvimento' para depois entrar em uma fase separada de testes. Tampouco interrompe o trabalho de produto para preparar o próximo projeto. O permanece como uma unidade estável trabalhando em direção a um , após .
Isso não significa que as pessoas devam trabalhar continuamente sem descanso. , férias, feriados e planejamento saudável de capacidade continuam sendo importantes. Continuidade se refere à cadência do , e não à eliminação do tempo de recuperação humana.
: o único objetivo que dá sentido à
O é o compromisso associado ao e o único objetivo da . Ele cria coerência e foco ao dar ao uma razão para o trabalho que vai além de concluir uma coleção de itens.
Uma sem um objetivo significativo pode se transformar em uma fase curta de projeto com solicitações desconexas. Um Developer trabalha em relatórios, outro em uma alteração de segurança, outro em uma nova funcionalidade e outro em infraestrutura. Todos podem estar ocupados, mas existe pouco objetivo compartilhado em torno do qual a equipe possa colaborar.
Um forte permite adaptação porque separa propósito de escopo exato. O objetivo é estável o suficiente para oferecer direção, enquanto os itens exatos do ou os detalhes de implementação podem mudar à medida que mais se aprende. Os podem perguntar 'Que trabalho agora é necessário para atingir o objetivo?', em vez de 'Como concluímos todas as tarefas que previmos no primeiro dia?'.
O é criado durante a por meio da colaboração de todo o e deve ser finalizado antes do encerramento da . Depois que a começa, não devem ser feitas mudanças que o coloquem em risco.
Essa é uma distinção crucial para a . O escopo é adaptável; o é protegido. Se o próprio objetivo se tornar obsoleto porque o mercado, a regulamentação ou o contexto de negócio mudaram de forma fundamental, o pode cancelar a . Porém, o aprendizado normal costuma alterar o escopo ou o plano, e não o objetivo.
Objetivo versus escopo
O fornece estabilidade de propósito. O fornece flexibilidade no trabalho exato necessário para atingir esse propósito.
A qualidade não diminui durante a
O Scrum Guide afirma explicitamente que a qualidade não diminui durante a . Essa regra protege a transparência e a integridade do .
Equipes pressionadas por prazos frequentemente são tentadas a reduzir padrões: adiar testes, pular documentação, reduzir verificações de segurança, desabilitar quality gates ou criar intencionalmente para concluir mais escopo. Se essas medidas de qualidade fazem parte da , ignorá-las significa que o trabalho não está Done.
O permite adaptar o escopo. Se a equipe aprende que não conseguirá concluir todo o trabalho previsto no nível de qualidade exigido, a resposta profissional é colaborar com o , reavaliar o escopo e proteger o e a . A qualidade não é a variável usada para fazer uma parecer bem-sucedida.
Essa regra tem uma razão empírica. Quando a qualidade muda de uma para outra, 'Done' deixa de significar a mesma coisa. Os stakeholders não conseguem saber o estado real do produto. Trabalho oculto se acumula. Sprints futuras gastam capacidade corrigindo aquilo que Sprints anteriores fingiram estar concluído.
Manter a qualidade também favorece a previsibilidade sustentável. Uma equipe que sacrifica qualidade repetidamente pode parecer mais rápida no curto prazo, mas defeitos, arquitetura frágil, recuperação manual e retrabalho tornam a entrega futura cada vez mais imprevisível.
Refinamento do durante a
Durante a , o é refinado conforme necessário. Refinement é a atividade contínua de decompor e definir melhor os itens do , tornando-os menores e mais precisos.
Este é outro ponto importante para a : o refinamento do não é um evento formal do . O não prescreve uma reunião de refinamento, , lista de participantes nem um percentual fixo da capacidade da . As equipes frequentemente agendam conversas de refinamento porque são úteis, mas o Scrum Guide define refinement como uma atividade contínua.
O refinamento durante a melhora a qualidade das decisões futuras. Os aprendem mais sobre trabalho futuro, dependências, risco técnico, e contexto do produto. O pode esclarecer a intenção e reordenar itens com base em novas evidências. Itens que provavelmente serão selecionados em uma futura podem se tornar suficientemente compreendidos para sustentar um planejamento confiante.
O refinamento não deve se transformar em design detalhado com meses de antecedência. O é emergente, e o valor da análise detalhada diminui quando a incerteza é alta. A equipe deve refinar o suficiente para apoiar decisões úteis, permitindo que o aprendizado futuro ainda molde a solução.
O refinamento também pode ocorrer durante a para itens que estão sendo considerados. O Scrum Guide atual observa explicitamente que o pode refinar itens selecionados durante o planejamento para aumentar a compreensão e a confiança.
Armadilha da
O refinement acontece durante as Sprints conforme necessário, mas não é um dos cinco eventos formais do .
Adaptação de escopo: esclarecer e renegociar à medida que mais se aprende
Durante uma , o escopo pode ser esclarecido e renegociado com o à medida que mais se aprende. Essa afirmação representa a natureza adaptativa do .
A palavra escopo pode ser interpretada incorretamente como permissão para mudança descontrolada. não significa que qualquer stakeholder possa adicionar solicitações quando quiser. O cria um limite. Os gerenciam o , e a colaboração com o é necessária quando o escopo do produto ou os itens selecionados do precisam ser renegociados.
Imagine que a equipe planeje três itens do para atingir um relacionado à redução de falhas no checkout. No meio da , os descobrem que um item planejado é desnecessário porque uma mudança técnica menor resolve o mesmo problema. Eles podem adaptar o plano. Por outro lado, podem descobrir uma nova tarefa técnica essencial para atingir o objetivo. O deve mudar para refletir a realidade.
A equipe também pode aprender que a original é grande demais. Em vez de reduzir a qualidade ou estender a , e podem negociar qual escopo exato preserva melhor o . Isso transforma a em um ambiente adaptativo controlado, em vez de um pequeno contrato de escopo fixo.
O é, portanto, um plano em tempo real, e não um acordo que se torna obsoleto no instante em que novas informações surgem. Atualizá-lo é evidência de adaptação profissional, e não de fracasso de planejamento.
Previsibilidade no : cadência, não perfeita
O utiliza uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. A contribui para a previsibilidade ao garantir que o progresso em direção a um seja formalmente inspecionado e adaptado pelo menos a cada mês do calendário.
Esse tipo de previsibilidade é diferente de fingir que o futuro é completamente conhecível. Em ambientes complexos, o comportamento exato do produto, a resposta do mercado, o desafio técnico ou o aprendizado do cliente não podem ser previstos com certeza. Portanto, o cria oportunidades previsíveis de aprendizado, em vez de prometer resultados detalhados previsíveis.
Uma cadência fixa de permite que stakeholders saibam quando haverá inspeção significativa. A equipe sabe quando os objetivos serão revisitados, quando os resultados do produto serão analisados e quando a efetividade será inspecionada. Horizontes curtos limitam por quanto tempo hipóteses podem permanecer sem teste.
O desempenho histórico também pode apoiar previsões. podem usar informações sobre Sprints anteriores, capacidade, , ou outras evidências. O Scrum Guide menciona burn-downs, burn-ups e cumulative flow como possíveis práticas de , mas adverte explicitamente que essas ferramentas não substituem o .
Essa é uma distinção sutil, porém poderosa: o melhora a previsibilidade não ao eliminar a incerteza, mas ao limitar por quanto tempo a organização opera sem novas evidências.
Previsibilidade no trabalho complexo
O torna previsível a cadência de aprendizado, mesmo quando o resultado exato do produto no futuro não pode ser previsto.
A como um projeto curto - e por que essa analogia tem limites
O Scrum Guide afirma que cada pode ser considerada um projeto curto. Essa analogia pode ser útil porque uma possui um objetivo, um plano, trabalho, um limite de tempo e um resultado.
Entretanto, a analogia não deve ser levada longe demais. O é orientado a produto, e as Sprints formam uma sequência contínua em direção a um . A equipe não é repetidamente montada e desfeita. Cada se apoia nos Increments anteriores. O evolui em vez de ser reiniciado. O aprendizado se acumula.
Projetos tradicionais frequentemente definem sucesso como a entrega de um escopo predeterminado até uma data. Uma é diferente: o é fixo, a qualidade é mantida, o objetivo dá propósito e o escopo exato pode se adaptar à medida que mais se aprende.
Pensar em cada como um projeto curto é útil apenas quando isso reforça risco delimitado e trabalho com propósito. A analogia se torna prejudicial se encorajar mini-Waterfalls de escopo fixo ou a ideia de que cada deve ser planejada isoladamente como um contrato completo.
Exemplo prático - uma melhorando uma experiência de pagamento digital
Considere um responsável por um produto de pagamentos móveis. Dados recentes do produto mostram que clientes frequentemente abandonam um pagamento quando uma etapa de autenticação do dispositivo demora demais. O é tornar os pagamentos digitais mais rápidos e confiáveis sem enfraquecer a proteção contra fraudes.
Na , o explica as evidências e propõe que melhorar a conclusão da autenticação aumentaria o valor do produto. Todo o cria um : reduzir o abandono de pagamentos relacionado à autenticação para clientes recorrentes elegíveis.
Os selecionam itens do que acreditam apoiar o objetivo e criam um . O plano inicial inclui otimizar um serviço de validação de token, melhorar o comportamento de retry no cliente, adicionar observability e executar um experimento controlado de performance. A dura duas semanas.
No terceiro dia, a revela que o gargalo presumido não está no serviço de validação em si, mas em uma consulta lenta a uma dependência para um subconjunto de usuários. Os atualizam o . Uma otimização de UI planejada se torna menos importante, enquanto um experimento de caching passa a ser essencial.
O e os discutem as novas evidências. Eles renegociam o escopo: o item de UI sai da atual, enquanto o novo trabalho de caching é incluído. O não muda porque o objetivo continua sendo reduzir o abandono relacionado à autenticação.
Enquanto isso, a equipe continua refinando itens futuros do . Dados do suporte ao cliente revelam outro problema de autenticação que pode ser relevante em uma futura. O e os esclarecem o item, discutem possíveis formas de fatiamento e melhoram sua transparência. Nenhum 'evento formal de refinement' separado é exigido pelo .
No meio da , um gestor pergunta se os testes automatizados de performance podem ser ignorados para garantir que a funcionalidade de caching esteja pronta para a . Os testes de performance fazem parte da . A equipe se recusa a reduzir a qualidade. Em vez disso, os reduzem ainda mais o escopo não essencial, preservando o .
No décimo dia, um utilizável atende à . Ele poderia ser liberado antes da se o e a organização assim decidissem. A é usada para inspecionar resultados com os stakeholders, e não como um gate de aprovação para release.
Na , medições iniciais mostram que a latência de autenticação melhorou significativamente para o segmento-alvo, mas o abandono melhorou apenas parcialmente. Os stakeholders e o discutem uma nova hipótese envolvendo mensagens ao usuário. O muda.
A então inspeciona o processo da equipe. Os percebem que o gargalo da dependência teria sido descoberto antes com tracing melhor. Eles decidem melhorar a observability distribuída na próxima . A Retrospective encerra a , e a seguinte começa imediatamente, levando consigo o aprendizado acumulado de produto e processo.
Esse exemplo demonstra a finalidade completa da : cadência fixa, objetivo estável, escopo adaptável, qualidade preservada, refinement contínuo, valor utilizável, inspeção com stakeholders, melhoria da equipe e continuidade imediata para o próximo .
Armadilhas comuns da sobre a
Armadilha
Interpretação correta no
Uma pode durar mais de um mês se o trabalho exigir.
Falso. Uma dura um mês ou menos.
A pode ser estendida para concluir itens selecionados do .
Falso. O permanece fixo.
Pode existir uma semana de release ou de hardening entre Sprints.
Não faz parte do . Uma nova começa imediatamente após a anterior.
A acontece antes da .
Falso. A inicia a e ocorre dentro dela.
A acontece depois da .
Falso. Ela encerra a .
O e o escopo exato são ambos fixos.
Falso. O é protegido; o escopo pode ser esclarecido e renegociado.
A qualidade pode ser temporariamente reduzida se o aprovar.
Falso. A qualidade não diminui.
O refinement do é um evento formal obrigatório do .
Falso. É uma atividade contínua realizada conforme necessário.
Todos os itens selecionados do devem ser concluídos, ou a fracassou.
Falso. O objetivo é o e um valioso e utilizável; a pode mudar.
A é o gate de release.
Falso. Um pode ser entregue antes do fim da .
Sprints mais curtas são sempre melhores.
Falso. Elas podem criar mais ciclos de aprendizado e limitar riscos, mas a duração adequada depende do contexto.
O pode ser alterado sempre que as prioridades mudarem.
Falso. As mudanças não devem colocar o em risco.
Somente o pode alterar o .
Falso. Ele é um plano criado por e para os e é atualizado durante toda a .
Uma pode ser cancelada pelo se o trabalho estiver indo mal.
Falso. Somente o pode cancelar, quando o se torna obsoleto.
Previsibilidade significa que o deve garantir o escopo futuro exato.
Falso. A previsibilidade vem de ciclos empíricos curtos, inspeção, adaptação e evidências.
Um framework de raciocínio para questões da sobre Sprints
Contêiner: a resposta reconhece que a contém os outros quatro eventos do ?
: a tem um mês ou menos e sua duração permanece fixa depois de iniciada?
Continuidade: a seguinte começa imediatamente após a conclusão da anterior?
: a resposta protege o objetivo de mudanças que poderiam colocá-lo em risco?
Escopo: a resposta permite esclarecimento e renegociação com o à medida que mais se aprende?
Qualidade: a resposta preserva a em vez de trocar qualidade por mais escopo?
Refinement: a resposta trata o refinement do como atividade contínua, e não como evento formal?
Aprendizado: a resposta usa ciclos de feedback mais curtos para fortalecer o e reduzir a exposição ao risco?
Previsibilidade: a resposta favorece inspeção regular e evidências em vez de falsa certeza sobre escopo futuro detalhado?
Cancelamento: se o se tornar obsoleto, a resposta preserva a autoridade exclusiva do para cancelar a ?
Atalho para a prova
Em caso de dúvida, proteja o , preserve a qualidade, mantenha o fixo e adapte o com base no aprendizado.
Conclusão: a torna a adaptação segura ao lhe dar um ritmo estável
A é o coração do porque transforma a incerteza contínua em uma sequência disciplinada de ciclos de aprendizado. Ela oferece ao um horizonte fixo no qual perseguir um objetivo significativo, criar um utilizável, inspecionar evidências, melhorar sua forma de trabalhar e começar novamente de imediato.
Seu desenho contém um equilíbrio importante entre estabilidade e adaptação. O é estável. O fornece estabilidade de propósito. A qualidade não diminui. Ao mesmo tempo, o evolui, o escopo pode ser renegociado, o refinement do continua e os adaptam seu plano durante toda a .
Esse equilíbrio é o que permite ao operar efetivamente em ambientes complexos. Sem estabilidade, cada nova solicitação poderia causar caos. Sem adaptação, a equipe seria forçada a executar planos que a realidade já demonstrou estar errados. A cria estrutura suficiente para gerar foco e flexibilidade suficiente para permitir aprendizado.
Horizontes curtos de melhoram o controle de risco porque hipóteses equivocadas não podem permanecer indefinidamente sem inspeção. Sprints mais curtas podem criar ainda mais ciclos de aprendizado quando o contexto do produto se beneficia de feedback mais rápido. Porém, o objetivo não é velocidade por si só; é reduzir a distância entre ação e evidência.
A também fortalece a previsibilidade de forma realista. O não promete que o trabalho complexo possa ser previsto perfeitamente. Ele promete uma cadência regular para inspecionar o que realmente aconteceu e usar esse conhecimento na próxima decisão.
Na prática, é por isso que a é muito mais sofisticada do que uma fase curta de projeto. Uma fase de projeto frequentemente protege o plano. Uma protege o objetivo, o e a qualidade, permitindo que o plano mude. Essa distinção é central ao desenvolvimento empírico de produtos e essencial para quem se prepara para a avaliação .
Principais aprendizados
A é o coração do e o contêiner de todos os outros eventos do .
, Daily Scrums, , e todo o trabalho de produto acontecem dentro das Sprints.
Uma é um evento de duração fixa de um mês ou menos.
Uma nova começa imediatamente após a conclusão da anterior.
O é o único objetivo da e cria coerência e foco.
Não devem ser feitas mudanças que coloquem o em risco.
A qualidade não diminui durante a .
O é refinado conforme necessário durante a .
O refinement do é uma atividade contínua, e não um evento formal do .
O escopo pode ser esclarecido e renegociado com o à medida que mais se aprende.
O evolui durante toda a conforme os aprendem.
Sprints mais curtas podem criar mais ciclos de aprendizado e limitar o risco de custo e esforço.
As Sprints melhoram a previsibilidade ao garantir inspeção e adaptação frequentes, e não ao eliminar a incerteza.
Um pode ser entregue antes da ; a Review não é um gate de release.
Somente o pode cancelar uma , e somente quando o se torna obsoleto.
