O principal benefício dos Story Points no Scrum
Se Story Points são uma unidade de medida para tempo (esforço), por que não usar diretamente horas ou dias? Por que precisamos de Story Points afinal?
A principal razão para Story Points
Product Backlog Items com Story Points traz várias vantagens. No entanto, existe uma razão principal que já é suficiente para justificar o uso de Story Points. E isso tem a ver com o Rei Henrique I, que reinou de 1100 a 1135. Antes do seu reinado, existia a medida de comprimento "yard", que correspondia à distância entre o polegar esticado e o nariz de uma pessoa. Imagina só a confusão que isso causava. Afinal, essa distância era diferente para cada pessoa. Um dia, o Rei Henrique decidiu que um yard passaria a ser sempre igual à distância entre o seu polegar esticado e o seu nariz.
Isso foi prático para ele. Mas também para todos os outros, porque agora existia uma unidade de medida definida. Para cada pessoa individualmente, isso significava que um yard (o comprimento do braço do rei) talvez fosse um pouco mais longo ou mais curto do que o seu próprio braço. Assim, todos passaram a ter uma unidade de comprimento uniforme.
Estimativa Relativa com Story Points
Com Story Points é a mesma coisa. Assim como as jardas inglesas, os Story Points permitem que membros da equipe com diferentes qualificações façam juntos uma estimativa relativa.
Podemos usar outro exemplo: imagine que você quer correr com alguém. Você corre num ritmo relativamente alto, mas a outra pessoa é mais lenta. Você aponta para um caminho e diz: "Vamos por este caminho, vamos precisar de 30 minutos." Mas seu parceiro de corrida, cada vez que correu esse caminho no ritmo dele, precisou de 60 minutos e te diz isso. Então vocês discutem: "30". "60". "30". "60". Mas isso também não leva a lugar nenhum. Vocês poderiam fazer um acordo e combinar 45 minutos. Mas essa seria a pior coisa que poderiam fazer, porque agora vocês deram uma estimativa que não se aplica a nenhum dos dois. Então, em vez de concordar com 45 minutos, vocês voltam a discutir: "30". "60". "30". "60".
Em algum momento você diz ao seu parceiro de corrida: "Ok, o caminho tem 5 KM. Eu corro em 30 minutos." E ele responde: "É verdade, o caminho tem 5 KM. Mas eu preciso de 60 minutos para isso."
O problema é que vocês dois têm razão. Você realmente consegue correr o caminho em 30 minutos, mas seu parceiro em 60 minutos. Dar uma estimativa conjunta não vai funcionar, já que vocês dois trabalham ou correm em velocidades diferentes.
No entanto, se usarmos uma unidade de medida mais abstrata – aqui quilômetros – é possível chegar a um acordo. Vocês concordam que o caminho tem 5 quilômetros. A única diferença é quanto tempo cada um precisa para percorrê-lo.
Conclusão – Consenso com diferentes velocidades de trabalho
Story Points cumprem o mesmo propósito. Com a ajuda deles, pessoas que têm diferentes habilidades e velocidades de trabalho podem chegar a um consenso. Em vez de um corredor mais lento e um mais rápido – como no exemplo acima – você também pode imaginar dois programadores com produtividades diferentes:
Assim como os corredores, os programadores podem concordar que uma determinada User Story recebe 5 Story Points (em vez de 5 KM). O mais rápido dos dois programadores talvez pense que é apenas um dia de trabalho para ele. O um pouco mais lento, por outro lado, acredita que vai precisar de dois dias. Mesmo assim, eles podem concordar com 5 Story Points, já que o número de Points na primeira Story ainda pode ser escolhido livremente.
A partir dessa primeira estimativa, todas as outras para as Stories seguintes podem ser derivadas. Se o mais rápido dos dois assumir que vai precisar de dois dias para a próxima Story (o dobro do tempo da primeira), então ele dá a essa Story 10 Points. O programador mais lento talvez pense que vai precisar de quatro dias (também o dobro do tempo da primeira), então ele também dá 10 Points.
E assim os Story Points ajudam – exatamente como o comprimento do braço na história do Rei Henrique – pessoas diferentes a chegarem a um consenso.
Este texto foi retirado do blog de Mike Cohn e foi traduzido por nós para o alemão.
Criar estratégia de produto
Planning Poker
=> O Momento Certo para Planning Poker
