
Your team has been running Agile for years. Stories are planned in Jira, sprints run on two-week cycles, and the sprint board tells you exactly where everything stands. Releases ship on time, retrospectives close out action items, and the Definition of Done is defined and followed.
Then comes the requirement: Automotive SPICE® (ASPICE) compliance.
When your team maps Agile practices to what the ASPICE standard requires, the gaps become visible. Your Jira backlog manages work effectively, but the standard also expects a current product specification that reflects requirements at a given point in time. Your sprint board tracks delivery flow, and the standard expects the full chain of requirements to be traceable from stakeholder need to implementation. Your Definition of Done sets quality criteria.
In addition, the standard expects independent quality assurance records. Your retrospectives capture learning, but the standard asks a different question: Was the agreed process followed, and is there evidence to prove it? None of these are failures. They reflect how Agile methods are designed to work. ASPICE requires something more.
Agile SPICE is the recognized path to bridging that gap. It gives teams and assessors a shared framework for demonstrating ASPICE compliance in an Agile development context.
What Agile SPICE Actually Is
Agile SPICE is a Process Reference Model (PRM) and Process Assessment Model (PAM) published by intacs, the global body governing Automotive SPICE assessor training, examination, and certification. First released in 2022 and now at version 1.4.1 (released in July 2025 and fully aligned with ASPICE 4.0), it is designed to work alongside ASPICE, not replace it.
Agile SPICE supports the evaluation of ASPICE principles in Agile projects and the application of Agile methods in consistency with ASPICE. It introduces three dedicated Agile processes and interpretation notes for the ASPICE engineering and selected supporting processes.
The 3 Agile SPICE Processes and What They Cover
Three processes provide Agile-specific base practices for the areas of work management, partner collaboration, and quality assurance.
1: AGL.1: Agile Work Management
AGL.1 is the Agile equivalent of MAN.3 Project Management in ASPICE. It covers how an Agile team organizes and executes its work across the full management scope, including:
- Jointly defining the product vision.
- Assembling the right team with the right competencies.
- Evaluating feasibility.
- Managing stakeholder dependencies.
- Estimating and prioritizing the backlog.
- Planning iterations.
- Tracking progress transparently.
- Resolving impediments.
The work approach, including Definition of Ready and Definition of Done (DoR/DoD), must be defined, documented, and kept current.
2. AGL.2: Partner Collaboration Management
AGL.2 is the Agile equivalent of ACQ.4 Supplier Monitoring in ASPICE. It requires partners to establish a documented collaboration model covering:
- Joint Agile events.
- Joint artifacts.
- Roles.
- Information to be exchanged.
Partners share Definitions of Ready and Done, maintain aligned backlogs, and inspect progress continuously. Risks and impediments are managed collaboratively throughout development.
3. AGL.3: Agile Quality Assurance
AGL.3 is the Agile equivalent of SUP.1 Quality Assurance (QA) in ASPICE. In Agile, the self-organizing team structure makes independence harder to establish and demonstrate. ASPICE requires QA to be performed independently and objectively, without conflicts of interest, evaluated based on organizational and financial assignment.
Quality objectives are collaboratively identified and agreed upon, in line with the team’s work approach, governance criteria, and external customer requirements. Impediments affecting quality are tracked in the backlog, escalation paths are defined, and both are known to every team member and accessible to anyone in the organization.
What Agile SPICE Expects as Evidence
Agile SPICE provides interpretation and mapping of Agile work products to what ASPICE process indicators look for as evidence. These are the major gaps most Agile projects face.
The Product Specification and the Backlog Are Not the Same Artifact
SPICE is explicit on this: the requirements valid at a given point in time must be fully derived from the product specification and cannot be represented solely by the historical progression of the product backlog.
The difference matters. A well-managed backlog records what the team planned and completed. The product specification records what the product must do and why, differentiated from the backlog’s historical record of work completed. The requirements valid at a given point in time must be derivable from the product specification, not reconstructed from the historical progression of the product backlog.
Without a product specification that exists independently of the product backlog, teams cannot demonstrate that all requirements have been identified, are current, and have been implemented completely, all of which an assessor will look for.
Traceability Across the Full Development Chain
ASPICE requires bidirectional traceability across the full development chain. Agile SPICE clarifies how that chain maps to the work products Agile teams produce: stakeholder requirement, system requirement, backlog item, architectural element, test case, and test result. This chain applies to changes too. When a requirement changes, the impact must trace through all affected work products: the backlog item, the architecture, tests, and downstream requirements connected to it.
Independent QA Records and Configuration Baselines
Agile SPICE separates two responsibilities: the team is jointly responsible for the quality of their processes and work products, while quality assurance is independently responsible for ensuring conformance to agreed quality objectives is achieved and maintained.
The standard allows QA to draw on iteration reviews, retrospectives, and DoR/DoD criteria as inputs. Agile SPICE requires independently produced evidence artifacts, including review evidence and quality conformance evidence, that demonstrate conformance was checked without conflict of interest. Sprint review minutes and DoD checklists can inform those artifacts, but cannot substitute for them.
Configuration management also applies to Agile artifacts. Backlog items, iteration backlogs, and iteration review information should be considered as configuration items and version controlled accordingly.
The configuration management approach must be updated each iteration, and baselines must be performed according to the Agile work approach, for example at the end of each major iteration or release. DoD criteria can contribute to baseline completeness checks, but baseline audits and baseline reproduction checks must still be planned and implemented.
Both are evidence gaps that Agile teams consistently discover late, often during assessment preparation rather than during development.
How Jama Connect Supports Agile SPICE Compliance
Most teams worry that achieving Agile SPICE compliance means disrupting the development workflows that already work. It doesn’t. Jama Connect® manages the STATE of your development effort while your team continues managing FLOW in whichever work management tool they already use, such as Jira or Azure DevOps.
Jama Connect can be integrated with these tools so work items synchronize automatically and developers continue working in their existing tools.
Product Specification and Traceability
The product specification is maintained in Jama Connect as a managed, current set of requirements, separately from the product backlog. Jama Connect keeps bidirectional traceability between stakeholder requirements, system requirements, backlog items, architectural elements, test cases, and test results live throughout development. When requirements change, downstream items are flagged through Jama Connect’s Suspect Links mechanism. Teams get immediate visibility of impact without waiting for a manual review cycle.
Requirements Exchange Across Partner Boundaries
Partners can exchange requirements at defined sync points, or share a common Jama Connect instance so every party sees the same current requirements, changes, and review status in real time.
Independent QA and Baselining
In Jama Connect, work products go through formal reviews that produce the review evidence Agile SPICE requires. The independent QA function uses these records, alongside other inputs, to produce quality conformance evidence. Customers and partners can be invited into Jama Connect reviews.
The resulting evidence record spans organizational boundaries rather than staying within a single team. Teams can implement a defined baselining approach in Jama Connect, with baselines created according to agreed events and procedures.
To learn how Jama Connect supports Agile SPICE compliance in practice, explore our Traceable Agile™ solution.
Frequently Asked Questions
Can Agile SPICE Be Applied to Programs That Mix Agile and Waterfall Phases?
Yes. Many automotive programs run system-level and hardware engineering activities under a more traditional waterfall-aligned model while software development teams work in Agile iterations. The three AGL processes and the Part 2 interpretation notes apply to the Agile portions of a program without requiring the full program to change its delivery model.
Can We Apply Agile SPICE Without Changing the Agile Framework We Already Use?
Yes. Agile SPICE is framework agnostic. Whether a team is using Scrum, Kanban, SAFe (Scaled Agile Framework), or a hybrid approach, the existing work approach is the starting point. Agile SPICE provides interpretation notes that show how evidence from any of these frameworks maps to ASPICE base practice indicators.
Do the AGL Processes Appear in the ASPICE Assessment Report?
Yes, but as substitutes, not additions. The sponsor and assessor agree upfront which processes are assessed using Agile SPICE. The assessment still produces ASPICE capability level ratings on the same scale, so the report an OEM receives looks the same.
- Agile SPICE: What It Is and How Jama Connect® Enables Compliance - July 22, 2026
- [Webinar Recap] Making Sense of ASQMS: A New Standard for Automotive Software Quality - September 24, 2025
- [Webinar Recap] Achieving ASPICE 4.0: Overcoming Key Challenges - November 13, 2024