Projects orchestration in SAP Cloud ALM - latest u...

Alexander_Korne · ‎2022 Aug 12

Introduction

As there are some recent changes in SAP Cloud ALM terminology for projects orchestration, let´s check, how it changes processes, described in blog posts Going SCRUM with SAP Cloud ALM and Binding SCRUM in SAP Cloud ALM with SAP Activate.

New terminology

First of all, let´s define Deployment plan. It is a collection of timelines that can be assigned to multiple Projects. So it is the biggest entity, available for projects orchestration. And it is important to mention, that one Project can be assigned to only one Deployment plan.

By timelines in Deployment plan we mean Releases. We can assign Release to Requirements to indicate, when we expect certain functionality should be available. Or we can assign Release to Features for deployment planning and execution.

What changed

To understand, what has been changed, let´s remember, how hierarchy of entities looked out earlier.

We had a Project in Cloud ALM, and for one project we had one Release. In terms of the Release we were able to have Release versions (or Waves in Scrum terminology). Then we split them to Sprints, and were able to have multiple SAP Cloud ALM User stories, Requirements, Tasks and Transport Requests.

The new hierarchy has 2 main changes:

as SAP Cloud ALM solution becomes more and more mature, number of cases with multiple simultaneous projects also grow. So now we can combine them in Deployment plan.

and there are no Release versions anymore for the the sake of simplicity. Instead of this we can have multiple Releases in one Project:

The new schema will look then as following:

And there would be following binding to the SAP Activate methodology:

Practical example

So, let´s take a look, how we can organize SAP S/4HANA Cloud 3SL implementation project within this slightly changed methodology.

Initial implementation means using one Project, which would be "nested" in one Deployment plan. If it is necessary to activate several countries in the solution, it is recommended to have one Release (or Wave) for each country. And Spints can be used then to customize and transport Solution Processes separately for each LoB.

If it is necessary to proceed with various extensions afterwards, the same Deployment plan can be used in order to avoid repeated customizing of landscape in SAP Cloud ALM Project.

Conclusion

The introduced improvements simplify projects´ orchestration in SAP Cloud ALM and harmonize SAP Cloud ALM terminology with general Scrum approach.