Estimar ou Não Estimar Histórias de Usuário?

Estimar ou Não Estimar Histórias de Usuário?

Estimar Histórias de Usuário é uma tarefa muito comum em times scrum. Talvez o método mais comum seja o Planning Poker. Mas você já se perguntou porque continua usando esse método de estimativa?

Estimando com Planning Poker

O objetivo do Planning Poker é ter uma estimativa do que cabe dentro de uma Sprint. Certo? E com isso, saber mais ou menos a velocidade do time… E saber quando um projeto vai terminar.

Ou, se a estimativa indicar que não vai terminar a tempo, permitir que o time ou Dono do Produto tomem alguma medida para corrigir o curso.

É por isso que estimamos as histórias de usuário no início de uma sprint. De acordo com Douglas W. Hubbard em How to Measure Anything: Finding the Value of Intangibles in Business, nós medimos ou estimamos alguma coisa para apoiar uma tomada de decisão.

E a decisão que o time toma no início de uma sprint é: “Quais histórias vamos nos comprometer a entregar?“; “Quantas cabem na sprint?“.

Mas você já parou para pensar no custo envolvido para rodar o Planning Poker. Todos os desenvolvedores juntos sem efetivamente gerar valor no produto… Qual o salário de todos (ou todas) somados? Quanto custa 1 hora de reunião desse time?

Um novo olhar sobre estimativas

Olhando com uma lente Lean, estimar histórias de usuário é um custo de coordenação do time.

No livro Kanban do David Anderson, tem uma passagem mais ou menos assim:

Se uma atividade gera valor para o produto, queremos fazer ela mais vezes. Se ela é uma atividade que gera custo, queremos fazer menos dela.

Vista por esta lente, uma seção de Planning Poker é claramente um custo. Fazer mais Planning Poker não traz mais resultados para o produto. Não incrementa o produto…

Se o resultado final dessa estimativa é saber quando um projeto vai terminar, será que não existe outra forma menos custosa de estimar o final de um projeto?

E na verdade, esta outra maneira existe.

A Alternativa para Estimar Histórias de Usuário

Se o time tem WIP limitado e histórias de usuário mais ou menos do mesmo tamanho (na verdade, isso vale para qualquer outra coisa que entre no processo de trabalho do time, não só para histórias de usuário), é possível usar a taxa de entrega em número de histórias para fazer previsões.

E histórias mais ou menos do mesmo tamanho, quer dizer que queremos evitar os ratos e elefantes. Qualquer coisa do entre um cachorro e um camelo está valendo. Alguém disse isso outro dia, não me lembro muito bem quem foi…

O que quer dizer que só precisamos tentar eliminar as histórias muito pequenas e aquelas muito grandes. E com isso, uma estimativa que leve em consideração a taxa de entrega (throughput) vai funcionar.

Recentemente, passei a usar dois métodos para estimar o fim dos projeto. O primeiro usando algo parecido com uma regressão linear e o segundo usando simulações de Monte Carlo.

Um bom começo para aprender um pouco sobre isso é um post da Plataformatec. Conheci o Raphael Albino no Lean Kanban Brasil 2017, troquei umas ideias e comecei a fazer uns experimentos…

O post é esse Por que usamos Simulações de Monte Carlo para gerenciar projetos.

E aí qual a sua experiência com estimativas? Deixa seu comentário aí embaixo.

%d blogueiros gostam disto: