Illustrating the Release Planning in a Scaled Environment

Objective

After completing this lesson, you will be able to plan Release in a Scaled Environment

Release Planning in a Scaled Environment

In an SAP Project, the implementation usually consists of multiple teams. The Product Backlog is valid for the whole project, but each team will need their backlog. In this case, use a Program Backlog, which represents the requirements or the Epics of the project. Each Product Owner splits those items into Scrum Team Backlogs, considering the features they need to deliver to satisfy the overlaying requirement or Epic. As shown in the figure, multiple Product Owners and teams might play on the same Epics and might even have dependencies on each other to be discussed, planned, and solved.

Epic/Process A corresponds to a customer-specific end-to-end business flow for which multiple requirements, materialized as Backlog items, were identified during the Explore phase.

Because Epic/Process A is very complex and/or requires skills specific to several Scrum Teams, it's split into:

  • User Story A1 going to Procure to Pay Scrum Team (for example, Configuration)
  • User Story A2 going to Order to Cash Scrum Team (for example, Enhancement)
  • User Story A3 going respectively to Record to Report Scrum Team (for example, Configuration)

Epic/Process B corresponds to another customer-specific end-to-end business flow for which multiple requirements, materialized as Backlog items, were identified during the Explore phase.

Epic/Process B is also very complex and has many requirements identified, but all the required skills to implement this feature are available inside the Procure to Pay Scrum Team. During the Backlog refinement session, the Scrum Team splits it into:

  • User Story B1 that will be implemented during Sprint 1
  • User Story B2 that will be implemented during Sprint 2

Epic/Process B will be completed only in Sprint 2

Log in to track your progress & complete quizzes