Uma discussão recente no grupo ScrumDevelopment do Yahoo! debateu sobre os diferentes usos e abusos da velocidade. Kurt Häusler descreveu seu entendimento sobre velocidade e o valor dela:
Olá, a velocidade é medida contando o número de pontos história concluídos na última iteração. Não tenho certeza se ela é apropriada como uma métrica de produtividade. Para mim é uma medida neutra para ser utilizada como uma ferramenta para a estimativa de quantos pontos serão concluídos na próxima iteração. Na minha opinião, uma velocidade maior ou menor não é necessariamente melhor ou pior.
No entanto velocidade é uma ferramenta importante, se você entender o que ela é e para que ela serve, e pelo que sei, ela serve para o planejamento da próxima iteração, e não para medir produtividade.
Kurt também reconheceu que este não é o único ponto de vista sobre velocidade citando o blog do Little Joe onde Joe afirma:
... que irá dobrar a velocidade da equipe. Em 6 meses ou menos.
Dobrar a velocidade (pontos de história concluídos de fato (done done em cada sprint) geralmente significa que temos de melhorar algumas coisas:
- uma definição mais clara de pronto (ou "pronto é pronto" (done, done) se você preferir). Normalmente deixamos essa definição muito vaga. Essa definição pode variar entre histórias, mas para a maioria das histórias de desenvolvimento de software, ela deve ser muito clara e pode ser consistente. E, na minha opinião, a definição é "nenhum bug [conhecido] ao fim do sprint". E os testes devem incluir, pelo menos, testes funcionais.
- devemos medir velocidade. Eu ainda me surpreendo com o número de equipes que encontro e que não têm medida de velocidade. Falarei mais sobre isso da próxima vez. Por agora: "Velocidade: não saia de casa sem ela."
- temos de priorizar os impedimentos, e continuar eliminando ou reduzindo o impacto dos mesmos até a velocidade dobrar. Dica: Priorizar os impedimentos de acordo com o aumento da velocidade causado pela remoção / redução do impacto. 25% aqui, 30% ali, e logo você estará falando de um verdadeiro aumento da velocidade.
Dica: Melhorar a qualidade e diminuir o débito técnico quase sempre são formas importantes de aumentar a velocidade efetivamente. Não são as únicas formas, mas são muito importantes.
Adam Sokra concordou com Kurt que velocidade é uma má métrica de desempenho, mas defende que a principal utilidade da velocidade é auxiliar no planeamento a longo prazo em vez de no planejamento da próxima iteração:
[A velocidade] é uma métrica de desempenho extremamente ruim, a menos que o uso da mesma seja feito com a intenção de ver como a sua produtividade estabiliza ao longo do tempo. Velocidade tem sido usada para dizer, "Na última iteração concluímos X pontos, então nesta iteração devíamos tentar concluir não mais que X pontos." No entanto, muitos de nós passaram acreditar que esta é uma forma duvidosa de fazer compromissos. Muitos sugerem que nos comprometamos a fazer simplesmente aquilo que pensamos que podemos realizar em cada iteração.
A velocidade é melhor utilizada para planeamento a longo prazo. Eu posso olhar para a minha velocidade ao longo de várias iterações e chegar a uma média (de preferência não um número exato, mas um intervalo.) Então eu posso usar essa informação para responder perguntas como: 1) Dado o backlog atual, aproximadamente quantas iterações serão necessárias para completar um determinado conjunto de histórias? 2) Quantos pontos de história, e por extensão que conjunto de histórias prioritárias, posso entregar até a data X (por exemplo, até a data de determinada exposição?)
E, naturalmente, existe uma escola de pensamento que vem ganhando e acredita que fazer planejamento é um desperdício.
Velocidade deveria ser utilizada como uma métrica de produtividade? Deve ser usada para planejamento de iteração? E para planeamento de longo prazo? Ela deve ser usada de alguma maneira, ou é um desperdício na prática?