A spec that scores 7 out of 10 doesn’t go to development. In an 18-person SAP team I work with, the team names that rule as the change that helped the most. Over five weeks, the median cycle time in the implementation phase dropped from 19 days to about 5.5.
Spec-driven development means writing the spec before writing code with AI, so the spec becomes the source of truth for the human and the AI. In SAP I add one thing: the spec gets a score, and the score decides if anyone touches ABAP.
You’d expect the AI win in the code. This team says it came one step earlier.
The bottleneck was the ticket, not the ABAP
We started with AI in reporting and in ABAP. In the team’s Jira, the median cycle time in the implementation phase fell 71% in five weeks. On SLA-related tickets, resolution time fell 49%, from 2.72 days to about 1.4.
I work with this team as a fractional AI lead, and I can’t split that 71% cleanly: the spec gate, the skills, the pairing and the incident agent all started in the same weeks. What I have is the team’s own answer to what helped the most: “what was helpful the most is spec-driven development, meaning the teams have started to create proper specifications.”
When we started, the average spec in that team scored 3.3 out of 10. The reason it mattered is simple. An ABAP developer with a vague ticket goes back to the consultant, waits for the answer, then guesses the rest. AI doesn’t fix that, it only guesses faster.
Score every spec. Below 8, it doesn’t enter the sprint
The team built an evaluator on top of the specifications. It’s an AI skill that reads a Jira ticket and scores it against 10 points. This is the rubric, written for SAP objects:
| # | What the spec must contain | Points |
|---|---|---|
| 1 | Business goal and who benefits | 1 |
| 2 | Affected SAP objects named: tables, function modules, BAdIs, interfaces | 2 |
| 3 | Current vs target behaviour | 1 |
| 4 | Acceptance criteria you can test (given / when / then) | 2 |
| 5 | Test data and edge cases | 1 |
| 6 | Authorizations and personal data | 1 |
| 7 | Dependencies and side effects: interfaces, batch jobs, transports | 1 |
| 8 | What is out of scope | 1 |
| Total | 10 |
The rubric is mine; the team and I built the evaluator on top of it. Acceptance criteria and the affected objects carry 2 points each because those were the gaps that hurt: the specs had no testable acceptance criteria or edge cases, and no context on the APIs or the technical architecture.
The bar sits at 8, so a spec can miss two points and still go through. Miss more, and it goes back to its author with the missing items listed. In the team’s own words:
If a specification has a rating lower than 8 out of 10, it’s not allowed for a team to work on that issue.
One ticket, before and after
Here is what a bounced spec looks like. This is an illustrative example I made up for this post, not a client ticket: the same request, scored before and after it went back to its author.
| Rubric item | Before | After |
|---|---|---|
| Goal | ”Orders on credit hold must not be delivered. Please fix.” (1) | The same, plus who benefits: finance stops chasing returned deliveries (1) |
| Current vs target | Target only (1) | Today the nightly job delivers everything; target: skip held orders (1) |
| Objects | None named (0) | Credit status CMGST on sales order header VBAK, job ZSD_DELIVERY_BATCH, BAPI_OUTB_DELIVERY_CREATE_SLS (2) |
| Acceptance criteria | None (0) | Given an order on credit hold, when the nightly job runs, then no delivery is created and the order lands on the exception list (2) |
| Edge cases | None (0) | Credit released between selection and creation; partly released orders (1) |
| Dependencies | None (0) | Must run after the nightly credit release job (1) |
| Out of scope | Not stated (0) | Credit limit changes (1) |
| Score | 2/10 | 9/10 |
Authorizations are still missing, so it’s a 9 and not a 10.
The strongest objection I found comes from Birgitta Böckeler. After testing three spec-driven tools on martinfowler.com, she wrote that she’d “rather review code than all these markdown files”, and that the process felt like overkill for small problems. For a two-line fix she is right.
In SAP the trade looks different: the skill produces the score, and the consultant reads only the missing points. A forgotten authorization or transport dependency costs more than ten lines of criteria.
Then AI made the ABAP faster
Once the specs were good, the code part started to pay off. The team created skills “capable of looking into the codebase to find the contracts and the relevant bugs”, so the AI works with the real Z-code, not with a snippet somebody pasted.
The second step was one setup for everybody. In practice, “we created a set of skills and an installation guide for each and every person in the SAP team that helps us to get other people faster into AI.”
Two of those skills carry most of the work. The spec evaluator scores a Jira ticket against the rubric above and lists the missing points. The codebase contract finder searches the team’s code for the contracts and the relevant bugs behind a ticket.
Together they work as a plugin. I keep my SAP skill set in a private repo; if you want to compare it with yours, ask me for access.
The incident agent took 3 hours to build
The same move worked on the support side: knowledge that sat in one head became written rules. The bottleneck there was manual categorisation of incidents.
“Before it was depending only on the knowledge of one single person and we turned that knowledge into an agent who is capable of doing the proper categorization.” The agent that replaced that manual work took 3 hours to build.
It isn’t perfect. The person in support still categorises 20% of the tickets by hand, the ones where the agent has low confidence. “We are not there yet with doing some sort of auto-fixing but it’s coming.”
Pair the beginner with the AI native
The skills spread through one rule.
“The rule is that we do the pairing. A person who’s not that knowledgeable in AI gets a buddy who is quite advanced in AI and they sit together. They move things forward together. Therefore the knowledge is shared very fast.”
Pairing also makes visible who doesn’t want to move. I wrote about that part in how AI resistance sorts your team.
Or do it with the whole team in one day
The CIO of a 50-person IT team asked me to bring this to everybody in one day: half SAP, half IT infrastructure and helpdesk. Their IT won’t connect AI into SAP, and that’s fine, because a spec doesn’t need SAP access and neither does Jira data.
The day starts with a 75-minute live build and the case above. Then the ABAP developers work on one shared setup and a piece of old Z-code, while consultants, helpdesk and infrastructure score six months of their own Jira specs and trace one incident from its log to a proposed fix. The day ends with 3 agreed metrics: median cycle time in the implementation phase, share of specs at 8 or above, and sprint completion against the plan.
Start on Monday, without touching SAP
None of this needs AI connected into your SAP system. It needs your Jira.
Measure the median first
Pick the two Jira statuses where development starts and ends, and keep them fixed. Take the last 6 months and write down the median time between them.
That is the cycle time in the implementation phase from the top of this post. Without the before number, the after number is just a claim. If you want a second pair of eyes on the delivery data, that’s what a team productivity audit does.
Score 20 old specs
Run the rubric above over 20 specs from last quarter. Count how many reach 8. That share is your starting line, and don’t be shocked: the team above started at an average of 3.3.
Close the gate
From the next sprint, a spec below 8 goes back to its author with the missing points.
One setup for every ABAP developer
Same IDE, same skills, one install guide, and a buddy for everyone new to AI.
Which of your last 20 specs would pass 8 out of 10? If you want to find out with your own team in one day, that’s the AI workshop for SAP teams.
[Writing time: 5h]
