Before we get into the topic of this lesson, I would like to define the term “business unit” in this course series:

A business unit does not refer to a department such as the human resources department, the manufacturing department, the logistics department, etc. in the company, but rather, for example, the railroad technology, energy technology, medical technology, etc. department. Accordingly, a business unit management manages relatively independent company units, which themselves have all departments. But now to the subject.

Today, when someone in a project tells me they have a requirement, my first reaction is: what kind of requirement? And the “what” then refers not to the content, but what granularity the requirement has. Is it a requirement from the management, already more specified from the division management? Or is it a requirement that has only arisen within a program during the course of the project? Has it already been broken down to requested performance features or even described in the department ready for implementation with all acceptance criteria? Or is it a requirement of a general nature, such as a performance definition? Is it a customer requirement, an infrastructure requirement coming from the team, or a requirement for a third-party solution needed to solve it?

In order to map this step-by-step specification of requirements from management to the participating specialist department, there are requirements objects in agile.

Fig.: Portfolio Epic – *Source reference: 07

The top requirement object is the “Portfolio Epic”. It describes a request for solution development from senior management, which in large companies is usually addressed to divisional management.

Fig.: Epic Owner – *Source reference: 07

The author of a Portfolio Epic is called the Portfolio Epic Owner and represents the business management area under whose responsibility the requirement falls. The Epic Owner is sometimes supported in his work by an Enterprise Architect. The Enterprise Architect is often an external business consultant with the experience to develop the business in the required direction.

Fig.: Capability – *Source reference: 07

Area managers typically work together to derive requirements from a Portfolio Epic, deciding whether the requirement affects the area at all, and if so, what area requirements are needed to implement it. For the requirements from the areas there is the requirement object “Capability”. The implementation of the requirement from a Portfolio Epic is usually described with several Capabilities.

Fig.: Large Solution Roles – *Source reference: 07

The division management is partially supported in its work by Solution Architects and a solution management team, which is responsible for cross-divisional solution development.

The Capabilities from the divisions are presented to the management, jointly agreed upon and, if necessary, adapted so that the Capabilities can be used by all divisions. In the interest of cost-effectiveness, it is important to avoid special solutions for areas, because all underlying requirements would otherwise have to be implemented in parallel with duplicate or multiple efforts in parallel solutions. The goal is always a solution development that works for all areas by as few project teams as possible – not only because of the reduction of effort, but also to keep the overview and the possibility of cooperation in the company as well as to remain flexible in the future in case of restructuring of the company areas.

The Large Solution level is particularly useful for large enterprises where one solution must serve multiple business units. Capability is not applicable without Large Solution level. In this case, the features for the requirement are defined immediately from the Portfolio Epic.

However, the Large Solution level is also an excellent place to organize and implement cross-program project basics. Therefore, I suggest this additional layer to anyone who has to support several programs in the project – even if it is only to serve one business unit.

In the Portfolio and Large Solution level, only strategic and technical requirements are described. It would be bad if technical requirements from the upper two levels limited or even prevented actual technical requirements at the program level. Technical requirements can therefore be described at the earliest with the expertise from the departments and their coordination with each other in the program level that now follows.

Fig.: Feature – *Source reference: 07

Depending on the scaling, a Large Solution level from the Capability or without a Large Solution level from the Portfolio Epic is used to describe the necessary Features for the requirement. Each Feature is described in a separate requirements object. The Program level is already in the middle management in the company hierarchy, i.e. IT management, personnel management, production management or, as in our focus, software development management. We also refer to these department heads in agile as Business Owners because they are responsible for their departments. We are now also in middle management because the definition of Features already requires specialist knowledge from the departments, which cannot be expected in management. In addition, at this level, the project is divided among different departments that are expected to work together to deliver a working solution. Each department then executes its Program from the project and returns as a result its partial solutions coordinated with the other Programs in terms of time and content.

In addition to defining Features for an overlying requirement object, a Program can also describe an entirely new requirement that has only arisen with expertise from a department. This additional requirement object above the feature is then called “Program Epic”. Again, the required Features of this object are described.

Fig.: Program Roles – *Source reference: 07

The department managers are supported by System Architects and a Product Management Team so that the requirements from all departments describe a solution that works for everyone.

Fig.: User Story – *Source reference: 07

A team from one or more departments is given a Feature from the Program as a basis for work and contributes its very specific requirements to a solution in the form of Stories (also called User Stories). Since many teams are usually entrusted with the requirements determination in parallel, the teams must coordinate with each other in such a way that, similar to the Large Solution level, a solution is described that is suitable for all – both in terms of content and time!

Fig.: Team Roles – *Source reference: 07

In Scrum, each team has a Scrum Master and a Product Owner for the partial solution to be developed. The Product Owner is in close contact with Product Management in order to steer the requirements definition in the planned direction of the levels above. The Scrum Master is in close contact with the Release Train Engineer (RTE in this case) to coordinate the delivery of the partial solution with other teams in a way that ensures a working solution in the Program at the end of each Product Increment. The RTEs, in turn, are in close contact with the Solution Train Engineers (also called STE) from the Large Solution level, so that the delivered releases of all individual Programs are coordinated in such a way that all components, i.e.: software, change management, IT, building management, etc., result in an overall solution that is as perfect as possible for the user, which can then be used in a value-creating manner. And the STE is again in close exchange with the division managers, who always keep an eye on implementation. The management itself is informed about appropriate tools and KPIs.

With this, we would have described the basic requirement objects.

The requirement object of the “Nonfunctional Requirement” then takes on a special role. This requirement can be described at any level – from Portfolio to Team – and is then additionally applicable to all assigned requirement objects. An example is the definition that a requirement (Portfolio Epic, Capability, Program Epic, Feature, or Story) must work under described conditions. In the case of software, this can be loading times, or a certain resolution, or a bandwidth restriction to be complied with, anything of this kind.

So far, we have only described customer requirements. In addition, there are also requirements from our own team. These would be, for example, infrastructure requirements, requirements for the elimination of bugs or requirements for suppliers regarding third-party solutions used. In the team, all these requirements are described in Stories. To be precise, customer requirements in User Stories and internal team requirements in Stories. In everyday life, however, no distinction is made. The same requirement object is simply used and differentiated via a requirement object attribute.

Fig.: Stream/Train Hierarchy

I would now like to very briefly address a foundation that will help us better understand the next lessons, even though this content is not about requirements objects, but about tools for organizing requirements.

The agile tool of the Value Stream collects challenges from the Portfolio level (here e.g. Challenge 1) and breaks them down into requirements (here e.g. Req. 1 to Challenge 1).

Solutions are developed for the requirements in the Solution Train (here e.g. Solution Release 1 + 2). The solution is divided into work packages, namely the releases, and structured in terms of both content and time. In the Solution Train, the Solution Releases are in turn broken down into smaller units that are easier to fulfill, the Solution Increments.

The delivery content for the Solution Increments is planned in the Release Train. Each release fulfills a Solution Increment. Not all delivery content is immediately made available in a release, but rather multiple Release Increments are typically collected by a wide variety of teams before being published for use in a working release.

The content for the Release Increments is agreed by the Business Owners and the Project Teams as part of the Product Increment Planning (then called PI Planning) and then implemented in time-limited Sprints.

• A Value Stream is usually divided into several Solution Trains
• A Solution Train is usually divided into several Release Trains
• A Release Train is usually divided into several Product Increments

• The work content of the Sprints ends up in the Product Increment,
• the contents of the Product Increment end up in the Release Increment,
• several Release Increments form a Release,
• a Release serves a Solution Increment,
• several Solution Increments form a Solution Release,
• a Solution Release serves a requirement from a challenge and
• multiple requirements satisfy a challenge.

And that makes the whole thing round. With this understanding, it should be easier for you to understand the following lessons and the logic behind them. So in the next lessons, we’ll look at these streams and trains, and in which streams and trains which requirements objects are planned and where solutions are delivered. You mean that sounds weird? Wait and see, that’s where the course content from the project management basics we’ve already covered blends in nicely.