A estimativa de histórias baseia-se na noção de que, com o tempo, uma equipe ganha experiência para resolvê-las. Com isso, a precisão é melhorada e a velocidade pode ser estabelecida para medir a velocidade de uma equipe. Uma metodologia perfeita para estabelecer prognósticos confiáveis para futuros sprints.
Bugs são um fato da vida de uma empresa de desenvolvimento de software. Embora eu concorde que todos os erros devem ser capturados durante o desenvolvimento de uma história, aceitar que isso não pode ser alcançado em todos os momentos deve ser algo que toda equipe deve planejar. Em vez de teimosamente pensar que o processo deve governar a equipe, deve ser o contrário.
Claro, bug ou história, do lado comercial, não importa com o que a equipe está lidando. Ambos podem produzir uma quantidade igual de valor para o proprietário do produto.
Em nossa equipe, experimentamos algumas técnicas para estimar bugs:
- Estimando bugs completamente desconhecidos
- Apenas estimando erros que já foram analisados
- Atribuindo tempo para a correção de bugs e não estimando bugs, mas classifique-os com base apenas no valor comercial
Com 1. falhamos de maneira insuficiente. Para a maioria dos bugs, descobrimos que 90% do tempo é gasto na análise de erros. Depois disso, a correção do bug pode ser estimada da mesma maneira que uma história. Ao planejar os erros em um sprint, cometemos o erro de que o escopo desconhecido afetou a resolução da história até o ponto em que quase todos os sprints que fizemos dessa maneira falharam.
Com base na proporção de 90/10 (análise para correção de bugs) a opção de técnica de estimativa 2. significava que tínhamos que planejar uma análise que não era coberta pelo planejamento de sprint (aprendemos da opção 1, mas nenhuma solução real como continuar com os erros analisados). O resultado foi que a análise de erros não foi feita desde que um sprint se concentrou nos itens planejados. A equipe não teve tempo de se concentrar nos bugs do backlog. Então, eventualmente eles também não foram feitos.
Ao adotarmos a incerteza, agora decidimos sobre a opção 3. Dividimos o backlog do produto em uma parte regular da história / tarefa que pode ser estimada pela equipe usando pontos de história e um backlog de bug. No backlog de bugs, o proprietário do produto classifica os bugs com base no valor comercial e no julgamento da equipe. A equipe permite alocar um bom tempo durante um sprint que pode ser gasto com foco em bugs. O proprietário do produto não sabe o resultado exato, pois não foi possível planejá-lo antes. O rácio entre o backlog de bugs e o backlog normal pode ser ajustado para cada sprint, dependendo do status atual de cada backlog e da importância e valor comercial do conteúdo.
Eliminando a incerteza, liberou a equipe novamente. Sprints não foram comprometidos por erros desconhecidos. Ao separar os bugs em um backlog diferente, aumentamos o foco de sprint regular da equipe e fizemos com que terminássemos bugs que também continham um valor comercial significativo.
Então, depende se os pontos da história são adequados para você. Eu tentaria estimar os bugs usando pontos de história primeiro. Se isso falhar, tente a minha opção 3. Ela fez com que nosso time (mais de 30 anos de idade) se concentrasse em bugs antigos que contenham grande valor comercial. Também nos libertou de tentar entregar algo que a equipe simplesmente não pode estimar. Ele estava abraçando o desconhecido que nos aproximou da realidade e também fez com que nossos sprints fossem bem-sucedidos novamente enquanto oferecia um grande pedaço (baseado na proporção do bug à história) de valor de negócios por meio de correções de bugs. A proporção que usamos recentemente foi de 50/50.