Baseado no texto de Dan Puckett, publicado recentemente no InfoQ, uma das questões clássicas que surgem é se o tempo envolvido na correção de bugs deve ser considerado ou não para a pontuação da equipe. Qual seria a melhor alternativa? Mike Cohn consideraria os pontos no caso dos bugs existentes antes da migração para Scrum:
My usual recommendation is to assign points to the bug fixing. [...] We are able to see how much work the team is really able to
accomplish but also able to look at the historical data and see how much went into the bug-fixing story each sprint. Knowing this can be helpful to a team and its product owner. For example, imagine a situation in which the product owner is considering suspending bug fixing for the next six sprints in order to add a valuable different feature into a release. If we know that the team's full historical
average velocity was 25 but that 5 points went to bug fixing each sprint, we know that suspending bug fixing for the next six sprints
will result in 30 (6*5) more points of new functionality.
No Brasil, Guilherme Silveira descreve os pontos positivos e negativos de cada abordagem. Em adição a estratégia recomendada por Mike, Charles Bradley defende mais opções para a equipe corrigir bugs:
[...] enquanto PO's podem priorizar bugs na lista, os desenvolvedores também devem possuir a liberdade de escolher qualquer
bug para ser fixado, estando ele no backlog ou não, e trazendo o mesmo para o sprint como uma tarefa, ganhando pontos no sprint,
independentemente do mesmo estar no backlog original ou não. Somente o time de desenvolvimento pode decidir quanto do product backlog pode ser trazido para o sprint e se decidirem passar 50% do tempo fixando bugs que o PO não havia priorizado, que eles tenham tal liberdade, mas a velocidade deles ficará claramente mais baixa.
Jack Milunsky distingue bugs legados dos gerados dentro do próprio sprint:
Pontos só devem existir para pontos legados, aqueles que foram gerados anteriormente. O valor nesse caso é para o PO - na questão de
qualidade. Bugs encontrados e corrgidos durante o sprint não de vem possuir pontos uma vez que isso afetaria a velocidade de uma maneira a gerar uma falsa sensação de aumento.
E no caso dos bugs que surgiram após a adoção do Scrum, mas descobertos somente após o Sprint? Esse é o caso clássico, onde as
histórias foram aprovadas em sprints anteriores mas bugs são encontrados posteriormente. Segundo Ron Jeffries:
"Se a história é aprovada com um bug, a mesma já foi registrada na velocidade. Sendo assim, a mesma já está artificialmente alta:
reduzimos nosso sucesso pelo valor da história e readicionamos a mesma no backlog - um trabalho custoso e exagerado - ou ainda simplesmente corrigimos o defeito, algo que pode levar menos ou mais tempo que a história original. De qualquer maneira, o tempo necessário para completar a história corretamente, e o número absoluto de histórias completadas, oferecem uma visão melhor do que adicionando pontos novos aos bugs. Além disso, não é necessário estimar, uma vez que o desperdício criado na correção do bug não possui originalmente nada de valor."
A visão é um pouco radical em acreditar que o ideal seria acertar as histórias de primeira, sem bugs, e qualquer bug que surge é algo que
não deveria acontecer. Seria possível situações como essas em que todas as hsitórias, após aceitas, não apresentam bugs?