How Scrum fits a clean-core SAP delivery model
SAP delivery has a well-earned reputation for waterfall behaviour, long requirement-gathering phases followed by a single high-risk go-live, and this module argues that the clean-core principle, extend the standard system rather than modify it, is actually what makes Scrum practical on S/4HANA for the first time. When customization happens through the extensibility model, side-by-side extensions on BTP, in-app extensibility, key user tools, rather than through core modifications, each extension becomes a genuinely separate, independently shippable increment, which is exactly the shape Scrum needs.
The module works through backlog slicing specific to SAP: separating what belongs in a side-by-side extension on the Business Technology Platform from what belongs in in-app extensibility, and treating that architectural decision as a refinement-time conversation rather than something decided once at project kickoff and never revisited. A central scenario walks through a stakeholder requesting a core modification, the fastest-looking option in the moment, and the module gives the team language for explaining why that request breaks the clean-core commitment and creates upgrade risk for years afterward, not just this Sprint.
Later lessons cover Definition of Done criteria that include upgrade-safety checks, since the entire point of clean core is that S/4HANA version upgrades should not break custom extensions, and a Sprint Review format for demonstrating an extension to business stakeholders who care about the process it supports, not the technical elegance of staying off the core. The module treats SAP's own release and support pack calendar the same way other modules treat platform-specific external constraints: a real planning input, not background noise.
Mistakes teams make with this material
Accepting a change to the standard S/4HANA system to save time now, which creates upgrade risk and technical debt that resurfaces at every future version upgrade, defeating the entire purpose of a clean-core strategy.
Deciding side-by-side versus in-app extensibility once at project kickoff and never revisiting it, when the right choice often depends on the specific requirement being refined that Sprint.
Shipping an extension that works today without verifying it survives a simulated version upgrade, which turns every future SAP release into a scramble instead of a non-event.
Showing stakeholders the extension's code or configuration instead of the business process it improves, which gives them nothing useful to actually inspect or give feedback on.
Questions people ask
What does clean core actually mean for a Scrum team's backlog?
It means every backlog item should be deliverable as a side-by-side or in-app extension rather than a modification to the standard S/4HANA system, which keeps each item independently shippable and upgrade-safe, the two properties Scrum increments need most.
How do you push back when a stakeholder requests a core modification?
Name the trade-off explicitly: a core modification may look faster this Sprint, but it creates upgrade risk that resurfaces at every future S/4HANA release. Offer the extensibility-based alternative and let the stakeholder choose with the real cost visible.
What belongs in the Definition of Done for an SAP extension?
Functional acceptance criteria plus a verified upgrade-safety check, ideally tested against a simulated version upgrade, so the team knows the extension will not break the next time SAP ships a release.
How should Sprint Review work for SAP extensibility work?
Demonstrate the business process the extension improves, in front of the business stakeholders who own that process, rather than presenting technical configuration to an audience that cannot meaningfully evaluate it.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
Which is the clearest Clean Core rule?
- Never build anything custom
- Do not modify the standard S/4HANA system, extend side-by-side or via released in-app extension points
- Always modify the core if it saves time
- Only use ABAP
Clean Core is about untouched standard, not about avoiding customisation. Extensions are welcome, in the right place.