Estou trabalhando em uma loja semelhante. Como outros observaram aqui, o que você descreve pode ser ágil, mas não scrum. Eu também acrescentaria que o fato de fazer ou não os registros e sprints de volta faz sentido depende se é um novo trabalho ou manutenção e suporte contínuo. No primeiro caso, uma abordagem em cascata faria mais sentido para uma equipe de uma pessoa. Caso contrário, da perspectiva do gerente de projetos, o que eles estão fazendo parece uma boa abordagem se tiverem vários projetos em seu portfólio.
Para os entusiastas do Agile, a mera menção ao uso de cascata é sacrilégio. Mas as pessoas precisam usar o bom senso.
Deixe-me dar um exemplo de um projeto recente meu. Eu estava liderando uma equipe de 3 desenvolvedores em uma agressiva linha do tempo de cinco meses para redesenhar dois dos principais sites. Tivemos reuniões diárias de stand-up. Mas era um projeto em cascata porque era uma equipe pequena, com um ciclo de vida limitado, e os desenvolvedores eram todos contratados a curto prazo comprometidos com o projeto somente até o lançamento. O projeto seguiu um ciclo de vida em cascata muito tradicional. Absolutamente nada de errado nisso. Exceto pelo fato de termos trabalhado de maneira "ágil", mantivemos as reuniões de pé e as melhores práticas de desenvolvimento ágil. Nossa pequena equipe foi dispensada das reuniões semanais de planejamento de sprints da equipe maior. Por quê? Porque não tivemos implantações semanais. E nossa equipe não dependeu ou influenciou o trabalho que está sendo realizado por qualquer outra equipe. De fato, trabalhamos quase de forma autônoma. Depois que os sites foram lançados, passamos para um processo ágil para manutenção e suporte contínuos. Os outros desenvolvedores agora estão trabalhando em outros lugares. Todas as melhorias são planejadas de acordo com implantações periódicas.
O ponto é que é melhor usar os processos que fazem mais sentido para o tamanho, a complexidade e a maturidade de cada projeto. Se você está pesquisando bastante, é difícil fazer uma estimativa para os próximos cinco meses, portanto, agilidade é provavelmente uma abordagem melhor do que a cascata.
Parte do problema é que algumas pessoas pensam que você pode planejar os próximos cinco sprints com antecedência. Esse tem sido o meu caso antes. Você não deve planejar mais de dois sprints porque, se estiver, estará derrotando todo o propósito de ter sprints. Um sprint deve ser um compromisso de fornecer uma quantidade realista de aprimoramentos dentro de um período de tempo definido. Você não deve se comprometer com algo que não tem certeza. O planejamento de sprint é, por natureza, um planejamento de curto prazo, mas esse é o ponto. Se você tiver um cronograma de longo prazo, pense em dividir as coisas em entregas menores. Ou configurando reuniões de ponto de verificação com base em onde você está no SDLC.
O planejamento da sprint deve ser um compromisso realista sobre o que é garantido que será concluído dentro de um determinado período de tempo. Se você achar que o planejamento não está respondendo a variáveis desconhecidas, talvez deva começar a fornecer faixas ou estimativas pessimistas. Ou, como sugerido, use pontos da história. Os sprints também não devem ser reservados completamente para permitir derrapagens e outras tarefas importantes que surgirem.