Questão de Engenharia de Software — SCRUM — CESPE / CEBRASPE 2025
Engenharia de Software›SCRUM
Código
ce417821
Banca
CESPE / CEBRASPE
Órgão
EMBRAPA
Ano
2025
Cargo
Ana ( )
A respeito de metodologias ágeis, julgue o item a seguir.
A duração da sprint no Scrum é variável, podendo ser aumentada conforme novos itens forem sendo acrescentados ao escopo.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Scrum: duração da Sprint
❌ ERRADO. No Scrum, a Sprint tem duração fixa (time-boxed), com limite máximo de um mês, e não pode ser estendida para acomodar novos itens de escopo. Novos itens são adicionados ao Product Backlog e priorizados para Sprints futuras, nunca inseridos na Sprint em andamento. Essa é uma distinção fundamental entre o Scrum e o Kanban, que trabalha com fluxo contínuo.
A Sprint é o coração do Scrum — um período de tempo limitado (time-box) durante o qual o Time Scrum trabalha para transformar itens do Product Backlog em um Incremento de produto potencialmente utilizável. A duração é fixa e consistente ao longo do projeto: uma vez definida (ex.: 2 semanas), ela não muda de uma Sprint para outra. O Guia do Scrum é claro ao afirmar que a Sprint é um "time-boxed" de um mês ou menos, e que "uma nova Sprint começa imediatamente após a conclusão da Sprint anterior".
A regra da duração fixa existe por um motivo: ela cria um ritmo previsível para o time e para os stakeholders. Com um prazo constante, a equipe aprende a planejar melhor, a estimar com mais precisão e a entregar valor de forma consistente. Se a Sprint pudesse ser estendida a cada novo item, esse ritmo quebraria, e o time perderia a capacidade de inspecionar e adaptar o processo em intervalos regulares — violando os pilares do empirismo (transparência, inspeção e adaptação) que sustentam o Scrum.
Na prática, quando um novo requisito surge durante uma Sprint, ele não é adicionado à Sprint atual. O Product Owner o registra no Product Backlog, e o time decide, no próximo Sprint Planning, se ele entra na próxima Sprint e com qual prioridade. Isso protege o time de interrupções constantes e garante que o objetivo da Sprint (Sprint Goal) permaneça estável. A flexibilidade do Scrum está em responder a mudanças entre Sprints, não em alterar a duração da Sprint em andamento.
A pegadinha da banca está em confundir a flexibilidade do escopo (que é real e desejável no Scrum) com a flexibilidade do tempo (que não existe). O Scrum é adaptativo em relação ao que será entregue, mas é rígido em relação ao prazo de cada iteração. É exatamente essa combinação — escopo flexível, tempo fixo — que permite ao time aprender e melhorar continuamente.
NÃO CAIA NESSA!
A banca troca a flexibilidade do escopo pela flexibilidade do tempo. No Scrum, o escopo da Sprint é congelado após o Sprint Planning; novos itens vão para o Product Backlog e entram na próxima Sprint. A duração da Sprint é fixa (time-boxed, máx. 1 mês) — se a questão disser que a Sprint pode ser aumentada, está errada. Essa é uma das inversões mais comuns em provas de Scrum.
PEGA ESSA DICA!
Para acertar questões sobre Scrum, memorize a tríade: Sprint = time-box fixo (≤ 1 mês), escopo = definido no Planning e congelado, mudanças = vão para o Product Backlog. Se a alternativa falar em "duração variável", "sprint estendida" ou "escopo alterado durante a sprint", marque errado sem hesitar.
1Duração fixa (time-box ≤ 1 mês)
2Escopo definido no Planning
3Novo item → Product Backlog
4Priorizado para próxima Sprint
LEVEL · soulevel.com.br
Item — ❌ ERRADO ⟵ GABARITO
A afirmação está incorreta por dois motivos: (1) a duração da Sprint é fixa (time-boxed), não variável; e (2) novos itens de escopo não são acrescentados à Sprint em andamento — eles são adicionados ao Product Backlog e priorizados para Sprints futuras. O Guia do Scrum estabelece que a Sprint é um período de um mês ou menos, com duração consistente ao longo do projeto. Alterar a duração da Sprint para acomodar novos itens quebraria o ritmo do time e violaria o princípio do time-box, que é essencial para o empirismo e a previsibilidade do framework.