Tem ocorrido diversos debates recentes sobre a decisão de contabilizar a correção de bugs na medição de velocidade de uma equipe ágil. A questão parece não possuir uma única resposta correta, contudo alguns agilistas discorrem sobre em quais casos a correção de bugs deve ser adicionada a contagem de velocidade e quando deve ser desconsiderada.
Syed Rahan, criador da ferramenta Scrumpad, sugere que a decisão de inclusão da contagem de bugs depende da forma que é caracterizada a velocidade. Se a velocidade é baseada em "perspectiva de valor", a correção de bugs não deve ser considerada, pois não adiciona valor ao cliente. Contudo, se a velocidade é baseada na "perspectiva de custo", então as correções de bugs devem ser contabilizadas pois tomam tempo e esforço (e portanto custo) para serem realizadas.
Mike Cohn recomenda que pontos de história (story points) sejam atribuídos a correções de bugs:
Esta solução une o melhor de dois mundos. É possível visualizar a quantidade de trabalho que a equipe está apta a realizar, e se pode observar os dados históricos além de visualizar quantos pontos foram gastos em correções de bugs no sprint
Jason Yip, consultor da Thoughtworks, faz uma analogia interessante quando compara a velocidade a um indicador da maneira que se avança em direção a uma meta. Yip, através de desenhos e fórmulas, enfatiza que a parte mais importante é a meta:
Imagine um cenário em que um atleta corre em direção a uma linha de chegada (meta). Se a referência temporal é um minuto, então a velocidade do atleta é a distância percorrida em direção à meta, dividida pelo tempo decorrido (veja a figura abaixo, extraída do post de Yip). A parte importante da analogia de Jason Yip é em "em direção à meta".
Jason Yip, segue seu exemplo propondo um cenário em que foram percorridos 10 metros, mas em que, por alguma razão o atleta retrocedeu 5 m. Logo após, o atleta se recupera e percorre mais 5 m. A distância total percorrida foi de 15 metros, mas o atleta está na marca de 10:
Desta forma, o autor verifica que o progresso total foi de 10 m, pois a medida é relativa ao progresso em direção a uma meta e não ao esforço despendido. Sendo assim, Yip conclui que a velocidade é um vetor e não um escalar.
Na seção de comentários do post de Jason Yip, é sugerida uma avaliação conjunta para determinar velocidade:
Eu incluiria a contagem da correção de bugs na velocidade mas gostaria de descontar esta velocidade das iterações anteriores onde o bug foi criado. Desta forma aplicaria um valor negativo nesta iteração.
Em outros comentários, é levantado que é perigoso não contabilizar a correção de bugs na medição de velocidade, pois há vários contextos em que isso não faz sentido.
Jack Milunsky, no blog Agile Software Development menciona que independentemente de ser levada em conta ou não a correção de bugs para a velocidade do time, esse trabalho deve ser considerado pois consome tempo de desenvolvimento da sua equipe.
A correção de bugs deve ser agendada em um sprint ou iteração durante o planejamento do sprint. Desta forma o tempo total para implementar as tarefas de conserto de bugs não deve exceder a capacidade de trabalho do seu time. Sei que muitos consultores argumentam que correções de bugs devem ser medidas separadamente e que bugs devem ser corrigidos durante o sprint. Mas isso nem sempre funciona na prática. Agende a correção de bugs no planejamento do sprint e você irá melhorar a estimativa do seu time significativamente.
Existe, portanto, um consenso na importância da contabilização de correções de bugs no processo de desenvolvimento. Mas considerar - ou não - essa atividade ao calcular a velocidade do time é uma questão controversa, pois a decisão depende muito do contexto no qual a equipe está inserida e da forma como a velocidade é caracterizada.