Lesson 3 of 5
Capturing and classifying deltas
9 min
A delta (some programs still say gap) is a business requirement that standard scenarios cannot satisfy as demonstrated. How deltas are written decides how much the program will build, test and maintain for years. A vague delta becomes a vague build. A delta without a business reason cannot be prioritized. A delta not linked to a process cannot be traced to a test.
What a good delta record holds
| Field | Why it matters | Contoso example |
|---|---|---|
| Solution process | Anchors traceability and coverage | Sell from stock |
| Title and statement | What the business needs, not how to build it | Consolidated monthly invoice for fleet customers |
| Business reason | Lets the product owner rank it | Fleet contracts require monthly billing |
| Type | Routes it to the right team and approach | Configuration candidate; possible standard collective billing |
| Priority | Decides what enters the first sprints | Must |
| Raised by and owner | Who can answer questions and who accepts | Raised by Maria; owner Maria |
| Acceptance idea | First note of how it will be proven | One invoice per customer per month across all deliveries |
Fields Contoso requires on every delta requirement.
Classifying deltas
Classification tells the program what kind of work each delta creates. Many programs use the old WRICEF list (workflows, reports, interfaces, conversions, enhancements, forms) for development objects. For Fit-to-Standard it helps to start one level higher and ask how the need will be met, in order of preference for a clean core.
- Is it met by standard configuration or a value not yet set?Yes → configuration item · No → next
- Can a key user meet it with in-app extensibility, such as a custom field or adapted output form?Yes → key-user extension · No → next
- Is it data exchange with another system?Yes → integration requirement · No → next
- Does it need new logic or apps?Yes → developer extension, preferably side-by-side or on released interfaces · No → organizational or change item
Some deltas are not system work at all. When the business accepts the standard but must change how it works, record a change management item for the Solution Adoption workstream. Those items still need testing evidence later, because training and work instructions will be based on the standard process.
Prioritizing
In SAP Activate, the product owner validates deltas and adds approved ones to the product backlog for Realize. SAP's agile Activate content warns against the common failure where almost everything is marked "Must have". Contoso uses MoSCoW categories and then ranks inside each category, so no two items share a rank.
In SAP Cloud ALM
Requirements in SAP Cloud ALM are created from a solution process. SAP's best practice guide describes a requirement-driven approach with user stories as the leading pattern for private edition projects: requirements capture the business need, can go through an optional approval step, and are then broken into user stories for the sprints and delivered through features. Status values have evolved over releases; check your tenant for the current list.
- CapturedRequirement created against the solution process in the workshop
- RefinedBusiness reason, type, priority and owner completed
- ApprovedProduct owner or requirement approver confirms it should be built
- Broken downUser stories created for sprints; feature created for deployment
- Realized and testedBuilt, tested against acceptance criteria, and confirmed
What would you do?
After the record-to-report workshops, Dan's team has raised 64 deltas, and 60 are marked "Must". Grace has to make the backlog usable for Realize sprint planning. What is the best step?
- A delta is a business need the standard cannot meet as shown; record it against its solution process with a business reason.
- Classify by the least invasive way to meet it: configuration, key-user extension, integration, developer extension or change item.
- Rank deltas inside MoSCoW categories; do not let everything become "Must".
- In Cloud ALM, requirements are created from processes, optionally approved, and broken into user stories and features.
Check your understanding · not graded
Lesson check
1. What is a delta in Fit-to-Standard?
2. Which field lets a product owner rank a delta?
3. Which way of meeting a delta is least invasive to the core?
4. In SAP Cloud ALM, where is a requirement created from?