The Vision and Scope Document · Business Analysis Notes

Key ideas#

Vision is not scope#

Wiegers and Beatty separate two things that teams often blur:

The product vision describes the whole product and where it is heading. It changes slowly, with strategy.
The project scope describes what one release or iteration will deliver. It changes far more often, and the further away a release is, the fuzzier its scope.

Each level must fit inside the one above: user requirements serve the business objectives, and functional requirements serve the user requirements. If something does not trace upward, question it.

What the document holds#

The authors’ template has three parts: business requirements (why), scope and limitations (what, release by release, and what not), and business context (who, and under which priorities). The outline under “Template” below follows that shape.

The out-of-scope list repays the effort. Writing down what you will not do settles an argument once instead of reopening it every month.

Objectives you can check#

Business objectives can be financial (market share, revenue, savings) or non-financial (customer satisfaction, compliance, reliability). Either way, make them verifiable: an action, a number, a unit and a deadline. “Become a world-class company” fails that test.

Wiegers and Beatty also warn: measure what matters, not what is easy. “Cut production costs by 20%” can be met by layoffs, which is rarely what the sponsor intended.

To get from vague problems to measurable objectives, they describe the business goal model, credited to Beatty and Chen. You cycle through three questions with the sponsor:

What prevents us from reaching this objective? (leads down to a more specific problem)
Why do we care about this objective? (leads up to a higher-level problem)
How will we know this problem is solved? (leads to a measurable objective)

The vision statement#

A short vision statement follows Geoffrey Moore’s “elevator pitch” keywords: target customer, need, product, category, key benefit, current alternative, and key difference. Its real value is as a test: when several stakeholders write it separately, the differences reveal mismatched expectations before work starts.

Risks, assumptions and priorities#

Keep business risks (competition, timing, user acceptance) apart from project risks (staffing, technology).
Write down assumptions. A revenue target often hides an unstated belief about customer numbers or spend. If it proves wrong, the written assumption explains the miss and prevents blame.
Classify five project dimensions (features, quality, schedule, cost, staff) as a constraint (fixed), a driver (important, slightly flexible) or a degree of freedom (the manager may trade it). Wiegers notes they cannot all be constraints, or the project has no way to absorb change.

Showing the boundary#

Choose one representation: a context diagram (the system as one bubble, external entities and flows around it), an ecosystem map (Beatty and Chen; it also shows systems linked only indirectly through shared data), a feature tree, or an event list. What a context diagram leaves out is information too.

How to apply it#

Start with the full template, then shrink it to fit. If a required section is empty, say so (“No business risks identified”) instead of deleting it, so readers know it was checked.
Run the three goal-model questions with the sponsor until every problem has a measurable objective.
Draft the vision statement, collect three or four independent versions, and reconcile them.
Draw one scope diagram and write the exclusions list.
Agree the five dimensions with the sponsor and project manager.
Filter requests through the objectives: which objective does this feature serve, and how much does it contribute?
Declare the project done when the success metrics show the objectives are likely to be met, not when every idea has been built. Vague objectives produce a project with no clear end.

Agile teams rarely write this document formally, but the content still matters. They either fix iteration length and let the set of stories vary, or fix overall scope and date and adjust the number of iterations. Many use an “iteration zero” to agree the vision.

Template#

Template

# Vision and Scope: <product or project name>

## 1. Business requirements
### 1.1 Background — the situation that triggered the project
### 1.2 Opportunity — the problem or market chance you are addressing
### 1.3 Objectives — action + number + unit + deadline
### 1.4 Success metrics — how and when you will check each objective
### 1.5 Vision statement — customer, need, product, category, benefit, alternative, difference
### 1.6 Business risks — market, timing, acceptance (keep project risks elsewhere)
### 1.7 Assumptions and dependencies — beliefs the objectives rely on

## 2. Scope and limitations
### 2.1 Major features — short numbered list with stable IDs
### 2.2 First release — which features, and to what depth
### 2.3 Later releases — tentative allocation
### 2.4 Out of scope — what you will explicitly not do

## 3. Business context
### 3.1 Stakeholders — who they are, what they value, what they fear
### 3.2 Project priorities — each of the five dimensions: constraint, driver or degree of freedom
### 3.3 Deployment — sites, training, data migration, timing

Example#

For The Workshop, a fictional chain of 12 bike-repair workshops:

Objective: halve phone calls about repair status within six months of launch (a fictional target).
Vision statement: for cyclists who want their bike fixed without wasted trips, Workshop Online is a booking and repair-tracking service that lets them reserve a slot and follow the repair by phone. Unlike calling the shop, it works at any hour and shows the actual status.
Out of scope: selling bikes and accessories online.
Assumption: most customers can receive notifications on their phone.
Priorities: schedule is a constraint (live before the spring season), cost is a driver, features are the degree of freedom.

Pitfalls#

Slogans instead of objectives. Rewrite each with a number, unit and deadline.
Writing the document once and forgetting it. Revisit it whenever scope changes.

Sources and further reading#

K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 5 (vision and scope template, business goal model, project priority dimensions).