The second of five (5) tasks in Planning Level 3 is optional. When appropriate, it seeks to group related Features. Doing so can help ensure resources are prioritized to deliver the most valuable increments of functionalty, rather than a randome set of less valuable Features.
Overview
Themes (or Initiatives) are used to help apply the Solution Roadmap effectively to Release Planning.  There is a reciprocal relation between Solution Roadmaps and Release Plans - once identified and defined during Release Planning, new Themes can be added to the Solution Roadmap; once on the Solution Roadmap, Themes help simplify the selection of Features for upcoming Releases.  Themes are an optional task of Planing Level 3. They are not appropriate for all Solutions.
Recall that the Roadmap is the high-level, strategic plan, intended to provide a longer-term outlook for the Solution's evolution. Each Release Plan is a medium-term plan which defines some increment of near-term scope and work effort that will advance the Solution towards its longer-term objectives.
The Solution Manager, Release Manager and Solution Owner(s) may struggle with the Roadmap when it comes to Release Planning. Frequently there are too many Features, and/or Features which define some very narrow increments of value. When this occurs it can turn the Roadmap into a tactical planning tool, which is not its intent - that is the purpose of the Solution Backlog and the Feature Planning Board.
Worse, the Features depicted on the Roadmap may be regarded by senior management as a commitment to deliver, as opposed to simply being part of high-level planning which is likely to change. In other words, the Roadmap is merely an estimate. It is only after Release Planning that there is a committment, and that commitment is only for the next Solution increment.
Additionally, there can be a tendency for Roadmaps to focus too much on individual Features, which can bog a Team down as members must spend too much time getting Stakeholders to agree upon when which Features will be developed.
Working with goals (i.e., Themes) shifts the conversation from debating individual Features to agreeing on desired benefits and making strategic Solution decisions.  BAs, Developers, QA, DevSecOps and other stakeholders should all agree upon and buy into the identified goals. When creating or updating the Roadmap, it is best to determine the goal(s) of each Release before identifying the Features to include.  Doing so helps to ensure that the Features selected do indeed serve the goal(s).
Solution Themes / Initiatives
A Theme is simply a collection of related Features which, together, seek to achieve some larger goal.  Consider this example:
Perhaps a Customer's desire for Order Management functionality involves the delivery of 8 individual Features. When those Features are looked at independently (i.e., without any organizing Theme), it may seem that two unrelated Features appear to be of higher priority than two Features needed to enable Order Management. By selecting 6 of the Order Management Features and the two unrelated Features neither the Order Management nor the other objective are achieved during the Release. By adding a goal-driven aspect, it becomes clearer that while two individual Features may have lower priority when considered independently, they actually contribute to a larger, higher-priority objective.
Ideally, the Features associated with a Theme all contribute to a common goal or are othewise related in some obvious way (e.g., all focusing on a given Customer benefit or on eliminating some area of Tech Debt). While some Features in a Theme may be dependent on one another, the Features need not encapsulate a specific workflow nor be delivered together.  One benefit of Themes is that Features can be moved in and out without significantly affecting the Solution Roadmap. They are also a better way to keep executives and stakeholders on the same page and focused on the big picture. Themes help keep the Roadmap at a high-level, especially for longer-term, fuzzy initiatives.
How to Define Themes / Initiatives
Themes should be goal-driven. If executive alignment can be obtained on the goals first, it becomes easier to create Themes that align with those goals. As part of the goal setting it's essential to discuss the metrics and KPIs that define whether the identified goal has been met. Rather than focusing on "what" Features the Customer wants, focus on "why" they want them. This will help in prioritizing upcoming work, removing the tendency to focus on the inclusion of new, specific Features and instead guiding the focus to be more about solving Customer problems.
Themes are added to, and referenced via, the Solution Roadmap on which they appear as Lanes. A Roadmap with no Themes may have just a single lane for all planned work.
When establishing a Theme, some of the following attributes should be considered:
- Anticipated target Release Date, which may be specific (e.g., YYYY-MM-DD) or generic (2017 Q3);
- A Name or Title by which to refer to the Theme;
- A description of the Goal to be achieved;
- A list of Features that will be necessary to achieve the Goal;
- The Metrics / KPIs that will demonstrate that the Goal has been met.
Note that not all Features must belong to a Theme. Anticipate that any given Release may include both goals to achieve (as represented by a Theme and related Features), and other independent, stand-alone Features.
While the Solution is young expect a higher degree of uncertainty and change. During this stage a goal-orientation (as opposed to a Feature-orientation) is preferable from a planning perspective. As the Solution matures, expect Themes to play a lesser role and the planning to become more Feature-focused. That is, as the Solution matures, the Release Planning effort will focus increasingly on a Feature-orientation and less so on Theme-orientation.
Tips for Creating Themes / Initiatives
The Customer's long-term strategic initiatives are a good place to start for identifying Themes. Identify and select just a few high-level initiatives to accomplish at any one time.  Give consideration to small, achievable, incremental Themes such that most Releases deliver new, incremental value to the Customer(s).
The number of Themes will depend upon the scope and scale of the related Solution, as well as the number of Teams involved in the Solution's delivery. A long-term, broadly scoped Solution such as an ERP implementation will have room for dozens of Themes, whereas a small System implementation may not benefit from Themes at all. And a Solution which involves 4 Teams working concurrently will have more benefit from Themes than a Solution with a single Team.
Unlike Features (which must fit within the timeframe of a Release) and Stories (which must fit within the timeframe of a Sprint) a Theme has no bounds. A Theme may be completed within a single Release, or it may span multiple Releases. Similarly, whereas a Feature aligns to a single Epic and a Story aligns to a single Feature, Themes may include myriad Features and/or Stories from multiple Epics. However, a Theme is not a Capability. There should just be some common goal which relates the Features included.
A note of caution when using Themes: stakeholders may tend to fill in the blanks about what a Theme includes, leading to mismanaged expectations.  Education is an important part of communicating the Roadmap and the work being done in each Release. Inform stakeholders about: how a Theme was defined; how its success will be measured: and provide some insight as to what is (and is not) included. Doing so will help ensure expectations are met and that no gaps or surprises arise as completion of the Features within the Theme approaches. This helps to ensure on-time and on-budget delivery of Solution functionality.