Uma equipe de desenvolvimento de sistemas de software (EDSS) está trabalhando no desenvolvimento de uma nova aplicação Web utilizando práticas ágeis alinhadas com o Scrum. Algumas funcionalidades da aplicação Web já foram disponibilizadas aos clientes, porém um dos Product Owners solicitou mudanças em algumas delas. Sabendo-se que a EDSS está no meio do andamento de uma Sprint de 4 semanas cujo Sprint Goal não tem relação direta com as funcionalidades entregues, para atender à solicitação do Product Owner, a EDSS deve:
- A)alterar o prazo planejado para desenvolvimento da Sprint de modo a adicionar a alteração solicitada;
Errada, porque a Sprint tem time-box fixo e não deve ter seu prazo alterado para acomodar mudança de escopo.
- B)realizar uma Sprint Retrospective para decidir quando adicionar a alteração solicitada;
Errada, pois a Sprint Retrospective serve para melhoria do processo da equipe, não para decidir inclusão de mudança funcional no meio da Sprint.
- C)executar uma Sprint Review para determinar as adaptações para adicionar a alteração solicitada;
Errada, porque a Sprint Review inspeciona o incremento com stakeholders, mas não é o evento para definir adaptação de escopo durante a Sprint.
- D)manter o prazo planejado para desenvolvimento da Sprint, removendo um dos itens do Sprint Backlog para adicionar a alteração solicitada;
Errada, já que a equipe não deve remover item do Sprint Backlog para simplesmente abrir espaço a uma nova solicitação fora do Sprint Goal.
- E)manter o prazo planejado para desenvolvimento da Sprint, adicionando a alteração solicitada no Product Backlog.
Certa, porque a mudança deve ser registrada no Product Backlog, mantendo-se o prazo da Sprint e respeitando o caráter fixo do time-box.
Gabarito: E
No Scrum, a Sprint tem duração fixa e não deve ser esticada no meio do caminho só porque apareceu uma nova vontade do cliente. A lógica é simples: a equipe trabalha para atingir o Sprint Goal dentro do prazo já combinado, e mudanças de escopo entram no Product Backlog, onde o Product Owner pode reordenar as prioridades para futuras Sprints. Quando um pedido de mudança surge durante a Sprint, o caminho normal não é “quebrar o relógio” nem reinventar a Sprint. Se a mudança não está ligada diretamente ao Sprint Goal, ela não entra naquela Sprint como regra geral. Ela vai para o Product Backlog, que é exatamente a lista viva de tudo o que pode ser feito no produto. É por isso que o gabarito é a letra E. A EDSS deve manter o prazo planejado da Sprint e adicionar a solicitação ao Product Backlog. Isso está alinhado com o Scrum Guide: a Sprint é um contêiner de tempo fixo, e mudanças são tratadas no Product Backlog e em Sprints futuras, preservando foco, previsibilidade e inspeção do trabalho. Resumo de prova: Sprint não alonga, retrospectiva não decide escopo, review não serve para “encaixar” mudança no meio da execução. Em Scrum, a mudança entra no backlog e segue a fila.