People at work are thirsting for context, yearning to know that what they do contributes to a larger whole.
The Vision is a description of the future state of the Solution under development. It reflects customer and stakeholder needs, as well as the features and capabilities proposed to meet those needs.
The vision is both aspirational and achievable, providing the larger context—an overview and purpose—of the solution under development. It describes the markets, customer segments, and user needs to be served. It sets the boundaries against which new features, Nonfunctional Requirements (NFRs), and other content decisions are based.
The vision icon lives on the ‘spanning palette,’ which means it can apply to any level of SAFe. While the focus of the vision is typically is on the solution, a Portfolio Vision is also clearly relevant, reflecting how the Value Streams will cooperate to achieve the larger Enterprise objectives. Moreover, Agile teams will often also have a vision for the elements of the system for which they have responsibility.
Few question the benefit of Lean-Agile’s focus on near-term deliverables and fast value delivery, which favors: deferring decisions until the last responsible moment, limiting work in process, avoiding Big Upfront Design (BUFD) and future proofing architectures, along with overly detailed long-term plans. There is no good substitute for a bias for action: ‘Let’s build it and then we’ll know.’
However, in the context of large Solutions, every individual contributor makes frequent decisions on what the solution should do 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.
Continuously developing, maintaining, and communicating the vision—both near and longer 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.
The portfolio vision sets a longer-term context for near-term decisions in a way that is both practical and inspirational: “This is something really worth doing.” Local decisions by Agile teams are best made in the light of this longer-term context.
Lean-Agile leaders have the most 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 timeframe.
- 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 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. 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 feedback and have intimate knowledge of what is needed
- 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’s context.
- Solution Backlog contributes direction and guidance to the vision.
- Continuous evolution of the Architectural Runway supports current and near-term Features.
- Strategic Themes provide direction and serve as a decision-making filter
- 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, large solution level stakeholders, such as Solution Management, describe the current overall Solution 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.
When using ‘Full SAFe’ or ‘Large Solution SAFe’, 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 must 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. Product and Solution Management have the responsibility to provide the direction for these next steps. In the SAFe context, this translates to a series of incrementalk 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. Further, the Program Kanban is used to explore the scope of features, its benefit hypothesis, and acceptance criteria, so when features reach this boundary, they are fairly well formed and vetted. 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.
Solution Management presents a similar “Top 10” Capabilities list during Pre-PI Planning to align the ARTs within a Solution Train.
Learn More 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: 17 June, 2017