HKSM

A concise, stable summary of the product's purpose, target users, expected benefits, and high-level success criteria for the Scrum project. Created early by the Product Owner with sponsors and key stakeholders, it guides backlog creation, prioritization, and release decisions across the lifecycle.

Key Points

• Output of Create Project Vision; input to Identify Stakeholders, Form Scrum Team, Develop Epics, Create Prioritized Product Backlog, and Plan Releases.
• Owned by the Product Owner, created collaboratively with sponsor, customers, and key stakeholders.
• Short, measurable, and stable enough to persist, yet revisited when strategy or market conditions change.
• Sets boundaries for scope and helps reject backlog items that do not support the desired outcomes.
• Provides a north star for Sprint Goals, Release Planning, and progress reviews.
• Links business justification to delivery by defining value, constraints, and minimum success criteria.

Purpose

The statement aligns everyone on why the product is being built and what success looks like. It reduces churn by making trade-offs easier when new ideas arrive.

It also connects the project to organizational strategy and funding, helping the team focus on value and enabling clear go or no-go decisions at release checkpoints.

Key Terms & Clauses

• Target users and customer segments.
• Problem or opportunity to address.
• High-level product capability or positioning.
• Business value and measurable outcomes (success criteria).
• Assumptions and key constraints (budget, time, compliance).
• Non-goals or out-of-scope items.
• Strategic alignment and expected benefits.

How to Develop/Evaluate

1. Engage sponsor, Product Owner, key stakeholders, and representative users to capture needs and drivers.
2. Draft a one-page vision using a clear elevator pitch format and include measurable success criteria.
3. Record assumptions, constraints, and high-level risks that shape scope and pace.
4. Align with organizational strategy and any Scrum Guidance Body guidelines.
5. Review, refine, and baseline; keep it visible in the product repository.

Quality checks:

• Clarity: understandable by a new team member within minutes.
• Measurability: contains outcomes that can be tested at release time.
• Relevance: directly supports strategy and stakeholder needs.
• Conciseness: one page or less; avoids solution-level detail.

How to Use

Use the statement as the primary input when developing epics and creating the Prioritized Product Backlog. It anchors relative prioritization by linking items to stated outcomes and constraints.

• Backlog management: accept or defer items based on alignment with outcomes and non-goals.
• Sprint Planning: shape Sprint Goals that contribute to the vision.
• Release decisions: assess whether success criteria are met before launching.
• Stakeholder alignment: socialize at kickoff, Sprint Reviews, and when major changes arise.
• Risk handling: test proposed pivots or scope changes against constraints and assumptions.

Example Snippet

For mid-size enterprises that struggle with manual reporting, our product will automate data aggregation and deliver near real-time dashboards. Unlike ad-hoc spreadsheets, it provides role-based insights and audit-ready traceability.

• Success criteria: reduce report cycle time by 60 percent; reach 80 percent user adoption in 90 days; pass compliance audit with no major findings.
• Constraints: initial release in 4 months; budget not to exceed X; security controls must meet standard Y.
• Non-goals: advanced predictive analytics excluded from the first release.

Risks & Tips

• Risk: a vague or long statement leads to bloated backlogs and misaligned Sprint Goals.
• Risk: skipping measurable outcomes makes release decisions subjective and slow.
• Tip: keep the statement visible on the team board and product wiki; revisit at each major release.
• Tip: phrase outcomes with clear metrics; avoid specifying design or technical solutions.
• Tip: use it to resolve prioritization conflicts by mapping items to stated benefits.

PMP/SCRUM Example Question

A new Product Owner is starting a Scrum project and wants guidance for creating epics and prioritizing the initial Product Backlog. Which artifact should they rely on first?

1. Definition of Done.
2. Sprint Goal from the first Sprint.
3. Project Vision Statement.
4. Team Working Agreement.

Correct Answer: C — Project Vision Statement

Explanation: The Project Vision Statement is the primary input for developing epics and prioritizing the initial backlog. The other artifacts are useful later but do not define the product's purpose and outcomes.