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 Release and Release versions.

Project

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

Timebox

A way to depict timelines of a single Project

Phase

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

Sprint

Optionally you can create sprints associated with Phases

Milestone

Depict key events associated with a phase

Release

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

Release version

Release contains Release versions. Release versions have start and end dates and can be assigned to Requirements, User Stories, and Features

Scope

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

 

Process

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

Roles

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.

Teams

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

Requirement

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

Sub-task

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

 

Feature

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

Landscape

Different systems that are used by Projects and Releases

 

Workstreams

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

 

Tags

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

 

Test case

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

 

Defect

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

 

https://help.sap.com/glossary/?search=SAP%2520Cloud%2520ALM

https://help.sap.com/glossary/?locale=en-US&search=SV-CLM

 

 

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

      4 Comments
      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!!

      Warmly,

      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.

       

      Regards

      Jag

      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.