Esse problema é tão antigo quanto o scrum. Existe uma solução, mas você não vai gostar.
- Coloque novas tarefas no backlog.
- Não interrompa os desenvolvedores.
- Aguarde o próximo sprint.
Colocar seus devs em mais de um scrum, ter dois backlogs separados ou atribuir apenas uma porcentagem de seu tempo ao sprint todo o trabalho contra o que o scrum está tentando alcançar, ou seja, um fluxo consistente de tarefas concluídas.
Se você tentar esse tipo de coisa, basicamente voltará às metodologias de desenvolvimento do 'caos' ou 'JFDI' com todos os problemas associados, por exemplo
- O desenvolvedor tem dez tarefas em movimento a qualquer momento. Ninguém sabe no que eles estão trabalhando ou quando será concluído.
- Tempo desconhecido para concluir o projeto, porque depende de quais outros projetos estão acontecendo ao mesmo tempo.
- Nenhuma visão consistente da prioridade do projeto. Outros gerentes desviam desenvolvedores para seus projetos favoritos.
É claro que a resposta usual a este conselho é "Mas eu não posso fazer isso! A empresa precisa que esses erros de produção sejam corrigidos o mais rápido possível!"
Mas isso não é verdade.
Se você realmente tem muitos bugs reais que estão afetando os negócios, você precisa se profissionalizar e melhorar seus testes. Apenas trabalhe com bugs e testes automatizados até ter corrigido todos eles. Contrate uma equipe de controle de qualidade e teste todos os novos lançamentos.
O que é mais provável, porém, é um dos seguintes:
-
Os bugs são problemas operacionais, com pouco espaço em disco, sem DR, sem Backups, sem failover, etc. Obtenha uma equipe de OPS.
-
Os bugs são usuários que não entendem como o sistema deve funcionar "Isso aconteceu! é um bug?". Obtenha um helpdesk e treine seus usuários, escreva a documentação.
-
Medo de reversão. Você lançou um novo recurso e quebrou alguma coisa, não tente apressar uma correção. Reverter para a versão anterior e colocar os bugs no backlog.