People at work are thirsting for context, yearning to know that what they do contributes to a larger whole.
The Vision describes a future view of the Solution to be developed, reflecting Customer and stakeholder needs, as well as Features and Capabilities that are proposed to address those needs. It also describes markets, customer segments, and user needs to be served. It provides the larger, contextual overview and purpose of the solution under development. It sets the boundaries against which new features, Nonfunctional Requirements, and other content decisions are based.
The vision is both aspirational and tactical in nature. It may be driven largely by a specific set of contractual obligations, or it may respond to the systems builders’ view of the opportunities the marketplace provides.
The vision icon lives on the “spanning palette” in SAFe. This reflects the fact that while the focus typically is on the solution at the Program and Value Stream Levels, the Portfolio Vision is also clearly relevant, and certainly Agile Teams can have longer-term views of the aspects of the systems that they are responsible for.
Few question the benefits of Lean-Agile’s focus on near-term deliverables. Deferring decisions until the last responsible moment, limiting work in process—foregoing detailed, too-early requirements specifications, future proof architectures, detailed longer-term plans—and instead focusing on immediate value delivery are hallmarks of Lean-Agile development. There is no substitute for that kind of focus and bias for action: “Let’s build it and then we’ll know.”
However, in the context of larger Solutions, every individual contributor makes decisions each day on what the solution is to do now and, in so doing, also what will be easy—or not so easy—to do in the future. In this way, they ultimately determine both the effectiveness of the current solution and the economics of developing future solutions. To this end, there is no substitute for keeping all team members continuously apprised of the solution Vision, for that is why they do what they do. Continuously developing, maintaining, and communicating the vision—both longer term and nearer term—is critical to creating a shared understanding of the program’s goals and objectives, especially as those ideas evolve due to ever-shifting market needs and business drivers.
In SAFe the vision appears on the spanning palette, indicating that it is applied at different places depending on context. The solution vision can be either at the Program Level in 3-level SAFe or on the Value Stream Level in 4-level SAFe, indicating to Agile Release Trains and Agile Teams why they are building the solution. The Portfolio should also have a vision, reflecting how the Value Streams will cooperate to achieve the larger Enterprise objectives. And of course the teams can apply the vision constructs as well, helping to ensure their focus on the nearer- and longer-term views.
The portfolio vision sets a longer-term context for near-term decisions in a way that is both practical—local decisions are made in the light of a long-term context—and inspirational: “This is something really worth doing.” Lean-Agile leaders largely have the responsibility for setting the strategic direction of the company and establishing the mission for the teams who will implement that strategy. Switch  calls this longer-term view a “Destination Postcard,” as Figure 1 illustrates.
A portfolio vision exhibits the following characteristics:
- Aspirational, yet realistic and and achievable. The vision has to be compelling and somewhat futuristic, yet realistic enough to be achievable over some meaningful time frame.
- Motivational enough to engage others on the journey. The vision must align with the Strategic Themes, as well as to the individual team’s purpose.
This longer-term vision—and the business context that drives it—is typically delivered to the teams during the periodic PI Planning event. It may be delivered by the Business Owners, or possibly by the C-level executive who can best communicate the vision, as well as inspire others to help achieve it. Given this vision, the teams will start thinking about how they will apply their unique strengths. True engagement begins with a destination in mind, one that helps the teams fulfill their purpose.
Given that longer-term view, Product and Solution Management have the responsibility for converting the portfolio vision to a solution vision indicating the reason and direction behind the chosen solution. In order to do so, specific questions must be asked and answered:
- What will this new solution do?
- What problem will it solve?
- What Features and benefits will it provide?
- For whom will it provide them?
- What performance (Nonfunctional Requirements) will it deliver?
Inputs to the Solution Vision
In SAFe, this responsibility lies primarily with Product and Solution Management (depending on whether this is a 3- or 4-level instance of SAFe). They work directly with the Business Owners and other stakeholders to synthesize all the inputs and integrate them into a holistic and cohesive vision. There is no shortage of inputs, as Figure 2 illustrates.
These inputs include:
- Customers provide fast and intimate feedback.
- Solution Intent contains some of the vision and is the destination for new elements.
- Solution Context indicates the how the solution interacts with the Customer context.
- Value Stream Capabilities Backlog contributes direction and guidance to the vision.
- Continuous evolution of the Architectural Runway supports current and near-term Features.
- Strategic Themes provide direction.
- Finally, and not to forget the obvious, the foremost experts in the domain are typically the Agile Teams themselves. Primarily through the Product Owner, teams continuously communicate emerging requirements and opportunities back into the program vision.
Capturing Vision in Solution Intent
Given the SAFe practice of cadence-based, face-to-face PI planning, vision documentation (various forms of which can be found in References 2, 3, and 4) is augmented, and sometimes replaced, by rolling-wave vision briefings. These provide routine, periodic presentations of the short- and longer-term vision to the teams. During PI planning, value stream level stakeholders, such as Solution Management, describe the current overall value stream vision, while Product Management provides the specific ART context and vision.
The relevant elements of the vision, along with details of the current and specific behaviors of the system, are captured in solution intent.
In 4-level SAFe, in addition to the solution vision, each ART will likely have its own vision, detailing the direction of the specific capabilities or subsystems that it produces. This vision should be tightly coupled to the solution vision it supports.
Having a sense of direction is critical to planning and engagement. But unless there is some realistic plan for how teams intend to fulfill the vision, people won’t actually know what they have to do. That purpose is filled by the Roadmap. Figure 3 provides an example.
PI Planning Vision—the Top Ten Features
The roadmap is indeed helpful. But for action and execution, the immediate steps must be clear. To that purpose, Product and Solution Management have the responsibility to lay out the next steps. In the SAFe context, this translates to a series of steady steps forward, one PI at a time, and one feature at a time, as Figure 4 illustrates.
To achieve this, Product Management constantly updates feature priorities using WSJF. Then, during PI planning, they present the “Top 10” to the team. The team won’t be surprised by the new list, as they have seen the vision evolve over time and are aware of the new features that are headed their way. In addition, the Program Kanban has been well used to develop the features, benefits, and acceptance criteria, so features that reach this boundary are fairly well formed and vetted already. Architecture/Engineering has already reviewed them, and various Enablers have already been implemented.
However, everyone understands that the Top 10 is an input, not an output to the planning process, and what can be achieved in the next PI is subject to capacity limitations, dependencies, knowledge that emerges during planning, and more. Only the teams can plan and commit to a course of action, one that is summarized at every Program Increment in the PI Objectives.
But these features are ready for implementation. And feature by feature, the program marches forward toward the accomplishment of the vision.
 Heath, Chip and Dan Heath. Switch: How to Change Things When Change Is Hard. Broadway Books, 2010.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
 Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
 Leffingwell, Dean and Don Widrig. Managing Software Requirements. Addison-Wesley, 2001.
Last update: 1 April 2016