Poker Face: a arte das estimativas ágeis

guy-poker-face-mainDesde 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!
Anúncios

Marcelo L. Barros

Olá! Sou um cara criativo, curioso e detalhista, que, cada dia, mais se vê interessado em desvendar os mistérios desse "bicho gente"! Comecei minha carreira profissional em 1996, sou formado em Processamento de Dados pela FATEC de Santos. Naquela época tudo o que eu queria ter na minha frente era um computador e uma desafiadora regra de negócio, que se transformaria no melhor programa possível. Mas as coisas mudam! Concluí que quem faz software com qualidade são as pessoas e não as máquinas. Hoje, minha MISSÃO é ajudar pessoas e times a alcançarem seus objetivos, pois acredito que o sucesso pessoal e profissional está ligado a três pilares: FELICIDADE, MOTIVAÇÃO e SENTIDO. Como faço isso? 💡 MOTIVANDO pessoas, fazendo-as enxergar o 💡 SENTIDO das suas ações, que traz 💡 FELICIDADE por fazerem a diferença em suas vidas, suas empresas. Sou formado em Coaching pelo ICC e escrevo artigos sobre Métodos Ágeis, Comportamento, Inovação e Coaching. Vejo no lúdico a forma mais profunda de aprendizado. Procuro sempre conduzir reuniões de forma criativa, que tragam algum tipo de aprendizado aos participantes, seja por meio de dinâmicas de grupo ou jogos em equipe. Neste quesito, desenvolvi um jogo, a "Feijoada Ágil", para ensinar conceitos sobre trabalho em equipe. Se você, como eu, também acredita que eu posso te ajudar, deixe-me saber! Vamos tomar um café e, quem sabe, juntos podemos MUDAR O MUNDO!

2 comentários

  1. Apenas um comentário que achei pertinente devido a minha realidade aqui.
    Então para o cliente não faz diferença quanto tempo leva cada bolo, desde que os bolos entregues ao final das 6 horas (Sprint), sejam os bolos prometidos.
    Na minha realidade faria sim diferença. Pois cada bolo teria um orçamento diferente, calculado pela quantidade de horas estimadas.
    A solução seria cobrar um valor fechado por Sprint???
    Funcionaria, desde que os Sprints tenham sempre a mesma quantidade de pontos para cada cliente.

  2. Não se esqueça de colocar o esforço necessário junto com a complexidade.

    Algo complexo pode ser resolvido facilmente através de alguma ferramenta/framework. Mas algo simples pode demandar muito esforço.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s