Oi Bruno,
a ideia é bem essa que o Alberto falou. No começo do projeto, como existe muita incerteza e as vezes o time também não tem maturidade com agilidade, o time vai pontuar sem nenhuma precisão. Inclusive no início ainda nem sabemos quanto o time produz de verdade, então até mesmo isso precisamos chutar. Com o passar do tempo as estimativas começam a ficar cada vez mais precisas. E geralmente a retrospectiva é o melhor momento para puxar estas discussões que o Alberto levantou de como melhorar a capacidade do time, melhorar as estimativas, etc
Quanto a sua dúvida de quando devemos estimar, se é na hora de definir o sprint backlog ou se a história já tem que ser elaborada com o esforço, em geral pontuamos no planning mesmo. Um fluxo que nós gostamos de adotar durante o planning é o seguinte:
1) o P.O. pega a história mais prioritária neste instante no Product Backlog e apresenta para o time
2) Desenvolvedores discutem história apresentada tecnicamente
3) Se necessário, desenvolvedores quebram a história em tarefas técnicas
4) Devs estimam o esforço para toda a história (evite pontuar as tarefas técnicas se não o planning leva uma vida)
5) adiciona a história no sprint backlog e repete todo esse processo para a próxima história, até passar de umas 2 ou 3 histórias do que o time acredita que consegue entregar nesta sprint.
Geralmente pegamos 2 ou 3 histórias a mais para ter uma margem de erro se estimarmos errado as histórias achando que elas eram mais difíceis do que realmente são. Mas já tem que ficar claro também com o P.O. que estas 2 ou 3 histórias são extras.
