Splitting User Stories

I've heard many times from my teams that they have a hard time estimating user stories that are moved from the backlog to the Sprint, the most commonly sited problems are related to the size and ambiguity of user stories. I believe that this happens partly because the confusion about the backlog, more precisely, teams tend to think that there's only one backlog.

It's crucial that Scrum teams to recognize that in fact there are two backlogs, one Product Backlog and one Sprint Backlog. I describe below some characteristics of both:

1. The Product Backlog contains high level user stories created mainly by the Product Owner. Those user stories has to have business value and usually will require a lot of man-hours to implement.
2. User Stories in the Product Backlog has to be prioritized by the Product Owner based on her perception of business. Of course teams can have an stake on this but business value should be the key driver.
3. During the planing stage, teams take user stories from the top of the Product Backlog, digest them and decide what to include in the Sprint Backlog. Teams are expected to split Backlog User Stories in smaller chunks if necessary. Actually, it's highly recommended that they do so. Note that Product Backlog User Stories are high level whereas Sprint Backlog User Stories has to be good instruments for estimation, planning, and tracking. The 'devide and conquer' principle is applicable here.
4. Even before deciding what to move to the Sprint Backlog, teams need to considered their velocity (measured in story points or hours) to have a feel of their capacity. Velocity is a great indicator that helps preventing teams for overcommitting, of course that for this to be effective, teams need to have a clear perception of their velocity.
5. A crucial point here is that teams and not Product Owners decide what to move to the Sprint Backlog. Of course that the PO can influence and negotiate, but she shouldn't be allowed to overload teams beyond their capacity. Successful teams don't refuse to work on something, they accept to work on that something in exchange of something else.
6. A symptom-at least in early Sprints-for things not going that well is that the Sprint Backlog would be bigger than the Product Backlog, this might indicate that: A, the Product Backlog doesn't exist or still in process of being created or B, the team is overcommitting and trying to complete too many User Stories in an Sprint. A could be a also a indicator that the PO is not involved in the project. B typically happens when teams aren't aware of their own velocity.