I am looking into BDD testing within a scrum scenario and realise that the BDD scenarios are more akin to specifications than tests.
Therefore should they be written before the developers go into pre-planning so that all of the functionality has been identified which would allow better estimating, prioritisation etc in that meeting?
Generally, in Scrum you want user stories that also have conditions of satisfaction to go along with them. Meaning, that if these conditions are met, I as a Product Owner, will be satisfied that the story is complete.
It's best to have these written by the Product Owner and even better if they are written in the Given/When/Then format. That way the team can create the BDD tests based on the conditions of satisfaction. When the tests pass, the story is complete.
There should be as many conditions of satisfaction as the Product Owner feels necessary to confirm that the story has been implemented and these conditions should be prepared in time for the sprint planning meeting. They don't need to be coded, but they should be written out so that the team has an idea of what is expected to complete the story.
The team may add their own BDD tests during the sprint as things come up, but the story isn't complete until the initial BDD tests pass.