Olá Ester e Bruno,

Muito bom o comentário de vocês!

Um comentário: na minha visão, a correção de bugs, tarefas de teste ou quaisquer outras tarefas relacionadas ao produto que o Time Scrum está executando, devem está listados no Backlog do Produto para também fazerem parte de uma Sprint. Assim o Time de Desenvolvimento tende a ficar mais comprometido com o produto que estão desenvolvendo, uma vez que a responsabilidade de fazer o produto (software codificado) fica apenas com eles.

Olá Bruno!

O objetivo desse post foi apenas apresentar os pontos que temos que nos cuidar quando tivermos acúmulo de papéis de Membro do Time sendo também Scrum Master, pois cada equipe dará sua solução em função do seu contexto. Sendo assim, foi muito legal a sua contribuição aqui no blog.

Essa é uma questão que sempre é abordada e que demanda muita discussão, e nada melhor que ouvir as soluções de cada equipe para formularmos a nossa. Mas para isso é sempre importante a contribuição de todos.

Parabéns pelo seu comentário, Gostei muito! Só devolvo para você uma pergunta (de curiosidade mesmo!):

O fato do Scrum Master (dentre várias responsabilidades extras que você citou) ficar responsável pela correção de bugs não cria um clima de menor responsabilidade na equipe de desenvolvimento quanto a quantidade de bugs que são deixados no produto entregue? Eles já sabem que é o Scrum Master que terá que resolvê-los! Como vocês lidam com isso?

Para tentarmos contornar esse inconveniente, atualmente temos utilizado de dois artifícios:

1. O SM é considerado no Sprint como “menos de um recurso”. Ou seja, ele é considerado, por exemplo, como 50%.

2. O SM não participa das atividades do Sprint. O seu tempo ocioso é aplicado a tarefas de fora do Sprint: correção de bugs, ações urgentes, desenvolvimento de tarefas já discutidas mas que não entraram para o Sprint, tarefas referentes a outros projetos, etc.

Assim, tendemos a minimizar os problemas citados no artigo.