The way I've been coaching business leaders on is to separate schedule from scope. If you try and completely hit the plan for both you will A- Fail almost for certain, B- Spend a lot of wasted time trying to estimate. This has been true even back to the old traditional project models. The PMP test teaches us about "Order of Magnitude" estimating for a reason.
So I coach the following- Pick the Release Date, "Really" rank order the backlog, Estimate the Backlog, Commit to the top 25% of the backlog, revise at 25%, 50% and 75% of the release schedule.
1- Pick A Release Date: Decide when you need to ship. For most companies predictability of release date is more important than content of release. Knowing they can count on a release going out on X date with high quality (quality is assumed, but does need to be planned), then they are going to be a lot happier and more tolerant of not knowing "exactly" what they will get. Scrum is great for hitting a release date. You know when to ship, you know how many sprints you have and you can plan your scope to that.
2- Really order the backlog: No really, we mean it. You need to stop doing anything with Priority. You can't have five P0s. That's like saying "we have one surgeon and all five of these people have to be operated on first." In trauma medicine we have the concept of triage. If doctors and their staff can make the very hard call on which patient to operate on first, we can make the hard call on if Feature A has more or less business value than Feature B. The key thing here is to estimate on business value AND the level of effort to build. If a story A costs 3 points to build and story B costs 8 points, engineering is probably going to build the 3 point story. If, however, Story A is worth 1 point and Story B is worth 13 points, then Story B probably should get worked first.
Commit to the top 25% This is not a hard number, go with what works. The concept here is that once you have a backlog you can probably have a certain confidence in being able to absolutely deliver a certain amount of the backlog. Don't ever do this as a stretch goal and never more than 50% of the backlog. What you're doing is saying "No matter what, we will ship this, you can take it to the bank." So be cautious.
Revise at 25%, 50% and 75% Then comes the order of magnitude estimating with agile. As you move through the release, you will get a better idea of your velocity and ability to deliver. At these milestones you update what you can commit to deliver based on the reality of what has already been delivered.
So in a year long program, at the start of the program sales knows 25% of the features and can be selling those right then. Three months before ship, you know for certain everything that will be in the release and groups like customer support and professional services can do final training.
Don't try to commit to schedule and scope at the start of a release. It will be fiction and everyone will know it.