Why adopt this practice

It is not uncommon that misunderstandings and miscommunication about the project strategy may lead the project team to develop a system that goes away from the original stakeholders' needs and vision. Without the correct context for decision-making about the requirements, not only user's satisfaction may be compromised, but also the project may be cancelled.

It is rather important that the development team and stakeholders have the same expectations. A shared vision provides a common understanding of the problem being addressed, a view of the high-level stakeholder requests and project constraints, and the background and context for requirements that will be later detailed. A shared vision serves as input for communicating the fundamental "what and why" for the project, and provides a strategy against which all future decisions should be validated. 

How it relates to other practices

Although decoupled in the adoption sense, this practice is related to many other useful practices. For example:

• Requirements - the vision is one of the outcomes of stakeholder requests elicitation, but also an input while gathering more fine-granular requirements. Stakeholders and development team use the vision to ensure consistency while reviewing the requirements that have been identified and the ones that have been detailed.
• Architecture - the vision provides the goals for the architecture and helps to identify which goals to address through out project iterations. These goals will prioritize and guide the approach to important technical decisions.
• Project management - the vision captures a high-level view of the scope and constraints of the project, which helps the team to discuss project (and iteration) priorities and estimates with stakeholders. The value delivered by the team at the end of each iteration must align with stakeholders' expectations expressed by the project vision.