The Path of a Business Requirement through the Scaled Agile Framework

Dean Leffingwell's Scaled Agile Framework® is a collection of best practices to scale agility to the development of a comprehensive product or product group (Value Stream). The framework is freely accessible and is constantly evolving. In addition, the approaches and methods have already been tested several times in reality. However, specific adaptations are absolutely necessary when using the framework in your own company. However, these should be critically scrutinized and SAFe® Best Practices should be closely examined.
In this blog, we want to take a closer look at the path from a business requirement to the implementation task according to SAFe® Best Practice. We look at the three levels of the Scaled Agile Frameworks® and the corresponding backlogs.

Step 1: New => Portfolio Backlog
At the portfolio level, business and architecture requirements are worked out and evaluated in a portfolio kanban process. During the elaboration process, it is continuously checked whether further processing seems sensible. The result of this process is a "Lightweight Business Case" per Epic (Business/Architectural), which is ranked in the portfolio backlog for further processing. The latter is an ordered list of Epics proposed for implementation. The "Lightweight Business Case" contains statements on costs/benefits, technical and business performance. Motivation, risks of non-implementation, etc.

Step 2: Portfolio Backlog => Program Backlog
When an Epic is selected from the portfolio backlog for implementation, the Epic Owner, in collaboration with Product Management, splits the Epic into features according to technical criteria. A feature consists of a title and a brief description of the goal. In addition, a feature is roughly estimated, weighted/prioritized, and described by acceptance criteria. The created features are stored in the program backlog sorted by weighting. Features selected for implementation are the input for the release planning meeting.

Step 3: Program Backlog => Team Backlog
In the two-day release planning meeting, the selected features are distributed to the agile teams (PO, SM, Dev-Team). Each team develops the user stories to be implemented from the assigned features. These are estimated and planned for the implementation iterations of the next Agile Release Train. Necessary input from other teams is mapped using a dependency matrix. The stories created are then placed in the respective team backlogs.
Excursus: Release planning is more than just a planning meeting => the content is being worked on!
The result of the release planning meeting are about 4 planned sprints. Planning accuracies for sprints that lie further in the future are taken into account by a lower (planned) utilization.

Step 4: Team Backlog => Iteration Planning
At the team level, an iteration planning is carried out by the team at the beginning of each iteration. This involves checking the plan created (from Release Planning) and deriving conversion tasks from the scheduled user stories. The implementation of the requirements then begins.

As far as the theory, ...
... but how do I depict this in my company?

In reality, I haven't yet seen a SAFe® implementation that accurately depicts these work steps. The two biggest discrepancies are usually the implementation of the portfolio level and the question "How should the input ideally be prepared for release planning?
In particular, the company-specific answer to the last question reveals how far the company is on the way to becoming an agile organization.

A plausible answer would be:
"Since it is a very expensive event, we prepare the contents in detail. It would be best if we create the user stories in advance and distribute them to the team members who ideally implement them. So the participants can concentrate on what concerns them (and maybe we can do it in one instead of two days)."

A more mature and Scaled Agile Framework® response might sound that way:
"We prepare the infrastructure of the event so that the teams can work without restrictions during the event. We select the most important features in advance and have them worked out by the teams. If it becomes clear during the meeting that we can do more, we will deliver additional features. The product owners know the goal of their features and try to implement it with the teams in user stories. At the end of the two days, everyone involved should know when they're going to do the next 4 sprints and why they're doing it."With the blog and the two possible answers I've outlined, I want to make it clear that the Scaled Agile Framework® only provides a framework - in my opinion, well thought-out - that is, a framework that can be used to help you to make the right decisions. Within this framework an agile organization can grow. However, the Scaled Agile Framework® is not a blueprint or instruction to follow to succeed.