Sem estimativas do Sprint Backlog com Task Points

Quando escrevi o livro Agile Estimating and Planning em 2005, já tinha cinco anos de experiência com diferentes métodos de estimativa. Depois de fazer experimentos com algumas equipes – especialmente com aquelas que trabalhavam diretamente comigo – senti que tinha aprendido o suficiente para poder escrever o livro.

No entanto, ainda havia muita coisa que eu não sabia (e claro que ainda há!). Por isso, procurei equipes que estimavam e planejavam seus projetos de forma diferente da minha. Algumas dessas equipes usavam Task Points além de Story Points para estimar seus Product Backlog Items.

Achei isso interessante. Naquela época, eu já era um defensor dos Story Points – e desde então me tornei um fã ainda maior devido às vantagens dos Story Points. No entanto, simplesmente não conseguia entender por que uma equipe usaria Task Points. Mas como era um grande fã de Story Points, quis descobrir mais sobre as equipes que trabalhavam com Task Points.

Consegui convencer algumas equipes a me deixarem observá-las, para poder aprender mais sobre isso.

O que descobri confirmou minha suposição de que as equipes não deveriam avaliar seus Sprint Backlog Items com Task Points.

A principal vantagem dos Story Points

A principal vantagem dos Story Points é que pessoas com as mais diversas habilidades, níveis de experiência e diferentes contextos podem fazer uma estimativa conjunta para o seu trabalho.

Vamos usar um exemplo um pouco divertido e imaginar que eu quisesse estimar, junto com um polvo, quanto esforço seria necessário para lavar meu carro.

Um polvo tem quatro vezes mais braços do que eu. Então, o polvo deveria conseguir lavar meu carro quatro vezes mais rápido do que eu. (Eu avisei que esse exemplo não era para ser levado totalmente a sério. Mas espere só.)

Porém, o polvo também vai conseguir lavar qualquer outro carro quatro vezes mais rápido do que eu. Então, o polvo e eu podemos talvez concordar que meu pequeno carro de dois lugares recebe cerca de cinco Story Points e um carro um pouco maior recebe dez pontos.

Os Story Points permitem, portanto, que o polvo e eu cheguemos juntos a um acordo sobre uma certa quantidade de pontos – mesmo que o polvo seja certamente muito mais rápido do que eu.

Pontos de Tarefa

Nas equipes que observei, percebi que um Task Point era quase a mesma coisa que um Story Point. No entanto, todas as equipes com quem conversei queriam usar uma unidade menor que Story Points.

Por exemplo, uma equipe que conclui dez Story Points por Sprint poderia alcançar cerca de 80 Task Points por Sprint.

As equipes simplesmente queriam uma unidade menor e mais refinada para acompanhar melhor seu progresso. É parecido com um velocímetro que mostrasse a velocidade em anos-luz por hora. Dessa forma, seria difícil saber se estou respeitando o limite de velocidade ou não.

Usar unidades mais refinadas foi uma boa ideia para muitas equipes. Afinal, é bastante difícil medir o progresso diário com Story Points quando uma equipe conclui, por exemplo, sete Story Points em duas semanas. Nesse caso, Story Points são simplesmente uma unidade grande demais para ser útil.

O que acontece com as horas?

Mas já existe uma unidade mais precisa, com a qual cada membro da equipe já está familiarizado: horas.

Quando observei as equipes estimando com Task Points, percebi que isso não traz nenhuma vantagem comparado à estimativa de itens do Sprint Backlog em horas.

Existe uma diferença fundamental entre itens do Product Backlog (geralmente na forma de User Stories) e Tasks do Sprint Backlog: em um item do Product Backlog normalmente trabalham três a cinco pessoas; talvez um ou dois programadores, um testador e eventualmente um designer, arquiteto, analista ou redator técnico etc. Em uma Task normalmente trabalha apenas uma única pessoa.

Isso significa que nem todos os membros de uma equipe precisam dar uma estimativa conjunta para uma Task, como seria o caso de um item do Product Backlog. Todos na equipe têm a possibilidade de dar uma estimativa para a Task, mas apenas quem vai trabalhar nela no final pode fazer a estimativa definitiva.

Se muito provavelmente apenas uma pessoa específica vai trabalhar em uma Task, então deve-se usar a estimativa dessa pessoa para a tarefa. Se duas ou três pessoas vão trabalhar em uma Task, ou se deixa todas as três darem uma estimativa conjunta ou se usa a estimativa da pessoa que mais provavelmente vai realizar o trabalho.

Se o trabalho for passado para outra pessoa durante o Sprint, na pior das hipóteses as estimativas simplesmente vão mudar. Se um membro da equipe mais rápido assumir o trabalho de um colega mais lento, ele muda a estimativa de oito para quatro pontos – ou vice-versa.

Por que não usar Task Points?

Task Points não têm vantagens em relação a horas. No entanto, têm desvantagens em comparação com Story Points:
- Muitos membros da equipe não estão familiarizados com eles.
- É necessário ter valores de referência para que as estimativas possam ser feitas.
- Existe o risco de que as estimativas, com o tempo, deixem de se orientar pelos valores de referência originais.

Minha dica para lidar com Task Points

Encerrei minha incursão no mundo dos Task Points sem que conseguissem me convencer do seu valor. Continuo sendo um defensor do Sprint Planning orientado a compromisso, como o conhecemos. Talvez planejamento de Sprint orientado à capacidade seja uma denominação melhor para isso. Na minha opinião, ele tem vantagens consideráveis em relação ao Sprint Planning orientado a velocity.

Na maioria das equipes, o Sprint Planning orientado a compromisso ou capacidade funciona melhor com horas. Algumas equipes seguem esse processo, mas deixam as estimativas de lado e as utilizam apenas em reuniões para descobrir o que podem incluir no Sprint.

Outras equipes simplesmente não estimam os itens do Sprint Backlog. Qualquer uma dessas abordagens pode funcionar bem quando uma equipe já tem experiência com ela.

Fico feliz por ter realizado esse projeto para descobrir mais sobre Task Points e as equipes que os utilizam.

Quando analiso métodos alternativos de estimativa, sempre fico um pouco decepcionado quando uma nova abordagem não é melhor do que uma existente. Mas infelizmente isso acontece com bastante frequência.

E ainda assim encontraremos as melhorias contínuas que todo agilista busca, se considerarmos o maior número possível de opções diferentes.

Este texto é do Blog de Mike Cohn e foi traduzido por nós para o português. 

Product Owner: Tarefas & Desafios

=> Descobre o que um Product Owner faz durante o dia todo.

O que é uma Scrum Story?

=> Aqui você encontra as diferenças entre User Stories, Epics e Themes.