People at work are thirsting for context, yearning to know that what they do contributes to a larger whole.

—Daniel Pink

Vision

The Vision is a description of the future state of the Solution under development. It reflects customer and stakeholder needs, as well as the Feature and Capabilities proposed to meet those needs.

The vision is both aspirational and achievable, providing the broader context—an overview and purpose—of the Solution under development. It describes the markets, customer segments, and user needs. It sets the boundaries and context for new Features, Nonfunctional Requirements (NFRs), and other work.

The vision applies to any SAFe configuration, which explains why it’s on the Spanning Palette. While its focus is typically on the solution, a portfolio vision is also clearly relevant, reflecting how Development Value Streams will cooperate to achieve the Enterprise objectives. Agile Release Trains (ARTs) and Agile Teams may also have their own vision to communicate their part in developing the solution.

Details

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 and limiting Work in Process (WIP). It also avoids Big Design Upfront (BDUF), future-proofing architectures, and overly detailed plans. There is no 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 many decisions. Therefore, continuously developing, maintaining, and communicating the vision 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.

Portfolio Vision

In Portfolio SAFe, The portfolio vision sets a longer-term context for near-term decisions in a way that is both practical and inspirational. (“This is something worth doing.”) Understanding the longer-term view helps the Agile teams make more informed choices about the development of functionality in both the short and long run.

The Portfolio canvas is a key input in developing the portfolio vision. One of the primary uses of the canvas is to record the current state of the portfolio. The current state canvas represents the as-is state for the portfolio, enabling alignment of the organization on its structure, purpose, and status. The next step is to envision the future state, which helps define the vision for the portfolio.

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 view a “Destination Postcard,” as Figure 1 illustrates [1].

Figure 1. The portfolio vision is an enterprise-level ‘postcard from the future.’

A portfolio vision exhibits the following characteristics:

  • Aspirational, yet realistic and achievable – It must be compelling and somewhat futuristic, yet practical enough to be feasible over some meaningful timeframe
  • Motivational to engage others on the journey – The vision must align with the Strategic Themes, as well as to the individual team’s purpose

Business Owners (or C-level executives) typically present this longer-term view and business context during the Program Increment (PI) Planning event. These leaders can inspire and align the teams, increasing their engagement and fostering their creativity to achieve the best results.

Solution Vision

In Large Solution SAFe, Product and Solution Management have the responsibility for translating the portfolio vision to a solution vision, indicating the reason and direction behind the chosen solution. Doing so requires specific questions to be asked and answered:

  • What will this new solution do?
  • What problems will it solve?
  • What features and benefits will it provide?
  • For whom will it provide them?
  • What Nonfunctional Requirements will it deliver?

Inputs to the Solution Vision

Product and Solution Management work directly with Business Owners and other stakeholders to synthesize all the inputs and integrate them into a holistic and cohesive vision, as Figure 2 illustrates. These inputs include the following resources:

Figure 2. Solution vision input sources
  • Customers  – Customers provide fast feedback and have intimate knowledge of what is needed
  • Strategic Themes – The Strategic Themes provide direction and serve as decision-making filters
  • Portfolio Canvas – The portfolio canvas provides the current state and the desired future state for the portfolio
  • Solution Context – The solution context indicates how the solution interacts with the customer’s context
  • Solution Backlog –  The solution backlog contributes direction and guidance to the vision
  • Solution Intent  – The solution intent contains some of the vision and is the destination for new elements
  • Architect/Engineers – The System and Solution Architect/Engineers support the continuous evolution of the Architectural Runway supports current and near-term features
  • Agile Teams– Finally, and not to forget the obvious, the foremost experts in the domain are typically the Agile teams themselves
  • Product Owners – The Product Owners 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 [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, stakeholders building large solutions, such as Solution Management, describe the current overall solution vision, while Product Management provides the specific Agile Release Train (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.

Program Vision

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.

Roadmap View

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.

Figure 3. The Roadmap is part of the vision

PI Planning Vision—the Top 10 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 increment steps forward, one PI at a time and one feature at a time, as Figure 4 illustrates.

Figure 4. Vision is achieved one PI at a time, via the “Top 10 Features for the
next PI”

To achieve this, Product Management constantly updates feature priorities using Weighted Shortest Job First (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, their benefit hypotheses, and acceptance criteria, so when features reach this boundary, they are fairly well-formed and vetted.  Architect/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, the knowledge that emerges during planning, and more. Only the teams can plan and commit to a course of action, one that is summarized 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

[1] Heath, Chip, and Dan Heath. Switch: How to Change Things When Change Is Hard. Broadway Books, 2010.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[3] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

[4] Leffingwell, Dean, and Don Widrig. Managing Software Requirements. Addison-Wesley, 2001.

 

Last update: 10 February 2021

 

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.