How to Combine Scrum and the V-Model of Software Development

Not every Scrum team may define its own software development process. The reasons for this are often regulatory requirements of the respective industry, customer requirements or existing processes that have grown over many years in companies. V-model oriented development processes are particularly common in this environment. This presents Agile Coaches and Scrum Masters with the challenge of integrating the existing V-Model processes with the Scrum framework. This article shows how to combine Scrum and the V-Model of software development.

Motivation and Background

The Scrum theory does not define and describe a development process according to which the Scrum team should or must work. With the Scrum Events, it merely defines a framework for the process organization, as well as values, artifacts, pillars and roles within a Scrum team. Theoretically, each Scrum Team is free to choose and define its own development process.

Unfortunately, the practice looks a little different, and often much more complicated. A not inconsiderable number of Scrum teams, especially in established industries, are not completely free in the choice of their development processes. These restrictions often result from regulatory requirements of the industry or explicit requirements of the customers regarding the processes to be applied. Often the V-model of software development is used in these organizations. This is used especially when there are high requirements with regard to the traceability of the requirements through the code, the selected implementation and the relevant tests.

When companies carry out an agile transition from classic project models to agile methods, the new methods collide with the grown, established processes along the V-model. Since the requirements regarding traceability and documentation remain even when using agile methods, it makes sense to integrate the existing processes with Scrum. This article shows why this is not a contradiction and how existing processes in the V-model can be combined with Scrum.

The V-Model for Software Development

Let us now take a look at the V-model of software development. The V-model is a process model that was originally designed for software development, but is now also used in many other disciplines. It represents a further development of the classical waterfall model. In a development according to the waterfall model, feedback on errors and problems found is only possible at the very end of the process chain. Much earlier feedback is provided when using the v-model.

The name V-model is derived from the classic representation in the form of a V. The left side of the V represents the process steps of requirements engineering and implementation, while the right side of the V contains the process steps of validation. In each case, implementation and validation steps of the identical abstraction level are opposite each other. From this it can also be derived in which level of detail of the implementation an occurred error can be found. The following illustration shows a possible representation of the V-model and the process steps it contains.

As we can see, the V-model spans two dimensions. On the one hand, the chronological sequence of the development from the first to the last development step is shown, and on the other hand, the depth of detail in relation to the individual process steps is also mapped. The feedback loops of the individual validation steps to their associated development steps can also be seen clearly.

Process Steps in the V-Model

The first process step of the V-model is the specification of requirements in collaboration with the customer. Then, functional requirements of the product are derived from these customer requirements. These two steps form the requirement engineering in the V-model of software development. The next two steps serve to create the software architecture and, derived from this, the software design of the individual software components.

In the center of the V-model, at the bottom of the V, is the actual implementation step. Here, the defined software components are developed according to the defined software design. This step has by far the highest level of detail of all process steps.

The implemented solution is validated in a test of the individual components, which is equivalent to validating the specification of the software design of the respective component. In the integration test the interaction of the different components is tested, and thus the software architecture as such. A system test follows, in which it is examined whether the functional requirements of the solution were correctly implemented. Finally, an acceptance test follows. This serves the validation whether the finished product solves the problem placed by the customer / the requirements placed by the customer satisfyingly and completely. If an error is found in one of the validation steps, the cause of this error is to be found in the equivalent process step of the left side of the V.

The V-model of software development thus defines the basic steps of the software development process. It describes the various steps of requirement engineering, implementation and validation. Along these process steps, a specific implementation of the V-model can take place in each organization in adaptation to the needs of the organization. However, the V-model does not define a time frame for the sequence of these processes, nor how and when the various development steps should take place.

Product Development With Scrum

In contrast to the V-model, Scrum is not a meta-description of a development process, but a framework which, among many other aspects, enables the temporal structuring of the processes of an organization. As the Scrum Guide 2020 tells us:

Here Scrum specifies things like its own three fundamental pillars, the roles within a development team, the events to be performed by a team, the artifacts to be processed and produced, as well as the values to be established and lived in a team.

Requirement Engineering With Scrum

The basic event in Scrum is the Sprint. This is a container for all other activities in Scrum. The duration of a sprint can be up to four weeks, should ideally be constant, and can be chosen by the team itself. Within a sprint, the team transforms the Sprint Backlog into a new iteration of the increment. Furthermore, the team is continuously involved in the development, coordination and clarification of new requirements. This process is called refinement and describes the requirement engineering in a Scrum team. This continuous process explicitly does not begin and end at the boundaries of a single sprint. It is operated across sprints and serves to clarify the content and technical aspects of future requirements/tasks.

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

In summary, Scrum defines the Sprint Backlog as a collection of the requirements / tasks to be implemented within the Sprint. The Increment describes the resulting new version of the product. Since Sprints build on each other incrementally, the product also grows incrementally. The essential characteristic of this Sprint Backlog is, that every task which is completed can be delivered to the customer. Hence, a Sprint is a closed loop in which requirements are turned into a shippable version of the Increment.

However, what Scrum explicitly does not specify is the way in which a team should transform the Sprint Backlog into the Increment. This “way” is what we know as the development process. This process is explicitly not highlighted by the Scrum framework because it is normally industry, organization and often even team specific. In a Scrum team, this process contains the tasks of implementation and validation, while the requirement engineering is covered by the refinement. Here too, it is not described how the refinement is to be carried out, but only that it has to happen. In contrast to the V-model, Scrum maps the requirement engineering in a separate process that stands beside the development process.

Combining Scrum and the V-Model for Software Development

Let’s now take a look at how the meta-process of the V-model can be combined with Scrum. As we have already seen, especially companies with established, classic processes that are starting an agile transition face this problem. On the one hand, we have the development process described in the V-model, and on the other hand, the rules defined by Scrum for structuring the project organization.

As described in the last section, in Scrum there is a separation between the actual development process (implementation and validation) and the requirement engineering process. This separation does not exist in the V-modell of software development. However, this point is exactly where we can split the V-modell to make it compatible with the requirements of Scrum.

Classic organizations and development projects work with requirements documents and scope statements. The requirements documents describe the customer’s requirements, while the scope statement describes the intended implementation of these requirements, including all deviations. In most cases, the discussion and clarification of those documents, takes place at the beginning of the project. Any subsequent changes are then mandated by change requests in complex change processes and generate not only additional overhead, but also additional costs.

Splitting up the V-Model

The combination of Scrum and the V-model of software development is made possible by the fact that the requirement engineering is stretched over the entire duration of the project. The classical approach of the V-model is therefore transferred into the continuous refinement process of Scrum. Of course, this requires prioritization of the requirements by the customer, because only in this way can the most important requirements be discussed, refined and implemented first. This makes it possible to always refine requirements two to three sprints before their actual implementation, to adapt agile priorities, and thus to introduce Scrum in a classically influenced environment.

All requirements for a product developed with Scrum, including the refined and agreed requirements, are found in the Product Backlog. From this Product Backlog, the Scrum team selects the requirements to be implemented in the next sprint, during the Sprint Planning event. These then form the artifact of the Sprint Backlog. Now, here comes the crucial part. As already mentioned, Scrum does not describe a development process. How the Sprint Backlog is transferred into the increment is therefore solely in the hands of the development team or, if applicable, the development organization.

The implementation of the Sprint Backlog, which is the creation of the Increment, can now take place according to the implementation and validation steps described in the V-model. A restriction here is that all requirements successfully passing the acceptance test must fulfill the Definition of Done. The Increment must therefore remain in a deliverable state at all times. Thus, the separation of the V-model into a requirement engineering phase, and a development and validation phase makes it possible to combine Scrum and the V-model for software development.

Final Thoughts

In this article we have looked at how it is possible to combine the classic V-model of software development with the agile framework Scrum. We have seen that this requires breaking up the development process according to the V-model. The transfer of the requirement engineering into the refinement process lived by Scrum teams enables the combination of established processes with agile methods. However, it is necessary to win over the client for cooperation according to this model. Only if the customer is willing to prioritize his requirements accordingly and to coordinate them in a continuous process, the combination of Scrum and classic development processes according to the V-model of software development can succeed.