Planejamento de Sprint orientado a compromisso (vantagens em relação à Velocity)
Já expliquei duas abordagens alternativas para o Sprint Planning:
Agora gostaria de explicar por que prefiro o Sprint Planning orientado por commitment. Mas antes, uma breve explicação dos dois conceitos.
Resumo das duas abordagens de Sprint Planning
No Sprint Planning orientado por velocity, a equipe seleciona uma série de Product Backlog Items cuja estimativa (geralmente em Story Points ou dias ideais) corresponde à velocity média da equipe. No Sprint Planning orientado por commitment, a equipe analisa um Product Backlog Item de cada vez e estima aproximadamente quais e quantas Tasks (tarefas) estarão envolvidas. Isso continua até que os membros da equipe sintam que o Sprint está cheio. Como "Commitment" é frequentemente mal interpretado como "garantia", essa abordagem também é cada vez mais chamada de "Planejamento baseado em capacidade".
A Velocity do Sprint pode variar
Um olhar no diagrama a seguir ajuda a entender minha preferência pela abordagem orientada por commitment. Ele mostra a velocity de uma equipe ao longo de nove Sprints consecutivos. Nota-se imediatamente que a velocity não é estável. Ela é diferente em cada Sprint.
A primeira grande desvantagem do Sprint Planning orientado por velocity é que a Velocity como medida é muito imprecisa. Por isso, não é confiável o suficiente para planejamento de curto prazo (por exemplo, um Sprint). Na prática, a Velocity varia em até 20 por cento. Por isso, é completamente normal que uma equipe com uma velocity real de 20 tenha uma velocity de 16 ou 24 em Sprints individuais. Parece então que a equipe realizou mais ou menos trabalho nesses Sprints. E isso certamente se aplica a algumas equipes.
Essa variação também se deve em parte às unidades imprecisas usadas para estimar os Product Backlog Items. A maioria das equipes que trabalha com Story Points usa valores predefinidos como a sequência de Fibonacci (1, 2, 3, 5, 8, 13) ou simples duplicação (1, 2, 4, 8, 16). Se uma equipe trabalha com a sequência de Fibonacci e afirma ter completado uma story de cinco pontos, na realidade pode ter completado apenas uma story de quatro pontos. A velocity é assim superestimada relativamente rápido. A longo prazo, isso não é um problema, pois a lei dos grandes números cria um equilíbrio. A curto prazo, no entanto, pode causar problemas.
O efeito de ancoragem do Sprint Planning orientado por velocity
Outro problema com o Sprint Planning orientado por velocity é o efeito de ancoragem. Nesse efeito, as estimativas são fortemente influenciadas por informações anteriores. Bons exemplos disso existem especialmente na época pré-natalícia. Imagine que você entra numa loja e encontra uma jaqueta que gosta muito. A etiqueta de preço mostra um preço original de 400 euros. Mas esse está riscado e o novo preço é 200 euros. Seu cérebro pensará automaticamente: "Ótimo, uma jaqueta no valor de 400 euros por apenas 200 euros!" E é exatamente por isso que o preço original é indicado. Na verdade, não importa quanto a jaqueta custava antes. Agora ela custa 200 euros e isso é a única coisa que deveria influenciar sua decisão de compra. Mas uma vez que o preço de 400 euros está ancorado na sua cabeça, é difícil ignorá-lo. Ele inevitavelmente faz você pensar que a jaqueta por 200 euros é uma pechincha.
O efeito de ancoragem e o Sprint Planning orientado por velocity
Mas o que o efeito de ancoragem tem a ver com Sprint Planning? Tomemos como exemplo uma equipe Scrum numa reunião de Sprint Planning. Já foram selecionadas stories que correspondem à velocity média. Os membros da equipe então consideram se essa é a quantidade certa de trabalho. (Como descrito no artigo sobre Sprint Planning orientado por velocity, identificar e estimar Tasks também é útil.) Uma equipe que trabalha com a abordagem orientada por velocity dirá mais frequentemente de forma precipitada "Sim, conseguimos fazer isso!", mesmo que na realidade não consiga completar o trabalho. Afinal, os membros da equipe sabem que a quantidade de trabalho selecionada corresponde à sua velocity média e assim sua estimativa é influenciada. Seria como se eu mostrasse a jaqueta e você pudesse ver a etiqueta de preço com os 400 euros.
Se eu perguntar agora: "Quanto você acha que custa esta jaqueta?", você certamente mencionará um valor (pelo menos aproximadamente) na faixa de 400 euros, porque ele se ancorou na sua cabeça. Devido a esse efeito de ancoragem, uma equipe com uma velocity média de 20 provavelmente dirá que um Sprint foi preenchido com exatamente 20 pontos – mesmo que o trabalho seja na verdade de 16 ou 24 pontos. Isso pode levar algumas equipes a ocasionalmente realizarem menos trabalho do que seria possível. Ou uma equipe assume trabalho demais. Frequentemente, nesses casos, um ou outro item é descartado em vez de adicionado.
Velocity no planejamento de longo prazo
Você provavelmente acredita agora que sou geralmente contra o Sprint Planning orientado por velocity. Mas isso não é bem verdade. Considero essa abordagem inadequada para o planejamento de Sprints individuais. Para planejamento de longo prazo, no entanto, acho-a muito adequada. A Velocity simplesmente varia demais para ser útil no planejamento de curto prazo.
Para ilustrar isso, imagine que você trabalha num lava-rápido. No início do seu primeiro dia de trabalho, seu chefe diz que você tem uma meta a cumprir: por hora você deve lavar quatro carros. No final da primeira hora, você só conseguiu lavar três carros. Você deveria ser demitido por isso? Claro que não. Afinal, foi apenas uma hora e talvez você tenha lavado três carros grandes. Talvez o tempo estivesse ruim e apenas três pessoas trouxeram seus carros para lavar. No final do primeiro dia de trabalho (oito horas), você deveria ter lavado 32 carros. Mas você lavou apenas 30. Isso é motivo para demiti-lo? Na verdade, ainda não. E no final do primeiro mês? Considerando 20 dias e 32 carros por dia, você deveria ter lavado 640 carros. Seu chefe vai demiti-lo se você só conseguiu 600 carros? Talvez ainda não, mas está começando a ficar evidente que você não consegue cumprir a meta – mesmo que seja a mesma proporção de lavar 30 em vez de 32 carros por dia. E se você continuar assim o ano todo? Se a meta foi bem pensada – e todos os outros funcionários a cumprem – seu chefe talvez devesse demiti-lo (ou tentar lidar de outra forma com sua produtividade mais baixa, mas esse não é o ponto aqui).
Com essa meta não é diferente da Velocity: ambas fazem sentido para um período mais longo. O que diria sobre a gestão da empresa se um novo funcionário fosse demitido após apenas uma hora porque não conseguiu cumprir a meta? Então cada funcionário certamente teria que ser demitido após no máximo três dias. Essa meta é mais adequada para períodos a partir de um mês do que para poucas horas. Da mesma forma, a Velocity é mais adequada para períodos mais longos. Quando uma equipe tem 30 Product Backlog Items para entregar, pode assim estimar bem quanto tempo precisará para cada item individual e quando terminará tudo. Uma equipe com apenas três Product Backlog Items deveria, no entanto, trabalhar com a tradicional divisão dos items em Tasks menores.
Devo mudar para Sprint Planning orientado por commitment?
Se você já trabalha com Sprint Planning orientado por velocity e com sucesso, então continue assim. Se sua equipe acabou de conhecer o Scrum ou notou alguns dos problemas mencionados, então o Sprint Planning orientado por commitment seria provavelmente a melhor escolha.
