Agile Development & ISO 26262
Integrating Agile Methodologies with Functional Safety Requirements
- Chapters
- 12
- Chapters
- Interactive Diagrams
- 6
- Interactive Diagrams
- Aligned
- SAFe
- Aligned
- Coverage
- ASIL D
- Coverage
Quick answers
- What is Agile development in ISO 26262?
- ISO 26262 does not mandate a waterfall process - it mandates work products, verification rigor, and traceability. Agile development in ISO 26262 means producing those same outcomes iteratively: user stories carry safety requirements, the Definition of Done enforces ASIL-appropriate reviews and coverage before a story closes, and traceability runs from safety goal through epic, feature, story, code commit, and test result. ISO 26262-6 Annex D discusses software process compatibility, and in practice frameworks like SAFe are aligned by placing safety gate reviews at Program Increment boundaries. The method changes; the evidence obligations do not.
- Is Agile allowed for ASIL D software development?
- Yes - no clause of ISO 26262 forbids iterative development at any ASIL. What changes with ASIL is rigor, not process shape: ASIL D still demands MC/DC coverage, stricter independence in reviews, and complete bidirectional traceability, regardless of whether the work happens in phases or sprints. The tension points are real, though: sprint velocity pressure versus safety gates, evolving backlogs versus baselined requirements, and Definition of Done discipline. The course maps exactly where Agile and the safety lifecycle align naturally and where you need explicit countermeasures.
Why it pays for itself
Sprints that survive an audit
Map user stories, epics, and sprint backlogs to ISO 26262 software requirements, design documents, and test specifications - so your Agile artifacts double as compliant work products instead of a parallel paper trail.
ASIL-graded Definition of Done
Get ready-made DoD checklists per ASIL covering peer review depth, static analysis thresholds, and MC/DC coverage targets, so story closure itself becomes the safety gate instead of a late-phase scramble.
A qualified CI/CD pipeline
Learn how to classify static analyzers, test runners, and coverage tools into TCL 1 to 3 per ISO 26262-8 Clause 11 and wire them into pipelines with pass/fail safety gates.
What you’ll be able to do
Map Agile Artifacts to Safety Work Products
Establish compliant mappings from user stories, epics, and sprints to ISO 26262 software requirements, design documents, and test specifications.
Define ASIL-Graded DoD Checklists
Create Definition of Done criteria that enforce ASIL-appropriate review depth, coverage targets, and analysis requirements before a story is closed.
Design Safe CI/CD Pipelines
Integrate qualified static analysis, unit test, and coverage tools into automated pipelines with safety gate conditions per TCL requirements.
Maintain Sprint-Level Traceability
Link safety requirements to code commits and test results within each sprint using issue tracking tools to enable continuous traceability.
Align Safety Gates with PI Boundaries
Synchronize confirmation measures and safety reviews with SAFe Program Increment boundaries to avoid blocking the release train.
Resolve Agile-Safety Conflicts
Apply structured decision frameworks to balance sprint velocity with safety gate requirements and escalate effectively when safety work cannot be deferred.
Chapter by chapter
- 01
New to Agile Overview
A crash course in Agile principles for safety engineers: the Agile Manifesto values, Scrum roles and events, Kanban flow, and why automotive organizations are adopting iterative development despite safety constraints.
- Agile Manifesto
- Scrum basics
- Why automotive Agile?
- 02
Key Terms & Concepts
Build a shared vocabulary bridging Agile and safety engineering: sprint vs. phase, user story vs. requirement, Definition of Done vs. acceptance criteria, epic vs. feature, and backlog vs. work product list.
- Agile-safety glossary
- Terminology mapping
- Shared vocabulary
- 03
SAFe for Automotive
Explore the Scaled Agile Framework as applied to large automotive programs: Agile Release Trains, Program Increment planning, the Essential SAFe configuration, and integration with OEM-Tier1 development contracts.
- ART structure
- PI Planning
- OEM-Tier1 alignment
- 04
Agile + ISO 26262 Fit
Analyze where Agile and ISO 26262 align naturally and where tensions arise. Map the safety lifecycle phases to Agile release cycles and understand ISO 26262-6 Annex D guidance on software process compatibility.
- Lifecycle mapping
- Tension points
- Annex D guidance
- 05
Scrum Ceremonies with Safety
Integrate safety activities into every Scrum event: safety backlog grooming in sprint planning, safety review in sprint demos, safety retrospectives, and daily stand-up safety signals.
- Sprint planning + safety
- Safety review
- Safety retrospective
- 06
Definition of Done by ASIL
Define ASIL-graded Definition of Done checklists that gate story closure. Covers peer review requirements, static analysis thresholds, MC/DC coverage targets, and work product completeness criteria by ASIL.
- DoD per ASIL
- Review gates
- Coverage criteria
- 07
Agile Artifacts → ISO 26262 Work Products
Map user stories to software requirements, epics to software units, sprint backlogs to development plans, and acceptance tests to module test specifications - with traceability maintained from start to finish.
- Artifact mapping table
- Traceability hooks
- Work product compliance
- 08
CI/CD & Tool Qualification
Design safe CI/CD pipelines with qualified tools: static analyzers (TCC/TCL), unit test runners, build systems, and coverage tools. Apply ISO 26262-8 Clause 11 tool confidence levels to your toolchain.
- CI/CD pipeline design
- TCL 1/2/3 classification
- Tool qualification evidence
- 09
Sprint-Level Traceability
Establish bidirectional traceability within sprints using issue trackers: linking safety requirements to stories, stories to code commits, commits to test results, and test results to coverage reports.
- Issue tracker setup
- Commit traceability
- Coverage linkage
- 10
Release Train Alignment
Synchronize safety gate reviews with SAFe Program Increment boundaries, ensure safety plans cover all ARTs, and coordinate confirmation measures across multiple Agile teams in a distributed program.
- PI boundary reviews
- Multi-ART coordination
- Safety gate timing
- 11
Practical Examples
Walk through a complete Agile sprint cycle for an ASIL B software feature: story writing with safety criteria, design, coding, peer review, static analysis, unit test, and DoD verification with traceability.
- End-to-end sprint
- ASIL B worked example
- DoD verification
- 12
Test Your Knowledge
Scenario-based quiz covering Agile-safety integration decisions: choosing the right DoD, resolving sprint velocity vs. safety gate conflicts, and identifying non-compliant practices in given project descriptions.
- Scenario quiz
- Conflict resolution
- Compliance assessment
Not just text: the visual toolkit
Safety Lifecycle ↔ Sprint Mapping
Interactive diagram overlaying ISO 26262 lifecycle phases on Scrum sprint cycles, showing which safety activities occur in planning, execution, and review phases of each sprint.
SAFe Program Increment Overview
Visual of an Agile Release Train PI structure with safety gate checkpoints, hardening sprints, and IP sprints highlighted with confirmation measure integration points.
Artifact Traceability Flow
End-to-end traceability chain from Safety Goal through Epic → Feature → Story → Code → Unit Test → Integration Test with interactive forward/backward trace modes.
Definition of Done Matrix
Interactive ASIL-graded DoD matrix showing review depth, analysis thresholds, and coverage targets for QM, ASIL A, B, C, and D - filterable by ASIL.
CI/CD Safety Pipeline Diagram
Annotated CI/CD pipeline showing qualified tool stages: static analysis, unit test, MC/DC measurement, integration build, and safety gate with pass/fail conditions.
Tool Qualification Decision Tree
Interactive TCL determination flowchart per ISO 26262-8 Clause 11: TD and TI assessment leading to TCL 1, 2, or 3 with required evidence for each level.
ASIL B Lane-Keep Assist Software Sprint
A complete eight-sprint Agile cycle for an ASIL B LKA software feature in an SAFe Release Train: PI planning with safety story sizing, sprint execution with ASIL-graded DoD, CI/CD gate configuration, and PI-level confirmation review.
- Safety epics and features written with ASIL B acceptance criteria
- Sprint DoD: peer review, PC-lint clean, 75% MC/DC, unit test pass
- CI/CD pipeline with qualified tools (TCL 2 justification)
- Sprint-level traceability: Jira stories → Bitbucket commits → Tessy results
- PI boundary: functional safety audit evidence package assembled
- Non-conformance found in sprint 5 - corrective action tracked to closure
Unlock in course
Who this guide is for
- Scrum masters and product owners inheriting their first safety-related backlog
- Safety managers asked whether the team "can even do Agile" on an ASIL project
- Software leads aligning SAFe Agile Release Trains with safety gate reviews
- Engineers defending sprint-level traceability in front of an assessor
Frequently Asked Questions
Common questions about Agile Development & ISO 26262
Start the course today
A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required.