Firstly, estimation is not always critical. It is often beneficial, but often the benefit can outweigh the time and energy invested in creating the estimates. Scheduling is not always required.

Secondly, "clarity" of requirements can only be definitively assessed by delivery of a working increment that meets that requirement; it is often the case that users or stakeholders will want to modify that requirement upon seeing the working feature that results. In agile environments, we recognise that scope changes often. The larger and more complex the project, the greater the chance that the scope will change - up or down or both.

Using BDD in Gherkin syntax is a great way of defining the details of feature behaviour; but I prefer that these be separate from acceptance criteria, which I believe should be bullet-point sentences in the form: "I can...". These provide the boundaries of the scope of the user story, and provide a clearer picture for BDD scenarios to emerge from them.

Lastly, you miss the point of Story Points entirely. They were never intended to be used to make business decisions in and of themselves.

Once you have completed a few Sprints and established your velocity, you can then project that velocity to predict delivery dates (within a range) - the business metrics you want. A velocity of 25 implies that, with a stable backlog (Ha!) and a stable team (ha!) we can deliver the 17th user story on the backlog in Sprint number n.

The desire for precision and certainty in software development is almost guaranteed to fail. And the more volatile the backlog, the higher that likelihood becomes.

As the manifesto itself says: "We value Responding to Change over Following a Plan"