Fórum de discussão

Para piorar a situação esta sprint é fundamental para o lançamento do serviço da empresa previsto para daqui a 3 dias e, devido ao volume dos itens apontados como não-atende, o time de desenvolvimento não tem como realizar a entrega dentro dentro desta restrição (3 dias):

Fica claro que nessa situação houve falha no planejamento da Sprint, as histórias de usuários não estavam claras o suficiente e pode não ter havido comunicação adequada entre a equipe de desenvolvimento e o dono do produto durante a sprint para tirar dúvidas. Estas falhas do processo Scrum são discutidas na reunião de retrospectiva e as melhorias no processo implementadas para a próxima sprint. 

Não se espera que uma situação desta ocorra na sprint final na véspera de lançamento do produto em operação. Isto é tipico em primeiras sprints.  Se usa sprints com duração menor quanto maior for o risco do projeto, justamente para avaliar os incrementos e fazer as adaptações nas próximas sprints.  Se isto ocorrer na véspera de lançamento do produto e não há mais tempo, o que demonstra um não comprometimento e irresponsabilidade total de todas as partes envolvidas no projeto, a equipe scrum vai se reunir e decidir o que melhor fazer para salvar projeto ou o negócio paga pela falta de comprometimento das partes envolvidas. Não existe fórmula mágica para isto. O Scrum não foi pensado para resolver situações trágicas deste tipo. Ele foi pensado para que isto não ocorra. 

O papel do Scrum Master é facilitar a ocorrência da reunião de retrospectiva e se identificadas as causas das falhas foi a falta de conhecimento em técnicas, como uso de histórias de usuários, ensinar o dono produto a detalhar melhor suas histórias de usuário. Se foi identificado que a equipe de desenvolvimento não teve acesso ao dono do produto para tirar dúvidas, cabe ao Scrum Master conversar com o Dono do produto e explicar como isto vai afetar o resultado final.  O papel do Scrum Master é remover os impedimentos que existem na equipe de desenvolvimento. 

No contexto colocado por você temos inúmeros cenários que podem ter ocorrido, cada qual com seu problema e sua solução.

Cenário 1: As sprints anteriores já vinham apresentando problemas.

Perceba que para ter um cenário de desastre total como você descreveu, as outras sprints também devem ter falhado. Porque não é por uma sprint falha que todo o objetivo e meta vai por água abaixo. Então neste caso, os problemas precisariam ter sido resolvidas nas sprints anteriores, e se não foram pode ter sido por falta de comprometimento do time, falta de habilidades do Scrum Master ou falta de conhecimento generalizado.

Cenário 2: Priorização errada

Se as primeiras sprints tivessem sido executadas corretamente e apenas a última deu problema e isso afetou tão negativamente a entrega  ao cliente, então a priorização do PO foi errada, porque deixou itens importantes demais para entregar na última sprint.

Então veja que para saber o que precisa ser feito e o que exatamente deu errado, precisa-se de mais informações a respeito do contexo geral.

um abraço,

Kelvin