Sprint Goal
In the Sprint Planning meeting, is the Sprint Goal crafted first or are the PBI's for the Sprint are selected first and then the sprint goal is crafted?
Why does it need to be one before the other?
The Scrum Guide identifies two primary objectives for the Sprint Planning session - determining what can be done in the Sprint and determining (to some level of detail) how the work will get done. Both crafting the Sprint Goal and selecting the Product Backlog Items are part of determining what can be done in the Sprint.
Rather than trying to either craft a Sprint Goal or select Product Backlog Items and then going to the other, I'd suggest an iterative approach.
The Product Owner can come into the Sprint Planning session with an ideal Sprint Goal, and perhaps some Product Backlog Items that may support that goal. The Product Backlog Items should be (mostly) refined by the Development Team, meaning they have been decomposed appropriately and estimated and any dependencies identified. This can be the start of a good discussion between the Development Team and the Product Owner about projected capacity, recent historical performance, and the need to also consider other work (ongoing support, technical debt paydown, etc). The end result will be a Sprint Goal and Sprint Backlog that makes sense to both the Product Owner as well as the Development Team.
Agree with Thomas, but just to add additional info: usually (at least in my company) the Sprint Goal is creating in the first part of the Sprint Planning, but don't look at this as mandatory rule. You have to create the Sprint Goal at the Sprint, be t no matter when you will create it.
In the Sprint Planning meeting, is the Sprint Goal crafted first or are the PBI's for the Sprint are selected first and then the sprint goal is crafted?
Would the team’s purpose for working together that Sprint be clear to them at the start of Sprint Planning, or not until the end?
I've often found it helpful for teams to at least discuss the goal at the start of Sprint Planning. Sometimes they just share keywords, concepts, and areas of uncertainty, before looking at Product Backlog Items. Other times there's already enough alignment that they can write a draft Sprint Goal.
By the end of Sprint Planning, the Scrum Team should have a clearer idea of what is possible, valuable, and expected. Discussions about release strategy and the kind of customer feedback we expect during the sprint can often affect the wording of the Sprint Goal.