Product Backlog

Oi Danilo, vou até encaminhar essa dúvida para os especialistas em agilidade, mas como já estou aqui, vou deixar meu pitaco.

Não leve a ferro e fogo essa parte de não entrar nada no spring. Se o bug é crítico, o que vamos fazer? deixar a app fora do ar :)? Vai ter que entrar no sprint e com prioridade alta, pq é um impeditivo.

O que eu já vi empresa fazendo é classificar os bugs pelo nível de problema que ele gera na app.. Se o bug for que uma tabela ficou desalinhada e vcs perceberam que isso não impacta muito na vida do usuário, aí pode deixar ele para depois... Aqui na alura tb é meio assim.. imagina se o exercício para de funcionar :)? Ou o fórum /o\?

o time e que vai resolver os problemas, um bom time sempre tem um testador mas pode acontecer de algo passar despercebido e o cliente ou usuário pode encontrar algo errado, é isso não e bom! o product owner retorna com o feedback e coloca no backlog, dependendo da feature volta pro backlog com prioridade.

Olá Danilo,

primeiramente, como o Alberto bem comentou, não precisa levar a ferro e fogo uma regra de algum processo ou framework ágil. Tem que sempre lembra que para a agilidade temos indivíduos e iterações mais que processos e ferramentas.

Segundo, não é totalmente verdade que o Sprint Backlog não pode ser alterado de jeito nenhum. Em diversos frameworks a ideia é que o Sprint Backlog seja mantido pelo time e "blindado" do cliente, no sentido de que o time pode atualizar o backlog seja desenvolvendo as histórias, adicionando uma nova história ou até mesmo removendo. Mas o cliente não pode simplesmente chegar no meio da sprint e alterar o Sprint Backlog como bem entender, ele primeiro precisa conversar e negociar com o time explicando o que aconteceu.

Por exemplo, no Scrum o Product Owner faz parte do time em si, então ele junto dos desenvolvedores e, eventuramente, o Scrum Master mantem o Sprint Backlog. Então se surgir um bug urgente, o cliente ou o usuário avisa o P.O., mostrando o bug encontrado e a gravidade daquilo, e gerar uma nova história. Caso seja urgente, o P.O. pode chamar os desenvolvedores para negociar de acrescentar uma história sobre o bug no Sprint Backlog, seja só colocando ela com todas as outras já definidas ou até mesmo removendo algumas histórias do Sprint Backlog para colocar o bug no lugar.

Outra estratégia que os times fazem quando os bugs aparentam serem frequentes é tirar uma métrica do número de bugs no sistema. Eles constroem um gráfico medido dia a dia de quantos bugs ainda não resolvidos existem ao todo no sistema e quantos bugs novos surgiram naquele dia. Se o time sente pelo gráfico que tem uma quantidade muito grande de bugs ou surgem muitos bugs novos todos os dias, os desenvolvedores e o P.O. entram em algum acordo de deixar um tempo de cada sprint reservado só para resolver bugs. Por exemplo, 15% de cada sprint será dedicada somente para solucionar bugs antigos ou novos que forem surgindo. Quando o gráfico estabiliza tira essa estratégia de 15% do tempo somente para os bugs.

Obrigado pelas respostas, é isso mesmo que eu imaginava... Tenho alguma vivência nestas situações e é isso mesmo que acontece, sempre que o BUG é crítico temos que solicitar ao time que arrume o quanto antes.

Obrigado!