Measuring scale for story points in Scrum framework

According to this Scrum article:

Story points are relative values that do not translate directly into a specific number of hours. Instead, story points help a team quantify the general size of the user story. These relative estimates are less precise so that they require less effort to determine, and they hold up better over time. By estimating in story points, your team will provide the general size of the user stories now and develop the more detailed estimation of hours of work later, when team members are about to implement the user stories.

Can anyone clarify:

What should be the measuring scale for story points? Should it be out of 10, 100 or the highest story point assigned in the given product backlog?
(little off-topic) A 'product backlog item' (check the attached image) consists of all the user-stories of the project while a sprint backlog contains a subset of stories from the product backlog. Having said that; if one product backlog is sufficient, then why TFS allow us to have multiple product backlog items?

Solution

You can use any scale you like. What I tend to do is the Fibbonaci (1, 2, 3, 5, 8, 13, 21, ...). To set the baseline of the scale we took a golden story which was average size and valued that with an 8 and one with a little less size and valued that 5. We now just value all the other stories to those two. And since you are working Agile you are just continuously improving. So if you feel that you need to have different golden stories: just do it.
The PBI (Product Backlog Item) work item is not the Product Backlog itself. It is the story on the backlog. The Product backlog list all the stories you would like to implement at some point in a specific order (hopefully the one with the highest business value is on top). When you want to pull a story into a sprint you change the iteration path. It is now pulled off the product backlog and shown on the sprint backlog.