If you are developing systems in automotive, medical or aviation business, you will have to document and trace your requirements in a pattern called the V model. How could this fit with Scrum? Scrum is agile and we want to have lean documentation, we don’t need a V model, right? Or do we? In this blog post we, Jean-Pierre Berchez and Joachim Pfeffer, provide some insights about agile Systems Engineering.
Scrum or the V model?
Sometimes we hear this question and our answer would be: we need both of them. But isn’t the V model a slow and bulky process, the contrast to Scrum? Short answer: no. The V model is not a process model. It does not prescribe any sequence of work. It is a consistency model, which helps to keep requirements, architecture and test cases consistent. You can change any spot in the V model at any time, as long as you are able to keep the information consistent.
Don’t get confused by your product development process, which uses the V model in a waterfally way, with requirements freezes and design freezes etc. This is a process design of your organisation, to simplify the consistency management, this is not the V model. If you would really be able to freeze something, it would be more easy to keep it all consistent – but as we all know, this is wishful thinking.
From our point of view, Scrum helps to cope with organizational complexity and the V model helps to cope with product complexity. So both approaches work in different dimensions and work perfectly together. By the way: it is not easy to do anything without a V model. If you want to cook pasta this evening, you will work in a perfect V model: expectations, architecture and decomposition into pasta and sauce, building the components, integration (hopefully in the pan, not on the plate), verification (it tastes like expected) and validation (do i really like pasta on this foggy winter day?).
The two faces of a requirement
Every Scrum Team faces the challenge to document what is currently inside the product. User Stories often change existing product behaviour, thus the documentation of “what is in the product” is covered by automated test cases – or separate product requirements. So let’s talk about requirements and why they are useful. In discussions and standards the two faces of a requirement often are mixed up: You could divide the attributes of a requirement in two groups: short-term documentation (e.g. effort, risk, cost, release assignment etc.) and long-term documentation (e.g. product behavior, tracing to test cases and test reports, tracing to system architecture etc.). Effort, risk and cost are no longer relevant after the requirement is implemented and tested. However the long-term documentation has to be available as long as the product development goes on (in compliance environments storage times are given by standards). As you can see, PBIs cover the short-term documentation. A long time ago, when Scrum was run paper-based, all User Stories were thrown into the recycle bin after a Sprint. Scrum does not provide a solution for the long-term documentation, this is up to us.
When developing complex systems, we need a concept for our long-term documentation, independent if we apply Scrum or work in a more traditional way. Skipping this documentation is pure technical debt, so the question is not if we need it but how we accomplish it. Software tools for agile teams often lack the ability of version control for Backlogs and Product Backlog Items (PBIs), so specialized requirement tools come into play. However this is just a sidenote, we don’t want to dive into the tool discussion here. Let’s move on to the life of a Scrum Team between Backlogs and traced requirements.
The second life(cycle) of a Product Backlog Item
When working with Scrum and “real” requirements we encounter two different lifecycles which we have to synchronize. A PBI, e.g. a User Story, is somewhen ready, is then planned into a Sprint and (hopefully) is “Done” at the end of the Sprint. Traditional requirements often follow a very different lifecycle, an example is depicted in the figure below.
A Scrum Team has to define how these lifecycles are synchronized. The real agile way would be: Everything is done in Backlogs until the sprint planning. The traced requirements then are created by the Scrum Team within the Sprint (example 1 in the figure). More traditional and less agile synchronization points are depicted in example 2 and 3.
Hint: The relationship between PBIs and requirements might also require a documented traceability between PBIs and requirements, which will make the PBIs also longterm-documentation in the sense of stakeholder requirements.
Summary
There is no blueprint, every team or organization has to find its own way, how to deal with short-term documentation and long-term documentation. The “way” relates to the process as well as to the tool landscape. We just wanted to enrich the discussion by introducing the two scopes of documentation – and to restore the V model’s reputation for agile Systems Engineering.
Want to learn more?
Our next Blog-Topic will be: "Traditional requirements vs. product backlog items in "Hardware" Scrum?"
Our Webcast regarding "Hardware" Scrum will be on the 16th April 2026 here at Scrum.org: German edition Scrum Pulse: Von starren Prozessen zu flexiblen Teams - Wie Scrum die Hardware-Entwicklung revolutioniert | Scrum.org
Additional Sources (German Language):
https://www.scrum-events.de/training-details/certified-agile-systems-engineer
https://joachim-pfeffer.com/case/