1.Why Scrum for SAP S/4HANA Clean Core is worth getting right
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.
2.How it works in practice
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.
3.Role reality
The left column is the SAP roadmap slide. The right column is the Sprint Backlog on a Tuesday.
| Textbook theory | Delivery reality |
|---|---|
| Clean Core means no customisation. | Clean Core means customisation lives beside the core, on released APIs and extension points, never inside it. |
| A small field change is harmless. | Clean Core dies by a thousand small modifications, not by one big one. Every 'just this one field' is the same request repeated. |
| Governance and Scrum are in tension. | Governance does not have to be waterfall. A lightweight architecture review every Sprint, focused on extension boundaries, is enough. |
| An upgrade is a separate project. | An upgrade is a stress test of every core modification you allowed. Clean extensions absorb releases without a project. |
4.Core delivery pillars
Four habits that keep an S/4HANA backlog Sprint-friendly and upgrade-safe.
If the change touches SAP-delivered code or tables, it is a governance decision, not Sprint content. Route it, do not backlog it.
Custom logic runs on the Business Technology Platform through released APIs, or as key user tools and RAP objects on released extension points.
Done means no core modifications, released APIs only, deployment tested, and the extension boundary written down for the next Sprint's reviewer.
A short architecture review each Sprint focused on extension boundaries beats a heavy CAB-style gate that becomes an impediment for the Scrum Master to remove.
5.Metrics that matter on a Clean Core team
The numbers that tell you whether the next upgrade will be a weekend or a quarter.
Percentage of new functionality delivered via released extension points. Target: near 100 percent.
Changes to SAP-delivered code or tables. Target: zero, tracked visibly if not.
Issues traced to core drift each release cycle.
Days from extension request to a documented decision.
6.Situations you will be asked to handle
The module puts you inside 3 decisions rather than asking you to recognise the right answer on a list. Each one is a situation practitioners meet, with several defensible options and consequences that follow from the one you pick. The scenarios below are the shape of the judgment the subject demands.
- Lesson 16.3: Game: order the Clean Core backlog
- Lesson 16.4: Game: Definition of Done when you cannot touch the core
- Lesson 16.5: Game: protect the Sprint from 'just tweak the standard'
7.Common mistakes and why they fail
Approving a core modification because it is faster this Sprint
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.
Treating extension architecture as a one-time decision
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.
Skipping upgrade-safety checks in the Definition of Done
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.
Running Sprint Review as a technical demo instead of a business one
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.
8.Questions worth asking before you commit time to this
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.
9.What to remember
- The one rule that separates Sprint content from a governance decision on S/4HANA
- Side-by-side and in-app extension patterns that keep the platform upgrade-safe
- A situational matrix for the 'just tweak the standard' requests that erode Clean Core one field at a time
10.Where this sits in the Scrumling course
Ship value on S/4HANA while keeping the standard system untouched, Sprint-friendly extensions, not waterfalled modifications.
About 38 minutes of lessons and decision scenarios.
- Lesson 16.1: Why Clean Core changes Sprint work
- Lesson 16.2: Side-by-side extensions vs core modifications
- Lesson 16.6: Governance without waterfall
- Lesson 16.3: Game: order the Clean Core backlog
- Lesson 16.4: Game: Definition of Done when you cannot touch the core
- Lesson 16.5: Game: protect the Sprint from 'just tweak the standard'
Assessment: Scrum for SAP S/4HANA Clean Core quiz