HKSM

Create Project Vision is the early Scrum process that crafts a clear, shared statement of why the project exists, for whom, and what success looks like, to guide all subsequent planning and delivery.

Purpose & When to Use

This process sets the direction for the entire initiative. It answers: Who are we serving, what problem are we solving, why now, and how will we know it worked? Use it at project inception, when re-starting a stalled effort, or when a major pivot changes goals or customers.

The outcome is a concise Project Vision Statement that aligns stakeholders, frames value, and becomes the north star for backlog creation, release planning, and scope decisions.

Mini Flow (How It’s Done)

• Trigger and inputs: An approved or draft Business Case or mandate, strategic objectives, initial market insights, and a preliminary stakeholder list.
• Assemble the right people: Sponsor and Product Owner lead the content; Scrum Master facilitates; include key stakeholders and a technical representative for feasibility sanity checks.
• Run a vision workshop: Clarify target users/personas, problems/opportunities, value proposition, benefits versus costs, high-level scope boundaries, constraints, major assumptions, and success measures.
• Draft the Project Vision Statement: Use simple, testable language (e.g., elevator pitch style). Keep it short enough to be remembered and shared.
• Validate and refine: Check alignment with strategy and the Business Case; resolve conflicts; confirm feasibility at a high level without committing to detailed design.
• Approve and communicate: Sponsor signs off; Product Owner owns the vision going forward; publish it widely (radiate on team wall/wiki) and reference it in backlog discussions.
• Connect to downstream work: Use the vision to inform the initial Product Roadmap outline and to seed the first cut of the Prioritized Product Backlog.

Quality & Acceptance Checklist

• Customer and problem are clearly stated (who, what pain, why it matters).
• Desired outcomes are measurable (success criteria and benefits, e.g., SMART/OKR-style).
• High-level scope boundaries defined (what is in/out, major constraints and assumptions).
• Strategic alignment is explicit (how it supports portfolio/program goals).
• Feasibility plausibly checked (no detailed design commitments).
• Risks and uncertainty acknowledged at a high level with guardrails (budget/time/value targets).
• Concise and shareable (ideally one page or equivalent), free of jargon and solution bias.
• Owned by the Product Owner and endorsed by the Sponsor; accessible to the whole team.

Common Mistakes & Exam Traps

• Confusing the vision with a detailed plan or backlog; the vision sets direction, it does not specify tasks.
• Writing a technical solution statement instead of an outcome/value statement.
• Skipping stakeholder alignment, leading to conflicting priorities later.
• Omitting measurable success criteria; if you can’t measure it, you can’t steer.
• Creating a long, unreadable document that no one references.
• Starting Sprint work without a shared vision, causing churn and rework.
• Assuming the Scrum Master owns the vision; in Scrum, the Product Owner owns it with Sponsor input, while the Scrum Master facilitates the process.

PMP/SCRUM Example Question

In a new Scrum initiative, who is primarily responsible for defining and owning the Project Vision, and what should happen before backlog creation begins?

1. The Scrum Master; conduct a sprint planning session to discover the vision during execution.
2. The Product Owner with Sponsor input; facilitate a vision workshop and gain alignment/approval.
3. The Development Team; create a technical architecture that implicitly defines the vision.
4. The Project Manager; write a detailed project plan that doubles as the vision.

Correct Answer: B. The Product Owner owns the vision with input and endorsement from the Sponsor; a facilitated vision workshop should align stakeholders and produce an approved Project Vision Statement that guides backlog creation.