Agile ASPICE and ISO 26262: Compliance Evidence Inside the Sprint
When the evidence is part of the Definition of Done, it exists the day the item closes.
Every automotive quality manager knows the four weeks before an ASPICE assessment or a functional safety audit. Engineers stop engineering and start reconstructing: trace matrices rebuilt in spreadsheets, review records written for reviews that happened months ago, verification reports assembled from whatever the test bench logged. Teams that adopted sprints often find this scramble got worse, because the sprints moved fast and the evidence never kept up.
Welcome to MBSE Explained. This post is written for safety and quality managers, and for the systems engineers who answer to them. It covers what Automotive SPICE and ISO 26262 actually permit for agile teams, where those teams really fall short, and how to produce the evidence inside the sprint so the scramble stops being necessary. It completes a short series with how to run the V-model and agile sprints at the same time and six hybrid workflows compared, and draws on my field guide, Sprinting through the V.
What the Standards Actually Say
The scepticism deserves to be taken seriously first. Both standards exist because informal development produced unsafe and unmaintainable systems, and "we're agile now" has been used to justify skipping work that matters. A safety manager who hears that phrase and reaches for the standard is doing the job well.
The standards themselves, though, are clearer than most of the debate around them.
Automotive SPICE assesses whether process outcomes are achieved and whether the evidence for them exists. It defines processes, base practices and work products, and leaves the lifecycle to the organisation. intacs, the body that certifies ASPICE assessors, publishes Agile SPICE, an assessment model aligned with Automotive SPICE 4.0 that adds three agile processes: AGL.1 Agile Work Management, AGL.2 Partner Collaboration Management and AGL.3 Agile Quality Assurance. It maps everyday agile practice onto ASPICE base practices and work products, which gives an assessor a recognised way to read an agile project.
ISO 26262 addresses agile directly, which surprises many people. In Part 6, clause 5.2, NOTE 1 states that development approaches from agile software development can be suitable for safety-related software, provided any tailoring of the safety activities follows ISO 26262-2:2018 clause 6.4.5. The same note sets the limit plainly: agile approaches "cannot be used to omit safety measures", nor to ignore the documentation, process or product rigour that functional safety requires. The examples that follow in the same clause name test-driven development and continuous integration on an automated build system, including documentation generation and testing.
Two precise points matter here. That note sits in Part 6, which covers the software level. At system and hardware level, the route is the general tailoring provision in Part 2, with the rationale recorded in the safety plan. And the note is informative guidance attached to normative requirements that do not change. Agile buys you freedom in how the work is sequenced. It buys no reduction in rigour.
Where Agile Teams Actually Fall Short
If agile is permitted, why do agile teams so often struggle in assessments? The best evidence comes from a mapping study presented at ICSSP 2017, How do agile practices support Automotive SPICE compliance? by Diebold, Zehler and Richter. Mapping agile practices against ASPICE requirements, they found supporting practices for around 96% of base practices and around 87% of work products.
That is a mapping on paper, and an assessment rating would be stricter, so the exact numbers matter less than their shape. Agile teams already do the activities. What they under-produce is the artefacts. In practice that shows up as the familiar findings: bidirectional traceability missing or reconstructed late, work products created after the fact, and requirements that exist in the requirements tool, in the ticket system and in a specification document, each saying something slightly different.
That diagnosis is useful, because it tells you where to invest. Agile teams need help with evidence far more than with process.
Put the Evidence in the Definition of Done
The single mechanism that closes the gap is the Definition of Done. If it names the trace links, the review record and the verification result, the evidence exists the moment an item closes. If it doesn't, the evidence gets produced weeks before the assessment by people reconstructing intent they no longer remember, at several times the cost.
A Definition of Done that carries compliance evidence looks like this for every item:
- Model changes merged and consistency checks passing
- Trace links complete: upward to the parent requirement, downward to the realisation, across to verification
- Verification artefact present, with its result recorded
- Peer review of the change recorded
- Generated work products regenerated and current
- No new orphan or unallocated elements introduced
Safety-relevant items carry additional criteria:
- ASIL attribute set on every affected model element
- Trace to the functional safety requirement and the safety goal
- Verification method appropriate to the ASIL
- Safety manager review recorded
- Impact on safety analyses (FMEA, FTA, dependent failure analysis) assessed, with follow-up items raised where needed
- Safety case claim updated with the new evidence
The test of whether this is working is simple. If the team ever schedules a "documentation sprint" to catch up on evidence from earlier sprints, the Definition of Done is not being enforced. The right response is to fix the Definition of Done and never to schedule the sprint, because once the catch-up sprint exists, every later sprint will rely on it.
Generate Work Products From the Model
A Definition of Done like the one above is only achievable if producing the evidence is cheap. If closing an item means writing three documents, it will not happen inside a two-week sprint, and nobody should pretend otherwise.
The way through is to stop authoring work products and start generating them. When requirements, architecture, interfaces, allocation and verification live in a SysML model, the system requirements specification, the traceability matrix, the interface specification, the architecture description and the verification report become views of that model. A generated document is consistent with the model by construction, which removes an entire category of assessment finding: the one where two artefacts describe the same thing differently. Running a report fits inside a sprint in a way that writing a document never will. ISO 26262-6 itself lists documentation generation as part of the continuous integration example quoted above.
There is a cost here that many write-ups skip. If a generator, a model checker or a CI pipeline produces or checks safety-relevant work products, ISO 26262-8 requires confidence in that software tool. The tool is classified by its potential impact and by how likely its errors are to be detected, and the resulting tool confidence level determines whether qualification is needed. Plan for that once per toolchain configuration. It is a one-off investment, and a qualified, validated generator is precisely what makes generated evidence trustworthy to an assessor.
Configuration management carries the same weight in both standards. Baseline the model at every sprint boundary, so each review demonstrates against a named, immutable snapshot, and keep external deliveries on separate, less frequent baselines so nobody confuses what the team has explored with what the programme has formally committed.
Treat Safety Requirements as Backlog Items
Some safety work genuinely belongs at the front, and a hybrid that pretends otherwise loses the safety manager's trust immediately. The item definition, the hazard analysis and risk assessment, and the functional safety concept belong in sprint zero and the first programme increment. Expect to revise them; a revised HARA is far cheaper than a missing one. What you buy by front-loading them is a stable boundary. Once the safety goals and the safety architecture exist, iteration inside them is low-risk, and any change that would cross them becomes visible instead of silent.
Inside that boundary, technical safety requirements, safety mechanisms and their verification become backlog items like any other, held to the stricter Definition of Done above. Agile SPICE's AGL.3 fits naturally here: safety review findings are tracked independently of the team's own backlog priorities, so they cannot be quietly ranked below feature work.
The safety case changes character too. In a sequential programme it is assembled at the end, often by whoever is available, from whatever was recorded. In this workflow the argument structure is drafted early, during the functional safety concept, and every sprint that completes a safety-relevant item attaches its verification evidence to the relevant claim. The safety case grows steadily, and at any moment you can see exactly which claims are still unsupported. That visibility is most of the benefit.
What Stays Independent and Event-Based
One distinction matters a great deal, and agile writing often blurs it. The safety manager's review inside the Definition of Done is a verification activity within the team's flow. ISO 26262's confirmation measures are a different thing: the confirmation reviews, the functional safety audit and the functional safety assessment. They require a degree of independence, from I0 to I3, that rises with ASIL and is set out in the standard's tables, and they are planned in the safety plan.
A team cannot self-organise its way around an independent assessment. Confirmation measures stay event-based, scheduled at programme-increment boundaries against formal baselines, and an ASPICE assessment remains an event too. What changes is what those events find. When evidence has been produced and reviewed continuously, an assessment confirms a known state of the work, and it stops being a hunt for defects that nobody knew were there.
Measure the Evidence, Not the Documents
The most useful leading indicator is evidence completeness: the percentage of completed backlog items whose trace links and verification artefacts are actually present. Track it every sprint, aiming for 100%. It predicts assessment outcomes many months ahead, which is exactly when there is still time to act on it.
Alongside it, trace health, meaning the count of orphan requirements, unallocated functions and requirements without verification, should come straight out of automated model checks and trend towards zero within each programme increment. The metric to retire is percentage-complete on documents. A specification that is 90% written says nothing about whether the system will work or the evidence will hold.
Where to Start
Pick one pilot subsystem with real content and moderate safety relevance. ASIL A or B is ideal, since QM teaches you little and ASIL D is a hard place to learn. Write the Definition of Done with the evidence requirements explicit, automate the trace and consistency checks, and enforce the Definition of Done strictly from the first sprint. The first time an item is rejected because a trace link is missing is the moment the approach becomes real. Generate the first work products from the model early and show them to your quality department, or to a friendly assessor, while there is still time to adjust. Adopt Agile SPICE as the interpretation layer before your next assessment, so the assessor's first question, which lifecycle is this and how does it satisfy the model, already has a defensible answer.
The full ninety-day adoption sequence, the complete Definition of Ready and Done checklists including the hardware additions, and a twelve-week worked example on an EV traction inverter are in the book.
That's the mission here at MBSE Explained, simplifying systems for smarter EVs. If you've been through an assessment with an agile team, what did the assessor ask about first?