A vision that nobody remembers isn't a vision — it's a document.
"The goal is to create a 'north star' to guide the team during their work." — from Visioning notes
That's the real purpose of visioning. Not to produce a vision statement artifact. To give the team a shared anchor — something specific enough that they can use it to make daily decisions.
The IIBA Agile Extension is clear on what makes a good vision:
"Apple iPod vision: All your music in one place in your pocket." "NASA vision: Put a man on the moon."
Notice what these have in common: they're short, concrete, and tell you immediately what success looks like. You can evaluate any decision against them. "Does this sprint goal move us toward all your music in one place in your pocket?" That's a functional test.
In the Scrum Guide, the Product Goal is the near-term expression of the vision — the next significant milestone the Scrum Team works toward. The Product Goal lives in the Product Backlog: every item in the backlog either supports it or doesn't belong there.
Visioning is typically done as a workshop — the BA facilitates, stakeholders contribute, and the goal is a shared understanding, not a pre-written statement that gets approved. The conversation is the value. A vision created by one person in a document room and handed to the team is not a shared vision.
"The visioning effort provides no value if the team does not use the information for decision making and prioritization." — IIBA Agile Extension
Exam tip: For PSPO II, the Product Goal and Product Backlog relationship is heavily tested. Items that don't support the current Product Goal should be removed or deprioritized — that's an active PO accountability.