Skip to main content
All CollectionsBoards
Enablement: Solution Boards
Enablement: Solution Boards

How to adopt Solution Boards - Solution Backlog and Solution Planning Boards - with Large Solution, Portfolio or Full SAFe configurations

Updated over 10 months ago

The Solution Boards are designed to enable the Solution Train organizational layer in Large Solution, Portfolio or Full SAFe configurations. In general terms; people + teams, work items and processes related to the governance layer supporting multiple ARTs or a portfolio of investments.


Below is a simple table for the purpose of providing common concepts and language as we explore the use of Solution Boards in this article.
โ€‹
I provide some general guidelines of the scope related to the Solution Boards; as it relates to People, Process (Work Items) and Time horizon. From this general baseline of Solution Board concepts + definitions we can start to play with ideas on how to use Solution Boards to facilitate the bigger picture (everything above the ARTs in SAFe) that surrounds PI events.

Organizational Nodes

Work Item Hierarchy

Time Horizon

Solution Train

Capabilities

Span multiple PIs

Agile Release Train (ART)

Features / Enablers

> an Iteration but < the PI

Teams (organized in ARTs)

User / Enabler Stories

Maintenance

Sprint (~2x weeks)


FAQs

Q: Is there a way to import work items (Sticky Notes) into the Solution Board?

Answer: Currently, as of Jan 2nd 2024, there is no bulk import functionality related to the Solution Boards. The guiding design principle at the moment is that the number of higher-level work items that would be managed at any one time at this level would be minimal and creating the Solution Backlog items manually would be sufficient.

Q: What are some general guidelines (good or emergent practices) for connecting Sticky Notes between the Solution (Capabilities), ART (Features) and Team (User Story) Boards?

Answer: At minimal keep some basic standards or working agreements amongst all PI participants. If you have a work item hierarchy, for example Capability > Feature > Story, then keep this hierarchy in the Sticky Note links too. Our minimal guidelines or recommendations are:
โ€‹

  • User Stories should originate on the Team Board and only be linked to Features that originate on the ART Backlog Board.

  • Features should originate on the ART Backlog Boards and are the scope of the ARTs delivery schedule for the PI. Since multiple Features will make up a Capability then only link Features to Capabilities (Solution Backlog).

  • Ensure tab #10 Links in the PI Session reflects these links respectively so they can be automatically mapped into the connected ALM tool.

Q: Are the Solution Board stickies meant to be managed to Sprints/Iterations manually?

Answer: The current functionality relies on managing the placement of the Solution Backlog [Work Item] Sticky Notes (e.g. Capabilities in this example) on the Solution Planning Board manually. A responsibility that will be the purview of a Portfolio team etc.

To facilitate that manual placement of the Solution Backlog sticky notes into Iterations/Sprints, we provide the ability to Mirror the ART Backlog items and Team Board Dependency sticky note items to the Solution Planning Board. In this manner the Iteration/Sprint plans from the ART and Team Boards is reflected on the Solution Board, to therefore allow for intelligent and transparent placement of the Solution Backlog items into the right Iteration/Sprint.


We are being methodical about what new functionality to release on the Solution Boards. This is the Portfolio level and maturity at the Portfolio level varies greatly.

Figure 1: The Solution Planning Board highlighting Capabilities being delivered by each ART with cross-ART dependencies.

Did this answer your question?