If we assume that you have a fairly mature Scrum team working on the project - meaning that they have a good spread of appropriate technical skills, work well together, follow the Scrum practices appropriately, and have reached a point in both productivity and estimation that they are regularly able to deliver the Sprint Goal without being heavily over- or under-worked, then:
Any Product Backlog item should be placed in a position on the backlog representing its priority relative to the other PBIs per the Product Owner's understanding of the current state of the Product.
Any Product Backlog item should be estimable, meaning that the team has some idea of how simple or complicated it is relative to other tasks, and hence of their capability of completing it if it were included in a Sprint. (This could be done in terms of Story Points or any other manner, like T-Shirt sizes or world monuments or whatever, as long as the team understands how the values relate to each other.)
The Product Backlog items near the top of the backlog will, on average, be better understood, more clearly defined, smaller and have fewer unmet preconditions than the ones further down the Backlog - i.e. they should be more ready, with the items right up the top being potentially ready to be worked on right away.
With this being the case, the Product Owner should be able to essentially just draw a line somewhere in the Product Backlog and say "This is what we are delivering next Sprint", and the Scrum Team should be close enough to agreeing with this that they can negotiate and adjust the point up or down a few items.
This also means that the Product Owner should be able to draw multiple lines down the Product Backlog, each representing a Sprint's worth of work. If you do that, then you have an estimate of how long it will take for any given item to be completed, since it's just a function of how many Sprints away it is and how long your Sprints are.
However, you have to keep an eye on points 1 and 3 above. Each Sprint Review is a discussion between the Scrum Team and the customer, and it represents a point at which the Product Owner may decide to change the order of items in the Backlog, or even change what items are represented in the Backlog at all. Additionally, anything that's further down the Backlog is by nature clouded in uncertainty - something that's currently 1 Sprint down in the Backlog will probably wind up in the next Sprint, but something that's 4 Sprints down might wind up being worked on 3 Sprints from now, or 5. It might be split into 3 different items because it actually involves multiple major developments, or the team might need to invest in a research spike to even understand what developing that feature even entails.
A lot of Waterfall-style projects tend to assume that the milestones planned at the start of the project are perfectly estimated and predictable, but if you're working in a Scrum team then there's a decent chance that your product doesn't fit well in that paradigm in the first place, and the stakeholders who are breathing down your neck asking for perfectly accountable timeframes are going to struggle to get used to this, but hopefully if they are involved in the key parts of the Scrum process (especially Sprint Review, where they can see both the incremental development of the Product and the adjustment of the Product Backlog) then they will start to learn the value of embracing this uncertainty - which is always going to be there, but made much more overt in Scrum than in Waterfall.