Using Scrum to Validate Software during Agile Development

#Using Scrum to Validate Software during Agile Development

Scrum is an increasingly popular way to develop software, a methodology to implement Agile Software Development.  Though Scrum has been coming up for a few years now, it’s not always clear how to validate software that is being developed this way. Specifically for pharmaceutical and biotech companies it’s valuable to show deliverables of incremental sprints in Scrum can be combined with the deliverables expected by the GAMP 5 guide.


There are several accepted definitions of SCRUM, but for now, let’s go with the following:

“Scrum is a development framework in which cross-functional teams develop products or projects in an iterative, incremental manner. It structures development in cycles of work called sprints.”


Sprints are blocks in which Scrum-teams deliver their product. They are iterations of no more than four weeks each (the most common one being two weeks), and take place one after another without pause. These sprints are time boxed, meaning they end on a specific date whether the work has been completed or not, and they are never extended.

Usually, Scrum teams choose one sprint length and use it for all sprints. Though, if they improve they might decide to use a shorter cycle.  At the beginning of each sprint, a cross-functional team selects items (customer requirements) from a prioritized list.  Subsequently, the team agrees on a collective target of what they believe can be delivered at the end of that sprint. The benefit being that the work scope is small and there is a commitment from all participating team members.

During the sprint, no new items are added; changes are put on the product backlog and prioritized for execution in future sprints. At the beginning of every day, the team gathers briefly to inspect its progress and adjust the next steps needed to complete the remaining work in time.

At the end of the sprint, the team reviews the sprint’s results together with the stakeholders and demonstrates what has been built. In the case of software, this would mean a system that’s integrated, fully tested, end-user documented, and potentially shippable. The obtained feedback can lead to changes or additional requirements that are added to the product backlog.


Good Automated Manufacturing Practice (GAMP) is a set of guidelines for manufacturers and users of automated systems in the pharmaceutical industry.

More specifically, the ISPE guide for Validation of Automated Systems in Pharmaceutical Manufacture describes a set of principles and procedures that help ensure that computerized systems, including software, are fit for purpose.

One of the core principles of GAMP is that quality cannot be tested into the computerized system, but must be built into the computerized system during each stage of its development. As a result, one of the key features of GAMP is computer system validation.

Computer System Validation

Computer System Validation (CSV) establishes documented evidence providing a high degree of assurance that a specific computerized process or operation will consistently produce a quality result, matching its predetermined specifications. In other words, CSV is demonstrating that the computerized system is consistently doing what it should be doing and that the data it produces is reliable.


Normally the “V-model” is used to execute this kind of validation. In GAMP this model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.  The left axis represents the stages of a specification and the right represents the stages of verification or testing. Steps in the V-model are sequential, following the arrows, and every next step should only be started when the previous one is completed. During software validation, the deliverables of each step are checked

Validation starts by combining all requirements in a User Requirements Specification (URS). When this URS is approved, the Functional- and Configuration Specifications (FS and CS) are drawn up and the software can be developed afterward. After development, it can be validated together with its accompanying procedures. Only when everything is according to the URS and applicable procedures the software should be released.

Combining both methods

On first sight, combining Scrum and GAMP doesn’t seem possible, because Scrum is an incremental process, i.e. software is delivered in working parts, and validation according to GAMP is sequential i.e. the software is delivered in a whole working package.

However, when confronted with this problem, you can decide to treat each Scrum sprint as a separate “GAMP V-model”. This way, you can perform validation while the software is being developed and this is in line with both ways of working. To have a potentially shippable product it needs to be validated and to validate this product the specifications, functionalities, and documentation all need to be checked.

To establish this, the validation documentation is aligned with the scrum documentation according to the table below:


By combining GAMP and Scrum like described, it’s possible that a cross-functional (development, testing, and validation) team is able to deliver functioning and validated software in a timely matter while meeting all predefined top priorities. Since time is usually fixed, lower priorities might not always make it in the first production release, but this is actually one of the strengths of Scrum; focusing on what must be implemented.

Most software developing companies do not work according to the V-Model anymore and have embraced Scrum. Pharma companies, however, often state that GAMP or the V-Model needs be followed. It is worthwhile to seek some flexibility on both sides to make it possible to start implementing Scrum while maintaining benefits of the V-model. Our experience is that Scrum can definitely help to successfully execute projects on time with the required functionality and quality.

Please feel free to contact us if you have any questions!
Blog by: Anton van Rosmalen - Consultant at Xendo
Contact: Joost Havers - Managing Consultant at Xendo

Subscribe to newsletter