Você é o Scrum Master de uma equipe que está desenvolvendo ...

Alternativa Correta: B - Adicionar a nova funcionalidade ao backlog do produto, mas priorizar sua implementação na próxima sprint, respeitando o compromisso da equipe com as tarefas atuais.

Para resolver essa questão, é essencial compreender o contexto do Scrum, um framework ágil que visa promover a entrega de valor com flexibilidade, adaptabilidade e colaboração contínua entre os membros da equipe.

No Scrum, a Sprint é uma iteração de trabalho com duração fixa (geralmente de 2 a 4 semanas), dentro da qual a equipe se compromete a completar um conjunto de tarefas definido no início da Sprint. Uma vez que a Sprint começa, o escopo deve ser estável para garantir foco e produtividade da equipe.

Segundo o guia do Scrum, não é recomendado adicionar novos itens ao trabalho da Sprint em andamento, a menos que o escopo da Sprint possa ser mantido. Isso ajuda a proteger o compromisso da equipe e evita a sobrecarga de trabalho.

Justificativa da Alternativa Correta (B): A decisão de adicionar a nova funcionalidade ao backlog do produto e priorizar sua implementação na próxima Sprint é a mais alinhada com as práticas do Scrum. Isso respeita o compromisso atual da equipe e permite que a nova exigência regulatória seja tratada adequadamente, sem interromper o trabalho em andamento. Essa abordagem mantém o foco e a produtividade, ao mesmo tempo que se adapta a mudanças necessárias.

Análise das Alternativas Incorretas:

A: Negociar para incluir a nova funcionalidade na Sprint atual comprometeria o escopo e a estabilidade da Sprint. Essa prática não é recomendada, pois pode levar a uma sobrecarga de trabalho e desorganização.

C: Substituir uma tarefa atual pela nova funcionalidade durante a Sprint também altera o planejamento original, o que não é ideal no Scrum, já que o planejamento deve ser respeitado para garantir a consistência e o ritmo.

D: Organizar uma reunião de refinamento de backlog durante a Sprint para reprojetar o trabalho em andamento é uma quebra do planejamento da Sprint. Mudanças significativas no meio da Sprint devem ser evitadas.

E: Convocar uma reunião de revisão de Sprint antecipada para encerrar a Sprint atual e começar uma nova também é uma quebra de fluxo, causando interrupções desnecessárias no trabalho da equipe.

Estratégia de Interpretação: Ao analisar questões sobre Scrum, é importante lembrar que uma das características principais desse framework é a estabilidade e foco durante as Sprints. Mudanças são inevitáveis, mas devem ser geridas de forma a não comprometer o trabalho em andamento. Identificar alternativas que respeitam o planejamento original da equipe é crucial.

Gostou do comentário? Deixe sua avaliação aqui embaixo!

aí eu termino uma Sprint sem todos os requisitos para começar uma nova e ter que refazer a anterior? oi?

A questão é sobre meta da sprint, em uma situação específica. Olhando as referências, entendi o que ta sendo cobrado:

A Sprint 

Sprints são o coração do Scrum, onde ideias são transformadas em valor. São eventos de duração fixa de um mês ou menos para criar consistência. Uma nova Sprint começa imediatamente após a conclusão da Sprint anterior. Todo o trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily Scrums, Sprint Review e Sprint Retrospective, acontece dentro de Sprints.

Durante a Sprint:

● Nenhuma mudança é feita que coloque em risco a meta da Sprint;

● A qualidade não diminui

● O Product Backlog é refinado conforme necessário; e

● O escopo pode ser esclarecido e renegociado com o Product Owner conforme mais é aprendido. 

Compromisso: Meta da Sprint

A Meta da Sprint é o único objetivo da Sprint. Embora a Meta da Sprint seja um compromisso dos Developers, esta fornece flexibilidade em termos do trabalho exato necessário para alcançá-la. A Meta da Sprint também cria coerência e foco, encorajando o Scrum Team a trabalhar junto ao invés de iniciativas separadas. A Meta da Sprint é criada durante o evento Sprint Planning e então adicionada ao Sprint Backlog. Conforme os Developers trabalham durante a Sprint, eles mantêm a Meta da Sprint em mente. Se o trabalho acabar sendo diferente do que eles esperavam, eles colaboram com o Product Owner para negociar o escopo do Sprint Backlog dentro da Sprint sem afetar a Meta da Sprint. 

Voltando para a questão:

É possível fazer mudanças e negociar o escopo, desde que não afete a meta da sprint em andamento. Percebam que a questão cobra exatamente o que fazer na situação que afeta a meta da sprint, pois deixa bem claro que qualquer alteração nos trabalhos da equipe na sprint, pode afetar a entrega. Logo, qualquer alternativa que sugiresse fazer ajustes na sprint atual está errada, sobrando apenas a alternativa B.

Questão relativamente difícil. E quem me dera se fosse assim no dia a dia do trabalho...