Skip to Content
Product Information
Author's profile photo Jagmohan Singh Chawla

What is what in SAP Cloud ALM for Implementation

In this blog post, I would like to explain various entities in SAP Cloud ALM and explain how they are connected

You have things that are Project specifics such as scopes and Requirements and things that are project independent such as Deployment Plan and Release.



Something with a purpose with dates, teams, scope, requirements, features, and user stories. It can be used for “Continuous Implementation” which means running perpetually

Project Specific Entities


A way to depict timelines of a single Project


The initial list comes from Activate but you can add custom phases


Optionally you can create sprints associated with Phases


Depict key events associated with a phase



A Collection of Business Processes that need to be handled together. You create a Scope and then first assign Solution Scenarios such as SAP S4HC with a particular content version and then pick processes from those Solution scenarios



A series of steps following BPMN notation explaining a business functionality, typically used in Fit to Standard workshops. You get standard content from SAP but you can create your own custom processes using the editor. You can associate Requirements, User Stories, and Project tasks to a process


Teams currently exist within a Project. A team is made of multiple roles and each role contains multiple persons.

PMO Team

a special Team that is delivered by default. This is the only team that contains the Project lead and this team can not be deleted. You can change the name of this team


Project task

An activity that needs to be performed. This is created by the Project team and can be edited or deleted

Template task

Content delivered by SAP whose description can not be edited. If not required, this can be set to a state “Obsolete” and then deleted


A business need that typically needs to be processed for approval and is later decomposed into smaller items such as Project tasks and user stories

User Story

A functional detail of Requirement. User stories can also be directly created from the process and may depict pre-approved requirements or change requests coming from Production incidents that do not need approval


A child of Template task. Project task or user story. Used to distribute work between team members



The entity that is required to document change records and move functionality to production. One Requirement can have multiple features but a feature can have only one Requirement. Multiple user stories can belong to a Feature

Test case

a vehicle for testing that can be attached to a Requirement or a user story



A record indicating a functionality not working properly


Please note that these are not the official definitions and this list is not comprehensive. You can visit the links below in SAP Glossary for more details

Project Independent Entities

Deployment Plan

A series of timelines were created for deployment purposes. Multiple projects can refer to the same Release but one Project can have just one Release


Deployment Plan contains Releases. Releases have start and end dates and can be assigned to Requirements, User Stories, and Features


A list of typical responsibilities. You get the initial list from the SAP Activate methodology but you can add your own list of roles. you can assign multiple persons to the same role in a Project and use roles for task assignments if you work in a ‘pull’ fashion and have self-empowered teams.



Different systems that are used by Projects and Releases



An aggregation dimension for Requirements, user stories, and Features. Currently, a controlled list that comes from SAP Activate methodology



Community-driven classification that can be attached to Requirements, Tasks, User stories, and defects



Next Steps

As we publish more and more blog posts, it’s easy to get lost. Please visit the Master Blog post and bookmark it.

To understand an end-to-end picture, please visit

Expert Portal for Implementation and stay connected




Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Lorie Schenck
      Lorie Schenck

      I really like this visual!  very nice!


      The definitions are very helpful and the image can be overlayed with Quality Assurance as well.  Nicely done!

      Lets talk more about Implementation Projects in CALM!!

      if we build it here, we have the data for the solution so we can monitor, change, update, and INNOVATE!!


      Lorie Schenck




      Author's profile photo Robin Schoenwald
      Robin Schoenwald

      You can assign User Stories and Tasks to a Timebox (Sprints, for example). Why isn't it possible to assign a Requirement or a Feature to a Timebox?

      Author's profile photo Jagmohan Singh Chawla
      Jagmohan Singh Chawla
      Blog Post Author

      According to our design , Requirements follow a timeline that is provided by Release and Release versions. The business indicates the expected date of Deployment by associating a Release version to a Requirement.




      Author's profile photo Robin Schoenwald
      Robin Schoenwald

      Obvious. But there are some good reasons to assign also requirements (and maybe features) to a Timebox:

      • You can work without Releases and Release versions. It can be time-consuming and error-prone to synchronize the release versions with the sprints and timeboxes, as these have to be maintained independently. If you have only one project and the releases are defined exclusively by sprints - why create release versions?
      • A requirement can be small and simple so that you can implement it without further decomposition. In this case - or if you have a requirement based implementation approach - I would like to assign a requirement also to a timebox.
      • You can create tasks and user stories in the context of a requirement. Both items can be assigned to a time box but the parent - the requirement - not? Sounds not logical.

      SAP Cloud ALM is very open for all kind of implementation methods, agile, waterfall, hybrid. This one seems like an unnecessary restriction.

      Author's profile photo Jagmohan Singh Chawla
      Jagmohan Singh Chawla
      Blog Post Author

      Thanks for your feedback. Timeboxes for requirements are now available




      Author's profile photo Robin Schoenwald
      Robin Schoenwald


      Author's profile photo Juan Janse
      Juan Janse

      When you define requirements (Explore phase) why is it not possible to also define a highlevel story point to the requirement before decomposition?

      I see the following advantages

      • This would help identify requirements that need decomposition into user stories.
      • Provide the input for the Sprint planning
      • Provide a better overview of the effort needed to be completed.

      I think here it would be nice to have the possibility that if a requirement has a Story point assigned and you create a user story that you would get the option to distribute the story points to the underlying components (1-n User stories)

      Anyway, thanks