Story Points: Devo usar pontos de história ao invés de horas?

Os Story Points, são unidades de medida, que permitem que a equipe se concentre na complexidade, risco e esforço de uma demanda. O time compara o novo trabalho, com o trabalho feito anteriormente. Diferentemente das horas, onde colocamos em pauta somente o fator tempo.

Por exemplo, não costumamos contabilizar reuniões, e-mails, revisões de código, entre outros, com valores de tempo. Entretanto, todas essas são práticas necessárias ao longo do nosso dia, mas não contam como trabalho.

Os pontos da história isolam o trabalho de desenvolvimento de software dos itens de trabalho logísticos associados. Portanto, as estimativas com base em pontos devem ser mais consistentes do que a abordagem baseada em horas.

“Estudos foram realizados sobre a precisão da estimativa de esforço entre indivíduo e grupo em um experimento para um projeto de software. 20 profissionais de software da mesma empresa estimaram individualmente o esforço de trabalho necessário para implementar o mesmo projeto de desenvolvimento de software.

Os participantes tinham experiências e funções diferentes e o projeto de software já havia sido implementado. Depois disso, eles formaram cinco grupos. Cada grupo concordou com uma estimativa, discutindo e combinando o conhecimento entre eles. Resultado: as estimativas baseadas em discussões em grupo foram mais precisas do que as estimativas individuais.” – (Jorgensen, M)

Por esses e outros fatores, é recomendável o uso de story points no lugar de horas. Exemplificando, imagine que temos as seguintes demandas divididas em Sprints (Time Box dentro do qual um conjunto de atividades deve ser executado):

• Referência

Sprint 1

Temos 2 atividades: A e B. Estimamos, com story points, que a primeira é 1 ponto, a segunda são 2 pontos. E, simplificando bastante, imagine que cada ponto signifique uma mudança de parâmetro. Dessa forma, o time estimou o primeiro item como tendo tamanho 1 por ter um parâmetro, o segundo em tamanho dois por ter 2 parâmetros.

Digamos que, nesse momento, o time leva, em média, 8 horas para terminar um ponto. Isso quer dizer que o time possui 3 pontos para trabalhar as 2 atividades ou 24 horas.

O projeto mantém seu andamento, o time passa pelas atividades A e B, e continua trabalhando. Ele começa a ganhar experiência, e com o andar do projeto ele está 50% mais rápido. Isso quer dizer que agora cada ponto leva 4 horas em vez de 8. E assim seguimos para a 2ª sprint.

Sprint 2

Pegamos pela frente as histórias C e D que também possuem mudanças de 1 e 2 parâmetros. Só que diferente das primeiras atividades, estas não vão levar 1 dia, 2 dias pra terminar, mas 4 horas, 8 horas, já que o time está mais rápido.

Isso significa que o tamanho dela em horas também deve ser menor, mas cuidado, não devemos fazer o de/para em pontos; para que a primeira tenha 0,5 pontos e a segunda 1 ponto.

O número de pontos não mede o tempo para uma história ser feita, mas sim, o tamanho relativo (complexidade, risco e esforço). Havíamos dito que, nesse modelo simplificado, uma história seria o dobro da outra se tivesse o dobro de parâmetros, e isso não mudou. A história D, com duas mudanças de parâmetros, ainda é o dobro do tamanho da história A, que tem apenas uma mudança. 

Se estivéssemos utilizando tempo para estimar o backlog (log de acumulação de trabalho), sempre que a eficiência do time mudasse teríamos que rever a estimativa de todo o restante do projeto. E assim teríamos adaptações constantes derivadas da evolução da demanda.

O único motivo para alterar estimativas feitas com pontos é a alteração de escopo ou mudança no entendimento da atividade.

Ex: O time de negócios informa que agora além da alteração do parâmetro, precisamos alterar um campo (mudança de escopo).

O uso dessa forma faz com que tenhamos uma maior precisão com o passar das sprints se comparados ao método waterfall, é possível medir o capacity do time através de um range mais assertivo, tendo como base os pilares já mencionados de risco, complexidade e esforço.

Planning Poker e a utilização de pontos

O Planning Poker (técnica de estimativa) e a utilização de pontos funcionam como uma abordagem produtiva para estimar histórias do usuário.

O jogo estimula a equipe a discutir cada “user story”, gerando maior compreensão das demandas e projetos, sendo não só agradável para os membros do time — já que conseguem chegar a um consenso de maneira mais eficaz — como também fornece uma visão ampla para a implementação de uma atividade. Já que todos os participantes contribuem para o resultado.

Pensando além, e fugindo um pouco da utopia, será que a utilização de Story Points seria o único meio ideal? Vamos para um caso onde temos uma squad (equipe multidisciplinar pequena) com somente 1 ou 2 desenvolvedores (além do Product Owner e Scrum Master), realmente faz sentido atribuir pontos? A discussão técnica será efetiva na atribuição de pontos?

Podemos também ter casos onde os recursos são divididos em mais de uma squad. Ou seja, o mesmo desenvolvedor (a) está atuando em 2 ou até mesmo 3 squads ao mesmo tempo.

A principal dica é testar e ver o que melhor se adapta à sua equipe! Veja o que faz sentido para seu time: Planning Poker, Horas, T-shirt Sizes, Affinity Mapping, entre outros.

Acredito que, o mais importante é você conseguir adotar um método que gere engajamento e contribuição da equipe e, a partir do andamento das sprints, consiga colher insumos e métricas para debates durante as cerimônias de revisão/retrospectiva com os membros da equipe, sobre entregas e produtividade do time.

E você? Que método utiliza para realizar a estimativa da sua squad?