Project vision and Product Goal: pointing the work somewhere

Teams that start without a shared sense of where they are going do not usually notice, at first. They are busy. The backlog fills up with sensible-looking items, the Sprints run, and months later someone asks what the product is meant to achieve and gets four different answers. A vision is the cheapest way to prevent that.

Two names for the same need

The Scrum Guide does not use the word "vision". It uses Product Goal. The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. It lives in the Product Backlog, and the rest of the backlog emerges to define "what" will fulfil it. The Guide calls it the team's long-term objective and says the team must fulfil or abandon one objective before taking on the next.

The SBOK® Guide starts a project a little earlier. In its Create Project Vision process, the project's business case is reviewed, the Product Owner is identified, and a Project Vision Statement is written. It is meant to provide overall guidance, inspiration and focus for the project. The statement is the key output of that process, along with the identified Product Owner, and may be accompanied by a project charter and a project budget.

So a Guide reader and an SBOK reader are doing the same job in different words. The SBOK is explicit about where the vision comes from and who approves the money. The Guide is explicit about how the goal governs the backlog afterwards.

What a good vision does

The SBOK says a good Project Vision Statement explains the business need the project is intended to meet, rather than how it will meet it. It should not be too specific, because the current understanding may rest on assumptions that will change. It should focus on the problem, not the solution.

That is advice worth taking whichever document you use. A vision that names the solution ("build a mobile app with a booking calendar") has already decided the thing that discovery should decide. A vision that names the need ("make it easy for families to find and book a tutor they trust") leaves room to find out that the answer is a web page, or an email, or something else.

A short test for a vision statement:

• Can everyone repeat it? If the team cannot say it from memory, it is too long or too vague.
• Does it name a user and a change? "Families can book a trusted tutor in minutes instead of days" has both.
• Could it be wrong? If nothing could ever contradict it, it says nothing.
• Does it still hold if the plan changes? The vision should survive the discovery that the first idea was poor.

What feeds it

The SBOK lists the inputs. The central one is the business case, the rationale for starting the project. It can be a polished document or a short verbal statement, formal or informal. It typically covers the background, the intended outcome, any analysis of strengths and weaknesses, known risks and a high-level estimate of time, effort and cost, and it should consider external factors such as regulation and privacy.

Other inputs help the Product Owner place the vision in context: the company's own vision and mission, so the project supports the organisation's direction; a market study, which gathers data on customer preferences, trends and competitors; and, where feasible, a small trial project or proof of concept to test whether the idea is viable before committing fully.

The techniques it suggests for reaching the statement are a vision meeting with the stakeholders who understand the company's direction and the justification for the project; a structured facilitated workshop to reach consensus on high-level scope and objectives; a SWOT analysis, which weighs internal strengths and weaknesses against external opportunities and threats; and a gap analysis, which compares the current state with the desired state. You do not need all of them. Pick the ones that answer a question you actually have.

The Scrum Guide gives no such list, and does not need to. Where the Product Goal comes from is left to the Product Owner, who may do the work or delegate it but stays accountable.

Charter and budget

The SBOK adds two documents the Guide leaves out. A project charter is a formal statement of the desired objectives and outcomes, and in most organisations the document that formally authorises the project and gives the team written authority to begin. A project budget covers the cost of people, materials and other expenses, is typically approved and signed off by the sponsor, and is then managed by the Product Owner and Scrum Master.

These are organisational realities, not Scrum rules. A team in a company that needs a signed authorisation before work starts will need a charter whatever framework it uses. What matters for Scrum is that the charter and budget serve the vision and do not freeze the solution.

A worked example

An invented case. A network of twelve public libraries wants to replace paper sign-up sheets for meeting rooms. The business case is a page: staff lose hours each week to double bookings, the public cannot see what is free, and the budget is fixed for the financial year.

First draft of a vision: "Build a room booking app with a calendar, payments and an admin dashboard." The team recognises this as a feature list, and it commits to a solution.

Second draft: "By the end of the financial year, a member of the public can see which rooms are free and book one without calling a branch." It names a user, a change and a date. It does not say how. When the team learns that payments are not needed because rooms are free, nothing in the vision is contradicted. The same statement becomes a Product Goal in the Product Backlog, and every item is tested against it.

Common mistakes

• A vision that is a feature list. It fixes the solution before anything is learned.
• A slogan. "Delight our customers" cannot guide a decision.
• Writing it once and filing it. The Guide has the Product Goal sit in the Product Backlog so it is seen every day. If it only exists in a kick-off deck, it is not doing its job.
• Several goals at once. The Guide asks for one at a time.
• The sponsor's vision and the team's vision differ. If the people paying and the people building cannot agree on a sentence, that disagreement is better found now than at the first review.
• Confusing it with the Sprint Goal. The Product Goal is the long-term objective, and the Sprint Goal is the objective of one Sprint. See writing a Sprint Goal.

The Agile Manifesto principle that the best architectures, requirements and designs emerge from self-organising teams is a reminder that a vision should orient the team, not script it.

How to practise it

In the simulator, the first step takes a business case, a market study, the company vision and the funding limits, and the Sponsor and Product Owner shape a vision and charter that you ratify.