Product Information
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.
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
Project Specific Entities
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
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
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
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
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
Release
Deployment Plan contains Releases. Releases have start and end dates and can be assigned to Requirements, User Stories, and Features
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.
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
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
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
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?
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
Obvious. But there are some good reasons to assign also requirements (and maybe features) to a Timebox:
SAP Cloud ALM is very open for all kind of implementation methods, agile, waterfall, hybrid. This one seems like an unnecessary restriction.
Thanks for your feedback. Timeboxes for requirements are now available
Regards
Jag
😊👍
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
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
regards
Juan