Por que usar “story points”?

*Artigo de Rodrigo de Toledo

Usar pontos ou horas é uma discussão recorrente quando se adota métodos ágeis. Por isso decidi escrever um artigo sobre o assunto que pode ser baixado aqui. Nesse artigo eu relembrando os porquês de estimar e explico o sistema de pontuação Fibonacci. 

Medir tamanho/esforço e não tempo traz diversas vantagens listadas abaixo. Vale lembrar que também é possível ser ágil usando medidas de tempo, como Homem-Dia (HDia) para classificar o custo das suas stories e, para tentar ser imparcial, listo algumas desvantagens do uso de pontos.

(Todos os itens abaixo são discutidos em detalhes no artigo)

1.    Vantagens do uso de Story Points

1.1.        Foco em estimativa relativa

Para o ser humano, é muito mais intuitivo fazer estimativas relativas do que absolutas.

1.2.        Performances individuais diferentes

Um problema inerente do uso de Homem-Dia é que essa medida depende do desempenho de quem é esse homem que está executando a tarefa.

1.3.        Foco em tamanho/esforço e não em duração

É natural pensar primeiro em tamanho (do esforço) para depois se calcular tempo. Mas na nossa área, as pessoas perguntam e respondem em medida de tempo sem ser criterioso com o esforço. 

1.4.        Usar HDia sempre leva a um fator de ajuste

Quando se usa medida de tempo em HDia ou acaba-se por contar com um dia cheio de trabalho o que de fato não acontece. Obrigatoriamente é necessário fazer um ajuste, calcular um percentual pelo qual você deve multiplicar seu HDia real em HDia produtivo.

1.5.        Com HDia a aceleração da equipe pode ficar mascarada

Observe que à medida que o seu time vai ganhando experiência no projeto, tarefas de esforço similares tendem a diminuir o tempo necessário para a execução. Caso a opção seja usar HDia, o resultado é uma diminuição na estimativa em horas de novas tarefas e o ganho de produtividade não ficará explícito.

1.6.        Entrada de novo membro na equipe

Quando uma pessoa nova chega ao time, é normal que ela leve um tempo para render o seu máximo. Com HDia há um aumento irreal de produtividade prevista para o time, pois aumenta-se o número de horas trabalhadas. 

1.7.        Evita-se pressões externas sobre as estimativas

É natural que em algum momento as estimativas das stories de um determinado projeto sejam apresentadas a alguém externo, como um diretor ou mesmo o product owner. Caso as estimativas estejam em HDia, se deixa uma margem para discussão podendo sofrer uma pressão para diminuir os prazos (que pode levar a uma queda da qualidade). Com o uso de pontos cria-se uma blindagem! Mesmo que haja pressão para baixar os pontos estimados, como a referência de pontuação é flexível, a conseqüência é apenas uma alteração nessa referência que será refletida na velocidade do time medida também em pontos. Ou seja, o time vai continuar tendo a mesma taxa de entrega de funcionalidades sem perda de qualidade, apenas o número de pontos entregues fica alterado.

 1.8.        Lei de Parkson

A lei de Parkson, escrita originalmente em 1957 por C. N. Parkinson [11], é um problema clássico no gerenciamento de pessoas. A lei sentencia que “o trabalho se expande para preencher o tempo disponível para sua realização”. Ou seja, se você der 5 dias para uma pessoa realizar uma tarefa ela será realizada no tempo estipulado, mesmo se pudesse ter sido feita em 1 dia. Isso acontece como resultado de duas possíveis situações: (i) atraso no início da realização, também conhecido como síndrome do estudante, pois o executor supõe poder concluir a tarefa apenas nos últimos dias; (ii) a tarefa é realizada quase toda no início do prazo, mas o executor estica a sua entrega para poder caprichar em detalhes nem sempre úteis ou mesmo para poder fazer outras tarefas paralelas. A lei de Parkson pode ser evitada se usarmos pontos ao invés de dias nas estimativas, pois se desacopla a execução de uma story a uma data exata de término (apenas a sprint tem data para terminar)! É claro que ela também poder ser evitada em times altamente comprometidos e cujas tarefas estejam bastante claras na sua descrição (especialmente em termos de requisitos de qualidade).

1.9.        A aritmética é fácil

É apenas uma conseqüência menos importante. Somar story points é muito mais simples que somar horas, minutos ou dias. Mas nada que uma planilha Excel não resolvesse…

 

2.    Desvantagens do uso de story points

Como tudo na vida, adotar story points não traz somente benefícios, eles também apresentam alguns prejuízos.

2.1.        Medida não universal

Medir em pontos é uma coisa muito particular e subjetiva, o seu significado acaba fazendo sentido apenas para um time em um determinado projeto. Portanto, não se está prometendo aqui uma medida universal ou um metro quadrado mágico para a indústria de software.

2.2.        Desconforto inicial de alguns

De fato, story points são menos palpáveis que medidas de tempo. Então, pode ser difícil convencer algumas pessoas. Especialmente porque todos sabem que ao final os pontos vão se transformar em estimativas de tempo. No entanto, usando story points, após algumas poucas sprints cria-se uma noção intuitiva de pontos.

 

3.    Conclusão

Usar story points é muito bom, mas fazer Agile continua sendo muito bom, mesmo sem story points.  Existem muitas discussões em torno deste assunto, espero estar contribuindo para resolver algumas dúvidas que tenho visto surgir no dia-a-dia de quem está implantando métodos ágeis.

 

Sobre o Autor:

Rodrigo de Toledo

Rodrigo de Toledo é graduado e mestre pela PUC-Rio e PhD pelo INRIA na França.

Na área acadêmica, tem diversos artigos internacionais em computação gráfica e lecionou por alguns anos na PUC-Rio. 
Rodrigo trabalhou por dez anos no Tecgraf onde desempenhou por um ano o papel de Scrum Master.
Atualmente é engenheiro de software na Petrobras onde atua também como Product Owner, além de se dedicar à divulgação dos métodos ágeis.