Poker Face: a arte das estimativas ágeis

Desde que alguém decidiu fazer projetos, estimar seu tamanho é o primeiro grande desafio a enfrentar. O desafio não é menor para times ágeis, pois existem muitos que fazem as estimativas das suas user stories de modo que o compromisso do time desvie do valor da entrega.

Há times que estimam user stories diretamente em tempo, mas, se o primeiro dos Princípios Ágeis diz que a prioridade do time é “satisfazer o cliente, através da entrega contínua e adiantada de software com valor agregado” e se o sprint tem um timebox fixo para que isso aconteça, por que diabos o time deveria se preocupar com o tempo gasto em cada uma das user stories?

Há times que estimam usando as cartas do planning poker, atribuindo pontos para cada US, com a finalidade de descobrir a quantidade de pontos que o time é capaz de entregar em uma sprint. Mas qual é o critério usado neste tipo de estimativa? Se o time não define o critério de pontuação, este pode ser qualquer um, e pode variar de uma sprint a outra, pior, de uma pessoa pra outra. Como você consegue determinar a velocidade do time se o seu critério varia de acordo com as condições climáticas?

Há ainda times que fazem uma correspondência entre pontos e horas. Sinceramente, acho que fazer esta correspondência é o mesmo que estar de dieta e comer cinco pedaços de bolo de chocolate só por que está escrito na embalagem que é light. O time tem a impressão de que não está se comprometendo com o tempo das histórias individuais, mas o Daily Meeting vira um relatório de status do projeto.

Estimar tempo favorece a Síndrome do Estudante e a tendência natural é que se coloque a famosa “gordura” na estimativa: só pro caso de algo dar errado… Mas o fato é que é bem provável que você tenha a impressão de que seu time poderia fazer mais na sprint. E o objetivo pulou do valor agregado para entregar a história no tempo exato estimado. E como melhorar a velocidade e performance do time neste cenário?

Recentemente fiz um Agile Workout com alguns times e é isso que quero compartilhar com o leitor.

Agile Workout: estimando como o Cake Boss

Suponhamos que, a partir de agora, trabalhamos na Carlo’s Bakery, como ajudantes do confeiteiro celebridade Buddy Valastro. Temos que entregar produtos para a serem vendidos a cada 6 horas. Para facilitar nosso exercício, consideraremos que temos todas as condições ideais para realizar nosso trabalho, inclusive fornos para assar bolos simultaneamente.

Nosso primeiro trabalho é fazer um bolo simples, esses bolos de avó. Simples? Conseguimos entregar este bolo em 6 horas?

Além desse bolo simples, temos que entregar também um bolo simples, mas recheado. Temos que cortar o bolo exatamente ao meio, colocar o recheio e colocar de volta a parte superior. É simples? E se comparássemos a complexidade deste trabalho com anterior? Em relação ao bolo simples de avó, o quão mais complexo é fazer um bolo recheado? A complexidade é alta, média ou baixa? Conseguimos entregar estes dois bolos em 6 horas?

Agora, uma encomenda especial: um bolo de aniversário pequeno! É necessário preparar o bolo, abrir, rechear, cobrir e escrever “Felicidades” em cima. Temos recheio e cobertura prontos (condições ideais, lembra?). Em relação ao bolo simples de avó, o quão mais complexo é fazer o bolo de aniversário? Conseguimos entregar estes três bolos em 6 horas?

Vamos colocar um pouco de desafio, agora! Recebemos a encomenda de um bolo de casamento! Oito andares! Flores de açúcar! Noivinhos no topo! Ok, mas, como eu disse, temos as condições ideais. As flores de açúcar estão prontas. Mas só!

Agora complicou! Só que não!

Estimando com arte e poker face

Suponhamos que, usando as cartas do planning poker, o bolo simples de avó vale 2 pontos. Vamos estimar novamente a complexidade do nosso trabalho:

• Em relação ao bolo simples de avó, que vale 2 pontos, o quão mais complexo, em pontos, é fazer um bolo recheado?
• Em relação ao bolo simples de avó, que vale 2 pontos, o quão mais complexo, em pontos, é fazer um bolo de aniversário?
• Em relação ao bolo simples de avó, que vale 2 pontos, o quão mais complexo, em pontos, é fazer um bolo de casamento de oito andares?

Pontuamos nossas “user stories” sempre baseadas em um referencial, para fazermos uma comparação de complexidade. Feito isso, temos, enquanto time, que decidir o que cabe ou não em nossa “sprint” de 6 horas.

Provavelmente, o bolo simples de avó, o bolo recheado e o bolo de aniversário caibam nas 6 horas que temos disponíveis. Talvez o bolo de casamento seja um pouco demais pra a capacidade do time. E este é o compromisso que o time vai assumir. Este é o objetivo da “sprint”, que ficará acordado com o “Product Owner”:

Entregar um bolo simples de avó, um bolo recheado e um bolo de aniversário. 

E se sobrar tempo? o que o time faz? Mais bolos recheados? Não!!! O Product Owner não pediu mais bolos recheados! Abrimos novamente o bolo e colocamos mais recheio? Também não! Podemos começar a adiantar o trabalho do bolo de casamento e, provavelmente, conseguiremos, como time, nos comprometer a entregá-lo na próxima sprint!

Mas por que começamos com 2 pontos para o bolo simples de avó? Ora! Enquanto confeiteiros, pode ser que um dia, alguém nos peça para fazer um brigadeiro! Que é um trabalho mais simples do que fazer um bolo!

E qual foi a pontuação encontrada para o bolo de casamento? Sabemos que hoje, o time não consegue se comprometer com uma user story com esta complexidade. É um exercício de estimativa descobrir qual é a quantidade de pontos máxima que o time consegue se comprometer.

Palavra de Confeiteiro Ágil

Repare que, em momento algum, nos comprometemos a fazer um bolo em x horas. Simplesmente por que, para o Product Owner, isso não importa! O que ele quer é ter bolos para vender! Fechado o compromisso com o time, ele sabe exatamente quantos bolos terá ao final da sprint.

Uma última dica: estimule a melhoria da performance do seu time! Aprenda sempre com os trabalhos das sprints! Assim, um dia, vocês chegarão à conclusão de que o bolo recheado pode passar a ser o seu referencial e valer 2 pontos. Isso é melhoria contínua!

Agradecimento muito especial aos times Rise e Quake e ao amigo João Reis que me trouxeram os insights que resultaram neste artigo!

Publicidade