A planning workshop that ends with the team confused and uncommitted is worse than no workshop at all — it creates the impression of alignment without the substance.
Sprint Planning is the canonical Scrum planning workshop. It has two parts, and the Scrum Guide separates them explicitly:
Part 1: What can be done this sprint? The PO presents the Sprint Goal and the most important backlog items. The Developers forecast which items they can complete given their capacity.
Part 2: How will the selected work be accomplished? The Developers plan the work — breaking items down, identifying dependencies, and creating the Sprint Backlog.
The Scrum Master's job in Sprint Planning is to ensure the event is productive and time-boxed (eight hours for a one-month sprint, proportionally less for shorter sprints). Not to run it. Not to decide scope. To facilitate.
At scale (PI Planning in SAFe, or planning workshops across multiple teams), the same principles apply with more coordination surface. Teams need to identify dependencies between each other, not just within themselves. The BA's role in planning workshops is to ensure items entering the sprint are understood — which is why backlog refinement exists as a prerequisite.
"Refinement is frequently done in preparation for a Planning Session." — IIBA Agile Extension
Good planning workshops are a symptom of healthy backlog management. If you're having long, confused Sprint Planning meetings, the problem usually started earlier — in refinement, or in how the backlog is ordered.
Exam tip: Sprint Planning's two parts are tested directly in PSM and PSPO exams. Know who owns each part: the PO owns the Sprint Goal, Developers own the Sprint Backlog and estimates.