Olá Karina,
1) Você não precisa estimar todo o backlog. Você pode ir pontuando as histórias até passar de 2 ou 3 a mais do que cabe dentro da sprint atual, somente para ter uma margem de erro.
2) Uma coisa importante sobre quando vamos estimar/pontuar uma história é que quase certeza que ela estará errada. A ideia da estimativa no planning é que o P.O. ou o cliente esteja presente nesta hora. Ai conforme o time faz um poker planning, dúvidas sobre a regra de negócio surgirão dado que cada um vai pontuar de uma forma diferente. E o P.O./cliente estando lá já poderão tirar estas dúvidas na hora e explicar de forma mais clara o que precisa ser feito. Assim, ao final da estimativa todo o time estará alinhado sobre o que se trata aquela história, qual a necessidade do seu cliente e o que precisa ser feito.
3) Geralmente registramos num cartão de história, mas que tenha o mínimo de informação possível, como por exemplo aquele trio Para- Como - Quero. Como um dos valores da agilidade é que o cliente esteja sempre presente e disponível, a ideia é que se mesmo depois da reunião surgirem dúvidas da regra de negócio os desenvolvedores sejam forçados a ir atrás e conversar cara a cara com o P.O./cliente sobre a regra de negócio do que ficar lendo uma documentação e abrindo margem para um interpretação de texto errada.