How to Run the V-Model and Agile Sprints at the Same Time
The sprint schedules the work, the V defines the evidence, and the system model is where the two meet.
Almost every automotive programme already runs the V-model and agile sprints at the same time. The V is the process your customer, your quality department and your assessor recognise. The sprint board is where your engineers spend their week. The useful question is how to combine the two so that the sprints shorten feedback loops while the V still produces a defensible engineering record at the end.
Welcome to MBSE Explained. Most advice on this topic stays abstract, and some of it recommends the one arrangement that reliably fails. This post sets out a concrete method instead: what to change, in what order, and what has to stay sequential however agile the team becomes. It is drawn from my field guide, Sprinting through the V.
Can You Use the V-Model and Agile Together?
Yes, and the standards are not the obstacle. Automotive SPICE defines process outcomes, base practices and work products, and it assesses whether those outcomes are achieved and the evidence exists. It does not mandate a lifecycle. ISO 26262 defines a safety lifecycle, the work products at each level and the confirmation measures around them, and it says nothing about sprint length or how many passes the architecture takes. intacs, the body that certifies ASPICE assessors, even publishes Agile SPICE, a model that maps agile practices onto the assessment so teams can demonstrate compliance in their own working style.
So compatibility is settled. What remains open is the method, and that is where most teams go wrong.
Why Most Teams End Up in Water-Scrum-Fall
The common move is to introduce Scrum to the development teams and leave everything around them unchanged. Requirements and architecture are still written up front by a different group. Integration and verification still happen at the end. Sprints occupy the middle third of the lifecycle, floating in a sequential process.
Within a few months the pattern is recognisable. Sprint goals turn into activity descriptions such as "continue work on the HV interlock concept". The review has nothing executable to show, so it becomes a status meeting with slides. ASPICE work products are assembled in a documentation push before the assessment, disconnected from the sprints that supposedly produced them. Velocity is measured and never used, because the delivery date was fixed by contract before sprint one.
This is Water-Scrum-Fall, and it is the most common state of the industry. Several popular guides recommend exactly this arrangement under the name of wrapping agile inside the V. It keeps the ceremony overhead of agile and the change resistance of the V, and delivers the benefits of neither, because the feedback loop that actually hurts, from architecture decision to integration result, is as long as it ever was.
What Each Side Gets Right
Before fixing it, both approaches deserve a fair hearing, because a hybrid that ignores either one gets rejected by the organisation.
The V-model earns its place through three properties. Bidirectional traceability links every requirement to its realisation and its verification, and it is the single most enforced property in an ASPICE assessment. Corresponding verification gives each specification level its own test level, so system requirements are verified by system qualification tests instead of a pile of unit tests. Level discipline keeps register detail out of system requirements and keeps the record navigable. Real forces also push automotive work towards sequence. A PCB spin takes six to ten weeks, a Tier 1 signs against a frozen requirements baseline, and type approval is a one-off event nobody repeats every fortnight.
Agile earns its place through feedback latency. In a strictly sequential V, the gap between making an architectural decision and learning whether it was right can be six to twelve months. By the time integration reveals that the CAN bandwidth budget was optimistic, suppliers have tooled and the safety concept has been written on top of the assumption. Short loops exist to find that out while the decision is still cheap to change.
These two do not conflict. Agile conflicts with the sequential execution of the V, which is a different thing from the V itself.
The Reframe: Evidence and Scheduling
The way forward is to stop treating the V and the sprint as rival lifecycles competing for the same slot. They answer different questions.
The V-model is a structure of evidence. The sprint is a structure of scheduling. They are orthogonal, and the model is what joins them.
The V answers what artefacts must exist, at what abstraction level, with which trace links, verified by what. It is a static description of a complete, defensible engineering record, and it says nothing about time. Nothing in that structure requires the artefacts to be completed left to right. That ordering is a habit inherited from an era when the artefacts were documents in a filing system.
The sprint answers what gets worked on next, by whom, finished when, and inspected how. It describes flow and says nothing about correctness.
The system model is where they meet. Every backlog item resolves to model elements it creates or changes, and every node in the V's evidence structure is realised by model elements. Two practical rules follow from that. Keep engineering content off the sprint board, so the board tracks work while the model and the requirements tool hold the requirements, architecture and trace links, and each backlog item simply references the model elements it will touch. And treat the sprint increment as a model increment, meaning a larger, still-consistent, more verified model plus whatever it executes: a MiL run, a SiL build, a HIL result, a bench measurement. That is the automotive replacement for "potentially shippable software", and it gives the sprint review something real to inspect.
This only works if the artefacts are model elements. In a document-centric V, a change at the top propagates by hand through a stack of Word files, so iteration genuinely is expensive and the organisation is right to resist it. In a SysML model the change propagates through the model's relationships, which is why MBSE is a precondition for this workflow and why requirements traceability in the model matters so much.
Slice the V Vertically
This is the step most published hybrid models skip, and the one teams need most.
The intuitive decomposition is by V level, with system requirements in sprint one, architecture in sprint two and software requirements in sprint three. That is horizontal slicing, and it reproduces the sequential V with sprint boundaries drawn on top. Nothing is verified until the layers are stacked, so the feedback latency is unchanged.
A vertical slice is one thin path through the entire V at reduced scope. One capability is specified, architected, allocated, implemented in the model or in code, and verified at the right level, within one or two sprints. For an EV traction inverter, a good first slice is torque command acceptance and limitation under a DC-link voltage constraint. It runs from a stakeholder requirement, through system requirements for torque accuracy and response time, into an allocation to the torque manager block and its interfaces, down to a software requirement and a control model, and it ends with a MiL simulation verified against the response-time requirement. The next slice adds thermal derating, the one after it fault reaction, and then the safety mechanism for unintended torque. Each slice re-traverses the V and deepens the model.
The value lies in what surfaces early. A thin slice drags the interface questions and the abstraction-level disagreements into the open in week two, long before integration in month nine.
The familiar "As a user, I want" story template transfers badly to systems work. This one makes the trace links and the verification method explicit at planning time:
Slice: Torque derating on inverter over-temperature So that: the inverter stays within thermal limits without an abrupt torque loss that would surprise the driver Touching:
ThermalManager,TorqueManager, interfaceIF_ThermalDerate, state machineDeratingStrategyDeriving from: SYS-REQ-0142, SYS-REQ-0143, SG-03 Verified by: MiL simulation of the derating profile against SYS-REQ-0143, with the system qualification test case drafted Safety relevance: ASIL B
Four slicing rules keep it honest:
- Every story crosses at least two V levels. A story that touches only one level is a task in disguise.
- Every story ends in a verification artefact, including architecture work, which is verified by review and consistency analysis.
- The first slices are the ones whose failure would most change the architecture. In a safety-critical domain, value largely means retiring risk early.
- One story never spans too many levels. A story running from stakeholder requirement to unit test is too big, so split it at the architecture boundary.
Run Three Cadences Instead of One
A single sprint rhythm cannot carry both a model change and a hardware build. The workflow therefore runs three nested loops, adapted from the nanocycle, microcycle and macrocycle structure in Bruce Powel Douglass's Harmony aMBSE process.
The nanocycle runs from hours to a day. Every model change gets an immediate check, such as re-running the interface consistency check, confirming that a refined requirement is verifiable, or executing a modified state machine against its scenario. No model change is left unchecked overnight. Most of the quality gain comes from this level, and it depends heavily on tooling, because nobody runs a forty-minute manual check every day.
The microcycle is the two-week sprint. It delivers a demonstrable increment built from vertical slices, every completed item meets the Definition of Done including its trace links and verification artefact, and the model is baselined at the sprint boundary. Two weeks suits analysis-heavy systems work better than one week does, and four weeks lets integration debt build up past the point of cheap correction.
The macrocycle is a programme increment of ten to twelve weeks, five or six sprints framed by a planning event and an integration event. This is the layer that faces outward. Customer milestones, A, B and C sample builds, hardware design freezes and gate reviews all attach here, and ten to twelve weeks is also roughly one PCB spin plus assembly and bring-up. The planning event at its start, with systems, software, hardware, test, safety and ideally the supplier in one room, is the single most valuable ceremony in the whole approach. It is SAFe's PI planning event, and it works perfectly well without adopting the rest of SAFe.
Each cadence traverses the V differently:
| Cadence | How it traverses the V | What "done" means |
|---|---|---|
| Nanocycle | One node, one check | The change is consistent and executable |
| Microcycle | One thin vertical slice | The slice is specified, allocated, modelled and verified at its level |
| Macrocycle | All slices integrated across a band | Gate criteria met for committed scope, with deferred scope explicit |
The V is traversed many times at small scope, and those traversals accumulate into the complete structure. That accumulation is what a gate inspects.
Change the Gate Criteria
Of everything in this post, this change has the most leverage, and it lives outside engineering.
A traditional gate asks whether the system requirements specification is complete, reviewed and baselined. A sprint delivers slices. After five sprints the team holds a partial specification of high quality, where the gate expected a complete one of unknown quality. If the criterion stays "all artefacts complete across full scope", the documentation push before each gate consumes whatever slack the sprints created, and the programme slides back into Water-Scrum-Fall within two or three cycles.
The fix is to define gates around committed scope: every artefact complete for the scope committed to this milestone, with the remaining scope explicitly deferred and tracked. That decision belongs to programme management and quality. It also explains why so many agile transformations in automotive stall even when the engineering teams do everything right. The part that had to change was never in the engineering department.
What Still Has to Stay Sequential
A workflow that pretends hardware iterates like software gets rejected by the organisation within two quarters. Some things genuinely cannot run on a two-week loop, including fabricating physical hardware, renegotiating a supplier statement of work, and repeating type approval or an EMC campaign.
The answer is an asymmetry. Iterate at high frequency everything whose cost of change is low (models, requirements, software, simulation), and commit everything whose cost of change is high (hardware builds, supplier scope) at deliberate, well-informed decision points on the macrocycle. Hardware work still happens inside sprints as analysis, tolerance stack-ups, thermal simulation, schematic review and DFMEA sessions. Fabrication is the part that runs on its own cadence. A design freeze then becomes a decision the team takes with evidence in hand, where it used to be a date the programme simply reached.
Safety follows the same logic. Item definition and a first-pass HARA belong in sprint zero, before iteration starts, because they define the boundary inside which iteration is safe. Inside that boundary, safety requirements become backlog items with their own Definition of Done, and the safety case is maintained continuously by a named owner. An architecture change that crosses the boundary triggers a planned impact assessment, which keeps it out of emergency territory.
Questions Teams Ask
Does Automotive SPICE require the V-model? No. ASPICE defines outcomes and work products and leaves the lifecycle to the organisation. The V in the reference model describes how outputs map to their verification, which is a different thing from a waterfall schedule. If ASPICE compliance is your main concern, see how ASPICE 4.0 aligns with model-based engineering.
Can you iterate a system architecture? Yes, until it has been handed to a supplier with a purchase order attached. That constraint is commercial, and it is an argument for iterating hard before commitment.
What sprint length works for automotive systems teams? Two weeks is the sensible default. It fits analysis-heavy work such as a thermal study or a HARA workshop while keeping integration debt small.
What do you demonstrate at a sprint review without working software? An executed state machine or activity diagram running a scenario, a MiL or SiL simulation showing a control strategy meeting a requirement, a HIL run, a bench measurement, a traceability view from a stakeholder requirement to its verification result, or an analysis result together with its effect on the design. Status slides and "the document is in review" do not count.
Where do the ASPICE work products come from? From the Definition of Done. When every completed item must carry its trace links and its verification artefact, the work products accumulate as a by-product of the sprints, and the assessment no longer needs a four-week reconstruction exercise. The full compliance picture, including what ISO 26262 itself says about agile, is in agile ASPICE and ISO 26262: compliance evidence inside the sprint.
Going Further
This post covers the core of the method. Choosing between existing frameworks such as SAFe, Agile SPICE and Harmony aMBSE is a separate question, compared in V-Model vs Agile in Automotive: Six Hybrid Workflows Compared. If the V-model itself is new to you, start with the V-model explained.
The full workflow is in the book, including sprint anatomy for a systems team, the three-lane structure for hardware, a twelve-week worked example on an EV traction inverter, Definition of Ready and Done checklists, and a ninety-day adoption roadmap.
That's the mission here at MBSE Explained, simplifying systems for smarter EVs. If your team is running sprints inside a V right now, which part breaks first for you: the slicing, the gates, or the hardware cadence?