O que são Story Points?

Story Points são uma unidade de medida para estimar o esforço total necessário para implementar completamente um item do Product Backlog ou outro trabalho.

Quando estimamos algo com Story Points, atribuímos a cada item uma determinada pontuação. Os valores absolutos não são o mais importante. O que importa são os valores relativos. Uma story estimada com 1 ponto deve ter metade do tamanho de uma story estimada com 2 pontos. Uma story com 3 pontos deve, portanto, ser três vezes maior que a story com 1 ponto.

Em vez de usar valores como 1, 2 ou 3, uma equipe também poderia atribuir 100, 200 e 300 pontos – ou 1 milhão, 2 milhões e 3 milhões. O que importa é apenas a relação entre os números, não os números em si.

Quais fatores entram na estimativa com Story Points?

Como Story Points representam o esforço de desenvolvimento de uma Story, tudo que possa influenciar esse esforço deve entrar na estimativa da equipe, como por exemplo:

• A quantidade de trabalho a ser feito
• A complexidade desse trabalho
• Quaisquer riscos ou incertezas na realização desse trabalho

Ao fazer uma estimativa com Story Points, você deve considerar cada um desses fatores. Vamos ver juntos como cada fator pode influenciar a estimativa de esforço.

A quantidade de trabalho a ser feito

Quando há muito a fazer, naturalmente a estimativa de esforço deve ser maior. Vamos imaginar que estamos desenvolvendo duas páginas web. A primeira página tem apenas um campo e um rótulo para inserir um nome. A segunda página tem 100 campos que também precisam ser preenchidos com um pouco de texto.

A segunda página não é mais complexa que a primeira. Não há interação entre os campos individuais e cada um consiste apenas em um pouco de texto. Não há riscos adicionais nessa segunda página. A única diferença entre as duas páginas é que na segunda há mais trabalho.

A segunda página deve, portanto, receber mais Story Points. Embora tenha aproximadamente 100 campos a mais, a página não recebe necessariamente 100 vezes mais pontos. Efeitos de escala fazem com que a página represente apenas duas, três ou 10 vezes mais esforço que a primeira página.

Risco e incerteza

Os riscos e a incerteza de um determinado Product Backlog Item devem influenciar a estimativa do item.

Quando uma equipe é solicitada a fazer uma estimativa para um Product Backlog Item, e o stakeholder que fez o pedido não consegue dizer exatamente o que precisa, essa incerteza deve se refletir na estimativa.

Complexidade

A complexidade também deve ser considerada em uma estimativa com Story Points. Pense novamente no exemplo da página web com 100 campos de texto simples, sem nenhuma interação entre eles.

Agora vamos imaginar outra página web com 100 campos. No entanto, alguns deles são destinados a inserir datas, onde uma visualização de calendário deve se abrir. Alguns desses campos são campos de texto formatados para números de telefone ou números de seguro social. Outros campos realizam validação de soma de verificação para, por exemplo, números de cartão de crédito.

Nessa tela são necessárias interações entre os campos individuais. Se um usuário indica um cartão Visa como cartão de crédito, um campo CVV de três dígitos para o código de verificação do cartão é exibido.

Mesmo que ainda existam apenas 100 campos nessa página, eles são mais difíceis de implementar porque são mais complexos e, portanto, exigem mais tempo. Além disso, aqui a probabilidade de um desenvolvedor cometer um erro e precisar corrigi-lo posteriormente é maior.

Essa complexidade adicional deve se refletir nas estimativas.

Considere todos os fatores!

Pode parecer impossível representar três fatores diferentes com um único número e fazer uma estimativa com ele. Mas é realmente possível, porque existe um fator que une todos os outros – o esforço. Aqueles que fazem uma estimativa consideram quanto esforço será necessário para realizar a quantidade de trabalho descrita por um Product Backlog Item.

Eles consideram quanto esforço será necessário para lidar com os riscos e a incerteza desse Product Backlog Item. Normalmente isso é feito ponderando os riscos de um problema ocorrer e seus potenciais impactos. Uma estimativa será, por exemplo, mais alta para um risco que consome tempo e também é muito provável do que para um risco menor e menos provável.

Além disso, a complexidade do trabalho a ser feito é considerada. Trabalhos complexos podem exigir reflexões mais cuidadosas, experimentação por tentativa e erro e mais troca com o cliente. Talvez a validação também demore mais e seja necessário mais tempo para corrigir erros.

Por isso, todos os três fatores devem ser combinados.

O conceito de Story Points

Uma estimativa com Story Points deve incluir tudo o que é necessário para definir um Product Backlog Item como done. Se a Definition of Done de uma equipe exige a criação de testes automatizados para validação de uma Story (o que seria uma boa ideia), então o esforço para esses testes deve entrar na estimativa.
Compreender o conceito de Story Points em sua totalidade pode ser bastante difícil. Mas valerá a pena entender que pontos representam esforço e que esse esforço é influenciado pela quantidade de trabalho, complexidade e riscos ou incertezas de um Product Backlog Item.