Common use of Scrum Lifecycle Clause in Contracts

Scrum Lifecycle. (1) SAP will designate a contact person (“Product Owner”) to discuss Customer’s Requirements and their priorities. The Product Owner will be responsible for managing the Product Backlog and for assigning the final priorities taking into account Customer’s business needs, the technical feasibility and the dependencies. (2) The Vision & Scope Document and the initial version of the Product Backlog are already available and attached to the applicable Order Form. SAP will start directly with the first Sprint. (3) As a prerequisite for Product Backlog Items to become part of a Sprint, they have to be specified in sufficient detail in the Product Backlog including description, acceptance criteria and prioritization. The SAP Product Owner continuously works together with Customer to break down and refine those Product Backlog Items that are not yet specified to the necessary level of detail. Refined Product Backlog Items result in new versions of the Product Backlog, which SAP submits to Customer for confirmation as described in this Supplement. (4) At the beginning of each Sprint SAP will conduct a planning meeting to decide which Product Backlog Items will be realized as Features by SAP in the Sprint. After the planning meeting SAP will inform Customer of the Sprint Scope. The respective Product Backlog Items are now considered fixed and cannot be altered during the Sprint. (5) At the end of each Sprint a review meeting will take place in which SAP will present to Customer the Features that have been developed during the Sprint. SAP will send via e-mail to Customer minutes of the Sprint review meeting for Customer to confirm. The minutes will reflect the Product Backlog Items that SAP considers completed and Customer’s objections to the demonstrated Features, if any. Customer must confirm or reject the Sprint review meeting minutes via e- mail within a period of five working days as of their submission. Customer’s confirmation or rejection must be based on the description of the Product Backlog Item and on the corresponding acceptance criteria. If Customer confirms or does not reject via e-mail the minutes of the Sprint review meeting within the five working days, the completed Product Backlog Items will move to status “confirmed”. As far as a Product Backlog Item is rejected, the status will remain “in progress“ and necessary adjustments will be made during one of the upcoming development Sprints, or latest during the integration test. (6) During the Build Phase and until Customer’s acceptance of all Features, both parties can request changes to the CAE Services (herein: “Change Request”). Customer can request changes to Product Backlog Items (including already confirmed Product Backlog Items) at any time, except during the Sprint where the respective Product Backlog Items are realized. SAP will investigate the possibilities of making the changes and inform Xxxxxxxx accordingly. a) If the requested changes have an impact on the total effort and price, Customer has to follow the Change Request procedure. b) If the requested changes do not have an impact on the total effort and price, and if SAP agrees to, SAP will create a new version of the Product Backlog and will submit it to Customer for confirmation. (7) The content of an already agreed version of the Product Backlog can only be changed in case of an agreement between the parties. In case of contradiction between versions of the Product Backlog, the most recently confirmed version will prevail over the others. (8) The last confirmed version of the Product Backlog will constitute the final version of the Product Backlog. Together with the Vision & Scope Document, it is the only contractually binding description of the Features and constitutes the basis for the acceptance of the Features by Customer. In case of inconsistencies between the Vision & Scope Document and the final version of the Product Backlog, the final version of the Product Backlog shall prevail. (9) Upon completion of the Features, SAP will execute an integration test of all developed Features based on test cases provided by Customer. (10) After SAP has completed the integration test, SAP will make the Features available for Customer in a development and/or test system landscape. Once SAP declares towards Customer readiness for Acceptance Testing of the Features, the period for conducting Acceptance Tests begins.

Scrum Lifecycle. (1) SAP will designate a contact person (“Product Owner”) to discuss Customer’s Customer Requirements and their priorities. The Product Owner will be responsible for managing the Product Backlog and for assigning the final priorities taking into account Customer’s business needs, the technical feasibility and the dependencies. (2) The Vision & Scope Document and According to the Scrum Lifecycle SAP will start the development of the Features based on the initial version of the Product Backlog. a) If no initial version of the Product Backlog is available, SAP will create the initial version of the Product Backlog are already available and based on the Customer Requirements as described in the Solution Proposal attached to the applicable Order Form. The initial version of the Product Backlog must be formally accepted by Customer. The first Sprint starts after acceptance of the initial version of the Product Backlog. b) If the initial version of the Product Backlog is already available, it will be attached to the applicable Order Form and SAP will start directly with the first Sprint. (3) As a prerequisite for Product Backlog Items to become part of a Sprint, they have to be specified in sufficient detail in the Product Backlog including description, acceptance criteria and prioritization. The SAP Product Owner continuously works together with Customer to break down and refine those Product Backlog Items that are not yet specified to the necessary level of detail. Refined Product Backlog Items result in new versions of the Product Backlog, which SAP submits to Customer for confirmation as described in this Supplement. (4) At the beginning of each Sprint SAP will conduct a planning meeting to decide which Product Backlog Items will be realized as Features by SAP in the Sprint. After the planning meeting SAP will inform Customer of the Sprint Scope. The respective Product Backlog Items are now considered fixed and cannot be altered during the Sprint. (5) At the end of each Sprint a review meeting will take place in which SAP will present to Customer the Features that have been developed during the Sprint. SAP will send via e-mail to Customer minutes of the Sprint review meeting for Customer to confirm. The minutes will reflect the Product Backlog Items that SAP considers completed and Customer’s objections to the demonstrated Features, if any. Customer must confirm or reject the Sprint review meeting minutes via e- e-mail within a period of five working days as of their submission. Customer’s confirmation or rejection must be based on the description of the Product Backlog Item and on the corresponding acceptance criteria. If Customer confirms or does not reject via e-mail the minutes of the Sprint review meeting within the five working days, the completed Product Backlog Items will move to status “confirmed”. As far as a Product Backlog Item is rejected, the status will remain “in progress“ and necessary adjustments will be made during one of the upcoming development Sprints, or latest during the integration test. (6) During the Build Phase and until Customer’s acceptance of all Features, both parties can request changes to the CAE Services (herein: “Change Request”). Customer can request changes to Product Backlog Items (including already confirmed Product Backlog Items) at any time, except during the Sprint where the respective Product Backlog Items are realized. SAP will investigate the possibilities of making the changes and inform Xxxxxxxx accordingly. a) If the requested changes have an impact on the total effort and price, Customer has to follow the Change Request procedure. b) If the requested changes do not have an impact on the total effort and price, and if SAP agrees to, SAP will create a new version of the Product Backlog and will submit it to Customer for confirmation. (7) The content of an already agreed version of the Product Backlog can only be changed in case of an agreement between the parties. In case of contradiction between versions of the Product Backlog, the most recently confirmed version will prevail over the others. (8) The last confirmed version of the Product Backlog will constitute the final version of the Product Backlog. Together with the Vision & Scope Document, it It is the only contractually binding description of the Features and constitutes the basis for the acceptance of the Features by Customer. In case of inconsistencies between the Vision & Scope Document and the final version of the Product Backlog, the final version of the Product Backlog shall prevail. (9) Upon completion of the Features, SAP will execute an integration test of all developed Features based on test cases provided by Customer. (10) After SAP has completed the integration test, SAP will make the Features available for Customer in a development and/or test system landscape. Once SAP declares towards Customer readiness for Acceptance Testing of the Features, the period for conducting Acceptance Tests begins.

Scrum Lifecycle. (1) SAP will designate a contact person (“Product Owner”) to discuss Customer’s Customer Requirements and their priorities. The Product Owner will be responsible for managing the Product Backlog and for assigning the final priorities taking into account Customer’s business needs, the technical feasibility and the dependencies. (2) The Vision & Scope Document and According to the Scrum Lifecycle SAP will start the development of the Features based on the initial version of the Product Backlog. a) If no initial version of the Product Backlog is available, SAP will create the initial version of the Product Backlog are already available and based on the Customer Requirements as described in the Solution Proposal attached to the applicable Order Form. The initial version of the Product Backlog must be formally accepted by Customer. The first Sprint starts after acceptance of the initial version of the Product Backlog. b) If the initial version of the Product Backlog is already available, it will be attached to the applicable Order Form and SAP will start directly with the first Sprint. (3) As a prerequisite for Product Backlog Items to become part of a Sprint, they have to be specified in sufficient detail in the Product Backlog including description, acceptance criteria and prioritization. The SAP Product Owner continuously works together with Customer to break down and refine those Product Backlog Items that are not yet specified to the necessary level of detail. Refined Product Backlog Items result in new versions of the Product Backlog, which SAP submits to Customer for confirmation as described in this Supplement. (4) At the beginning of each Sprint SAP will conduct a planning meeting to decide which Product Backlog Items will be realized as Features by SAP in the Sprint. After the planning meeting SAP will inform Customer of the Sprint Scope. The respective Product Backlog Items are now considered fixed and cannot be altered during the Sprint. (5) At the end of each Sprint a review meeting will take place in which SAP will present to Customer the Features that have been developed during the Sprint. SAP will send via e-mail to Customer minutes of the Sprint review meeting for Customer to confirm. The minutes will reflect the Product Backlog Items that SAP considers completed and Customer’s objections to the demonstrated Features, if any. Customer must confirm or reject the Sprint review meeting minutes via e- mail within a period of five working days as of their submission. Customer’s confirmation or rejection must be based on the description of the Product Backlog Item and on the corresponding acceptance criteria. If Customer confirms or does not reject via e-mail the minutes of the Sprint review meeting within the five working days, the completed Product Backlog Items will move to status “confirmed”. As far as a Product Backlog Item is rejected, the status will remain “in progress“ and necessary adjustments will be made during one of the upcoming development Sprints, or latest during the integration test. (6) During the Build Phase and until Customer’s acceptance of all Features, both parties can request changes to the CAE Services (herein: “Change Request”). Customer can request changes to Product Backlog Items (including already confirmed Product Backlog Items) at any time, except during the Sprint where the respective Product Backlog Items are realized. SAP will investigate the possibilities of making the changes and inform Xxxxxxxx accordingly. a) If the requested changes have an impact on the total effort and price, Customer has to follow the Change Request procedure. b) If the requested changes do not have an impact on the total effort and price, and if SAP agrees to, SAP will create a new version of the Product Backlog and will submit it to Customer for confirmation. (7) The content of an already agreed version of the Product Backlog can only be changed in case of an agreement between the parties. In case of contradiction between versions of the Product Backlog, the most recently confirmed version will prevail over the others. (8) The last confirmed version of the Product Backlog will constitute the final version of the Product Backlog. Together with the Vision & Scope Document, it It is the only contractually binding description of the Features and constitutes the basis for the acceptance of the Features by Customer. In case of inconsistencies between the Vision & Scope Document and the final version of the Product Backlog, the final version of the Product Backlog shall prevail. (9) Upon completion of the Features, SAP will execute an integration test of all developed Features based on test cases provided by Customer. (10) After SAP has completed the integration test, SAP will make the Features available for Customer in a development and/or test system landscape. Once SAP declares towards Customer readiness for Acceptance Testing of the Features, the period for conducting Acceptance Tests begins.

Scrum Lifecycle. (1) SAP will designate a contact person (“Product Owner”) to discuss Customer’s Customer Requirements and their priorities. The Product Owner will be responsible for managing the Product Backlog and for assigning the final priorities taking into account Customer’s business needs, the technical feasibility and the dependencies. (2) The Vision & Scope Document and According to the Scrum Lifecycle, SAP will start the development of the Features based on the initial version of the Product Backlog. a) If no initial version of the Product Backlog is available, SAP will create the initial version of the Product Backlog are already available and based on the Customer Requirements as described in the Solution Proposal attached to the applicable Order Form. The initial version of the Product Backlog must be formally accepted by Customer. The first Sprint starts after acceptance of the initial version of the Product Backlog. b) If the initial version of the Product Backlog is already available, it will be attached to the applicable Order Form and SAP will start directly with the first Sprint. (3) As a prerequisite for Product Backlog Items to become part of a Sprint, they have to be specified in sufficient detail in the Product Backlog including description, acceptance criteria and prioritization. The SAP Product Owner continuously works together with Customer to break down and refine those Product Backlog Items that are not yet specified to the necessary level of detail. Refined Product Backlog Items result in new versions of the Product Backlog, which SAP submits to Customer for confirmation as described in this Supplement. (4) At the beginning of each Sprint SAP will conduct a planning meeting to decide which Product Backlog Items will be realized as Features by SAP in the Sprint. After the planning meeting SAP will inform Customer of the Sprint Scope. The respective Product Backlog Items are now considered fixed and cannot be altered during the Sprint. (5) At the end of each Sprint a review meeting will take place in which SAP will present to Customer the Features that have been developed during the Sprint. SAP will send via e-mail to Customer minutes of the Sprint review meeting for Customer to confirm. The minutes will reflect the Product Backlog Items that SAP considers completed and Customer’s objections to the demonstrated Features, if any. Customer must confirm or reject the Sprint review meeting minutes via e- mail within a period of five working days as of their submission. Customer’s confirmation or rejection must be based on the description of the Product Backlog Item and on the corresponding acceptance criteria. If Customer confirms or does not reject via e-mail the minutes of the Sprint review meeting within the five working days, the completed Product Backlog Items will move to status “confirmed”. As far as a Product Backlog Item is rejected, the status will remain “in progress“ and necessary adjustments will be made during one of the upcoming development Sprints, or latest during the integration test. (6) During the Build Phase and until Customer’s acceptance of all Features, both parties can request changes to the CAE Services (herein: “Change Request”). Customer can request changes to Product Backlog Items (including already confirmed Product Backlog Items) at any time, except during the Sprint where the respective Product Backlog Items are realized. SAP will investigate the possibilities of making the changes and inform Xxxxxxxx accordingly. a) If the requested changes have an impact on the total effort and price, Customer has to follow the Change Request procedure. b) If the requested changes do not have an impact on the total effort and price, and if SAP agrees to, SAP will create a new version of the Product Backlog and will submit it to Customer for confirmation. (7) The content of an already agreed version of the Product Backlog can only be changed in case of subject to an agreement between the parties. In case of contradiction between versions of the Product Backlog, the most recently confirmed version will prevail over the others. (8) The last confirmed version of the Product Backlog will constitute the final version of the Product Backlog. Together with the Vision & Scope Document, it It is the only contractually binding description of the Features and constitutes the basis for the acceptance of the Features by Customer. In case of inconsistencies between the Vision & Scope Document and the final version of the Product Backlog, the final version of the Product Backlog shall prevail. (9) Upon completion of the Features, SAP will execute an integration test of all developed Features based on test cases provided by Customer. (10) After SAP has completed the integration test, SAP will make the Features available for Customer in a development and/or test system landscape. Once SAP declares towards Customer confirms readiness for Acceptance Testing of the Features, the period for conducting Acceptance Tests begins.

Scrum Lifecycle. (1) SAP will designate a contact person (“Product Owner”) to discuss Customer’s Customer Requirements and their priorities. The Product Owner will be responsible for managing the Product Backlog and for assigning the final priorities taking into account Customer’s business needs, the technical feasibility and the dependencies. (2) The Vision & Scope Document and According to the Scrum Lifecycle SAP will start the development of the Features based on the initial version of the Product Backlog. a) If no initial version of the Product Backlog is available, SAP will create the initial version of the Product Backlog are already available and based on the Customer Requirements as described in the Solution Proposal attached to the applicable Order Form. The initial version of the Product Backlog must be formally accepted by Customer. The first Sprint starts after acceptance of the initial version of the Product Backlog. b) If the initial version of the Product Backlog is already available, it will be attached to the applicable Order Form and SAP will start directly with the first Sprint. (3) As a prerequisite for Product Backlog Items to become part of a Sprint, they have to be specified in sufficient detail in the Product Backlog including description, acceptance criteria and prioritization. The SAP Product Owner continuously works together with Customer to break down and refine those Product Backlog Items that are not yet specified to the necessary level of detail. Refined Product Backlog Items result in new versions of the Product Backlog, which SAP submits to Customer for confirmation as described in this Supplement. (4) At the beginning of each Sprint SAP will conduct a planning meeting to decide which Product Backlog Items will be realized as Features by SAP in the Sprint. After the planning meeting SAP will inform Customer of the Sprint Scope. The respective Product Backlog Items are now considered fixed and cannot be altered during the Sprint. (5) At the end of each Sprint a review meeting will take place in which SAP will present to Customer the Features that have been developed during the Sprint. SAP will send via e-mail to Customer minutes of the Sprint review meeting for Customer to confirm. The minutes will reflect the Product Backlog Items that SAP considers completed and Customer’s objections to the demonstrated Features, if any. Customer must confirm or reject the Sprint review meeting minutes via e- mail within a period of five working days as of their submission. Customer’s confirmation or rejection must be based on the description of the Product Backlog Item and on the corresponding acceptance criteria. If Customer confirms or does not reject via e-mail the minutes of the Sprint review meeting within the five working days, the completed Product Backlog Items will move to status “confirmed”. As far as a Product Backlog Item is rejected, the status will remain “in progress“ and necessary adjustments will be made during one of the upcoming development Sprints, or latest during the integration test. (6) During the Build Phase and until Customer’s acceptance of all Features, both parties can request changes to the CAE Services (herein: “Change Request”). Customer can request changes to Product Backlog Items (including already confirmed Product Backlog Items) at any time, except during the Sprint where the respective Product Backlog Items are realized. SAP will investigate the possibilities of making the changes and inform Xxxxxxxx accordingly. a) If the requested changes have an impact on the total effort and price, Customer has to follow the Change Request procedure. b) If the requested changes do not have an impact on the total effort and price, and if SAP agrees to, SAP will create a new version of the Product Backlog and will submit it to Customer for confirmation. (7) The content of an already agreed version of the Product Backlog can only be changed in case of subject to an agreement between the parties. In case of contradiction between versions of the Product Backlog, the most recently confirmed version will prevail over the others. (8) The last confirmed version of the Product Backlog will constitute the final version of the Product Backlog. Together with the Vision & Scope Document, it It is the only contractually binding description of the Features and constitutes the basis for the acceptance of the Features by Customer. In case of inconsistencies between the Vision & Scope Document and the final version of the Product Backlog, the final version of the Product Backlog shall prevail. (9) Upon completion of the Features, SAP will execute an integration test of all developed Features based on test cases provided by Customer. (10) After SAP has completed the integration test, SAP will make the Features available for Customer in a development and/or test system landscape. Once SAP declares towards Customer confirms readiness for Acceptance Testing of the Features, the period for conducting Acceptance Tests begins.

Scrum Lifecycle. (1) SAP HRMANTRA will designate a contact person (“Product Owner”) to discuss Customer’s Requirements and their priorities. The Product Owner will be responsible for managing the Product Backlog and for assigning the final priorities taking into account Customer’s business needs, the technical feasibility and the dependencies. (2) The Vision & Scope Document and the initial version of the Product Backlog are already available and attached to the applicable Order Form. SAP HRMANTRA will start directly with the first Sprint. (3) As a prerequisite for Product Backlog Items to become part of a Sprint, they have to be specified in sufficient detail in the Product Backlog including description, acceptance criteria and prioritization. The SAP HRMANTRA Product Owner continuously works together with Customer to break down and refine those Product Backlog Items that are not yet specified to the necessary level of detail. Refined Product Backlog Items result in new versions of the Product Backlog, which SAP HRMANTRA submits to Customer for confirmation as described in this Supplement. (4) At the beginning of each Sprint SAP HRMANTRA will conduct a planning meeting to decide which Product Backlog Items will be realized as Features by SAP HRMANTRA in the Sprint. After the planning meeting SAP HRMANTRA will inform Customer of the Sprint Scope. The respective Product Backlog Items are now considered fixed and cannot be altered during the Sprint. (5) At the end of each Sprint a review meeting will take place in which SAP HRMANTRA will present to Customer the Features that have been developed during the Sprint. SAP HRMANTRA will send via e-mail to Customer minutes of the Sprint review meeting for Customer to confirm. The minutes will reflect the Product Backlog Items that SAP HRMANTRA considers completed and Customer’s objections to the demonstrated Features, if any. Customer must confirm or reject the Sprint review meeting minutes via e- mail within a period of five working days as of their submission. Customer’s confirmation or rejection must be based on the description of the Product Backlog Item and on the corresponding acceptance criteria. If Customer confirms or does not reject via e-mail the minutes of the Sprint review meeting within the five working days, the completed Product Backlog Items will move to status “confirmed”. As far as a Product Backlog Item is rejected, the status will remain “in progress“ and necessary adjustments will be made during one of the upcoming development Sprints, or latest during the integration test. (6) During the Build Phase and until Customer’s acceptance of all Features, both parties can request changes to the CAE Services (herein: “Change Request”). Customer can request changes to Product Backlog Items (including already confirmed Product Backlog Items) at any time, except during the Sprint where the respective Product Backlog Items are realized. SAP HRMANTRA will investigate the possibilities of making the changes and inform Xxxxxxxx accordingly. a) If the requested changes have an impact on the total effort and price, Customer has to follow the Change Request procedure. b) If the requested changes do not have an impact on the total effort and price, and if SAP HRMANTRA agrees to, SAP HRMANTRA will create a new version of the Product Backlog and will submit it to Customer for confirmation. (7) The content of an already agreed version of the Product Backlog can only be changed in case of an agreement between the parties. In case of contradiction between versions of the Product Backlog, the most recently confirmed version will prevail over the others. (8) The last confirmed version of the Product Backlog will constitute the final version of the Product Backlog. Together with the Vision & Scope Document, it is the only contractually binding description of the Features and constitutes the basis for the acceptance of the Features by Customer. In case of inconsistencies between the Vision & Scope Document and the final version of the Product Backlog, the final version of the Product Backlog shall prevail. (9) Upon completion of the Features, SAP HRMANTRA will execute an integration test of all developed Features based on test cases provided by Customer. (10) After SAP HRMANTRA has completed the integration test, SAP HRMANTRA will make the Features available for Customer in a development and/or test system landscape. Once SAP HRMANTRA declares towards Customer readiness for Acceptance Testing of the Features, the period for conducting Acceptance Tests begins.

Scrum Lifecycle. (1) SAP will designate a contact person (“Product Owner”) to discuss Customer’s Requirements and their priorities. The Product Owner will be responsible for managing the Product Backlog and for assigning the final priorities taking into account Customer’s business needs, the technical feasibility and the dependencies. (2) The Vision & Scope Document and the initial version of the Product Backlog are already available and attached to the applicable Order Form. SAP will start directly with the first Sprint. (3) As a prerequisite for Product Backlog Items to become part of a Sprint, they have to be specified in sufficient detail in the Product Backlog including description, acceptance criteria and prioritization. The SAP Product Owner continuously works together with Customer to break down and refine those Product Backlog Items that are not yet specified to the necessary level of detail. Refined Product Backlog Items result in new versions of the Product Backlog, which SAP submits to Customer for confirmation as described in this Supplement. (4) At the beginning of each Sprint SAP will conduct a planning meeting to decide which Product Backlog Items will be realized as Features by SAP in the Sprint. After the planning meeting SAP will inform Customer of the Sprint Scope. The respective Product Backlog Items are now considered fixed and cannot be altered during the Sprint. (5) At the end of each Sprint a review meeting will take place in which SAP will present to Customer the Features that have been developed during the Sprint. SAP will send via e-mail to Customer minutes of the Sprint review meeting for Customer to confirm. The minutes will reflect the Product Backlog Items that SAP considers completed and Customer’s objections to the demonstrated Features, if any. Customer must confirm or reject the Sprint review meeting minutes via e- mail within a period of five working days as of their submission. Customer’s confirmation or rejection must be based on the description of the Product Backlog Item and on the corresponding acceptance criteria. If Customer confirms or does not reject via e-mail the minutes of the Sprint review meeting within the five working days, the completed Product Backlog Items will move to status “confirmed”. As far as a Product Backlog Item is rejected, the status will remain “in progress“ ” and necessary adjustments will be made during one of the upcoming development Sprints, or latest during the integration test. (6) During the Build Phase and until Customer’s acceptance of all Features, both parties can request changes to the CAE Services (herein: “Change Request”). Customer can request changes to Product Backlog Items (including already confirmed Product Backlog Items) at any time, except during the Sprint where the respective Product Backlog Items are realized. SAP will investigate the possibilities of making the changes and inform Xxxxxxxx accordingly. a) If the requested changes have an impact on the total effort and price, Customer has to follow the Change Request procedure. b) If the requested changes do not have an impact on the total effort and price, and if SAP agrees to, SAP will create a new version of the Product Backlog and will submit it to Customer for confirmation. (7) The content of an already agreed version of the Product Backlog can only be changed in case of an agreement between the parties. In case of contradiction between versions of the Product Backlog, the most recently confirmed version will prevail over the others. (8) The last confirmed version of the Product Backlog will constitute the final version of the Product Backlog. Together with the Vision & Scope Document, it is the only contractually binding description of the Features and constitutes the basis for the acceptance of the Features by Customer. In case of inconsistencies between the Vision & Scope Document and the final version of the Product Backlog, the final version of the Product Backlog shall prevail. (9) Upon completion of the Features, SAP will execute an integration test of all developed Features based on test cases provided by Customer. (10) After SAP has completed the integration test, SAP will make the Features available for Customer in a development and/or test system landscape. Once SAP declares towards Customer readiness for Acceptance Testing of the Features, the period for conducting Acceptance Tests begins.