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 and the features and capabilities proposed to meet those needs.

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

The vision can apply to any level of SAFe, explaining why it’s on the Spanning Palette. While the vision’s 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 define a 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, every individual contributor makes many decisions in the context of large solutions. Therefore, continuously developing, maintaining, and communicating the vision is critical to creating a shared understanding of ART’s goals and objectives, especially as those ideas evolve due to ever-shifting market needs and business drivers.

Portfolio Vision

The Portfolio Vision sets a longer-term context for near-term decisions in a practical and inspirational way. (“This is something worth doing.”) Understanding the longer-term view helps Agile Teams make more informed choices about functionality development in the short and long run.

The portfolio canvas is a critical input in developing the portfolio vision. One of the primary uses of the canvas is to record the current state of the portfolio. This canvas represents the portfolio’s as-is state, enabling the organization’s alignment 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 are responsible for setting the company’s strategic direction and establishing the mission for the teams implementing 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.’
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, mission, and purpose

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

Solution Vision

For Large Solutions, Product and Solution Management are responsible for translating the portfolio vision into a Solution Vision, describing 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 is this solution?
  • 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
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 Vision – The Portfolio Vision gives the current state and the desired future state of the portfolio
  • Solution Context – The Solution Context indicates how the solution interacts with the customer’s context
  • Solution Train Backlog   The Solution Train 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
  • Architects – The System and Solution Architects support the continuous evolution of the Architectural Runway and support current and near-term features.
  • Agile Teams– Finally, and not to forget the obvious, the foremost experts in the domain are typically Agile Teams.
  • Product Owners – The Product Owners continuously communicate emerging requirements and opportunities.

Capturing Vision in Solution Intent

Given the SAFe practice of cadence-based PI planning, vision documentation (various examples can be found in [2], [3], and [4]) is accompanied and sometimes replaced by rolling-wave vision briefings. These briefings provide routine, periodic presentations of the short- and longer-term vision for the ART. During PI planning for large solutions, stakeholders, such as Solution Management, describe the overall solution vision, while Product Management provides the specific ART context.

The relevant elements of the vision, including details of the system’s current system behaviors, are captured in the solution intent.

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 know what they must do. The Roadmap fills that purpose. Figure 3 provides an example.

Figure 2. The roadmap is part of the vision
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 are responsible for directing these next steps. In SAFe, this translates to a series of incremental steps forward, one PI and one feature at a time (Figure 4).

Figure 4. Vision is achieved one PI at a time via the top 10 features for the following PI
Figure 4. Vision is achieved one PI at a time via the top 10 features for the following PI

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 and are aware of the upcoming new features. Further, the ART Kanban is used to explore features’ scope, benefit hypotheses, and acceptance criteria so they are sufficiently well-formed and vetted when they reach this boundary. Architect 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. Some ARTs will have more or less than ten features that they bring into PI planning based on the ART’s velocity. What can be achieved in the following PI is subject to capacity limitations, dependencies, the knowledge emerging during planning, and more. Only the teams can plan and commit to a course of action summarized in the team PI Objectives.

But these features are ready for implementation. And feature by feature, the ART marches forward toward accomplishing the vision. Solution Management presents a similar top ten 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: 28 February 2023