Pontos de bugs contam na velocidade?

Após definir um método objetivo de avaliação de valor para histórias técnicas, onde defendo que qualquer história técnica de tamanho razoável pode ser descrita como algo que agrega valor ao produto; o Alex da Locaweb levantou outra dúvida clássica que surge no workshop de POs: corrigir bugs possui algum valor ou conta na velocidade da equipe?

Não

A abordagem tradicional por equipes que adotam Scrum é de definir que a correção bugs não são pontuados e não contam na velocidade. Ferramentas de controle de sprint valorizam esse tipo de abordagem.

O pivotal pode ser configurado para contabilizar, mas não é recomendado pela ferramenta.

O gráfico de velocidade reflete a esperança de quanto valor em funcionalidades novas e modificações a equipe entrega.

A desvantagem está no momento da definição de um sprint backlog, que os desenvolvedores não sabem se atenderão ou não a média por causa dos bugs que entram.

Exemplo prático: se sua empresa possui um legado com grande número de chamados atendidos pela equipe, é comum se desmotivarem, pois entregam poucos pontos. Grande parte do esforço vai para corrigir bugs – sem valor. Como as metodologias ágeis dizem, o problema da qualidade de código legada grita.

Nesse caso, sugiro separar um número de bugs a serem corrigidos para que seu produto não fique parado no tempo, somente corrigindo débito técnico. Algo comum é definir uma hora por dia no início/final do expediente para ser gasto com bugs e chamadas.
O importante é adotar alguma prática para reverter a situação!

Sim

Ao definir que um bug possui “X” de valor, o time sabe quanto consegue uma previsão, por sprint, do quanto pode se comprometer, agrupando bugs e histórias de uma só maneira.

A desvantagem: ao medir o valor de histórias entregue, o gráfico indica uma falsa noção de velocidade de histórias novas.

Note que a velocidade entregue é real, mas indica quantos bugs e histórias novas sua equipe é capaz de entregar; não somente histórias.

Revezar entre as abordagens?

Os dois métodos apresentam uma velocidade média que pode ser utilizada enquanto aquela abordagem permanecer, o mais importante é não mudar de abordagem e desejar manter tal métrica como real, pois não é.

Parcialmente

Uma solução intermediária está em contabilizar os pontos dos bugs no momento de estimar o que será comprometido e não contabilizá-los no momento de dizer a velocidade para o cliente.

A métrica diz agora o quanto o cliente espera receber de valor de histórias e a equipe sabe quantos bugs espera corrigir.

Nessa situação adotamos, sem perceber, duas pontuações diferentes, mas com a desvantagem que a maioria das ferramentas online não são capazes de tratar.

Mais uma abordagem: dois tipos de pontuação

Cerca de dois anos atrás em uma conversa com o Alexandre Magno, lembro de termos comentado da diferença de valor e dificuldade.

Enquanto muitos projetos conseguem sobreviver com uma única medida, em produtos com entregas contínuas (desculpe pelo uso da palavra produto aqui), uma opção é manter uma medida de valor, que o Product Owner julga e outra que de dificuldade que a equipe define.

A equipe sabe quanto espera entregar em histórias e bugs e o PO o quanto espera receber de valor de histórias, de bugs ou de ambos. O melhor dos dois mundos.

O custo disso está no pouco suporte encontrado por ferramentas de visualização e controle de iterações.

Com isso, o PO coleciona com o passar do tempo, estatísticas em relação ao valor de uma história/bug e sua dificuldade esperada.

Lean/Kanban

Em “projetos de longa duração”, juntando a prática de duas medidas e Lean/Kanban, conseguimos gerar estatísticas e calcular o tempo esperado para a enésima história do backlog entrar em produção, em dias esperados:

Dn = Somatoria(de 1 ate n) Esperança(Valor, DificuldadeEsperada(Valor))

Todas as contas são baseadas em estatísticas e dão previsões. Como qualquer média, existe um desvio padrão e uma amostra mínima que consideradas, permitem alcançar uma margem de erro desejada.

A mesma média pode ser alcançada, com um cálculo um pouco mais complexo, em processos baseados em sprints.

E você, como está lidando com bugs em seus projetos?