How Should We Handle Requirements in a GxP Compliant Agile Software Development Process?

Agile Software Development in GxP Regulated Environments GAMP^® Special Interest Group

User Requirements (Specification)

Successful delivery requires ensuring we build the right system that is fit for the intended use, not just ensuring we build the system right. Traditionally, documented Requirements are termed as the “User Requirements Specification” (URS) within pharmaceutical projects and are often interpreted as a key “must have” document containing the full set of requirements before any other work is done, regardless of what project approach is used. This is the Certainty Mindset in action, that was discussed in our earlier blog However, Annex 11 and GAMP^® 5 Appendix D1 do state that Requirements may not initially be fully defined, e.g., for some Category 5 systems, requirements will be developed during subsequent phases of the project, which nicely fits the Discovery Mindset discussed in the same blog.

In agile, having a “full set of requirements” at the start is not possible nor even desirable. If we had a full set of requirements, we would not be applying an iterative or exploratory approach, and probably not an incremental approach either.

Where do requirements come from?

All companies have a Demand Pipeline of requirements. They may not explicitly talk about having this demand pipeline, but it’s there. New demand can come from many places, such as those helping to Improve the Business like Strategic Goals, initiatives, or value streams, others are from Run the Business where we obtain feedback on the currently live system such as defects or minor enhancements.

With agile, we embrace the Discovery Mindset to get early and often releases into production, repeatedly looping through the Demand Pipeline. Each release giving us another chance to obtain feedback from real usage, to inspect and adapt, altering our plan and adjusting the system as needed. It allows us to Experiment, with Hypothesises to see if our resulting system is meeting the intended needs of the user, customer or patient.

Compliance professionals must also adopt a discovery mindset to support innovators. Often times this involves going back to first principles and exploring alternative ways of managing compliance using new approaches. In its simplest form, this could look like shifting mindset to allow the use automated testing tools or adapting an existing validation process and toolset to be used in conjunction with an agile development methodology.”

Elizabeth A. McLellan

Chief Quality Officer and Data Protection Officer

Suvoda

Those early and often releases can help us deliver Value earlier, increasing our Return on Investment and giving us feedback on how the early releases are performing. Smaller releases inherently lower the Risks associated with the usual large releases. They also help us increase our Adaptability and respond to changing needs faster. All the while increasing Visibility to our stakeholders or customers, into how we are progressing.

How does agile Handle Requirements?

Agile is a generic term, just like the word ‘Science’. The name agile, covers a guiding manifesto and 12 principles. For this blog, we will talk about how the Scrum Framework documents requirements, how most Scrum teams differentiate requirements, and how they can be used within the GxP world of ours. But this won’t be a deep dive into how Scrum works.

Scrum doesn’t use a User Requirement Specifications in a Word document, that has gone through countless reviews and finally an approval. Instead, Scrum has the concept of a Product Backlog that are usually stored in an agile planning tool. It is a list of individual items that have been taken through the Demand Pipeline shown above. These Product Backlog Items (PBIs) can consist of various types of work, such as Defects, Epics, Stories (sometimes called User Stories), Enhancements, etc. reflecting the Product Owner’s current view of scope and priority of what needs to be done.

Most Scrum teams organise the Product Backlog by using Epics as the largest item. Epics are then broken down into a set of small Stories. Just as in the literary world, Epics are just large stories. In this case, large stories (or any other PBI) are just those that can’t comfortably be delivered within a Sprint.

For teams new to Scrum, one way to think of Epics and Stories, is that an Epic is like a Business Requirement (the what), and Stories are its Non/Functional Requirements (the how). Albeit, with a very different style of wording.

An example Epic:

• As an author, I want to be able to print my document, so I can read it without using the computer.

Example stories for the Epic:

• As an author, I want to print my document using whatever the current printer setting is, so that I have a hard copy.
• As an author, I want to print double sided, so that I save paper
• As an author, I want to print in colour, so that I can share a more professional looking hardcopy.
• As an author, I want to print a number of copies, so that I can give them to multiple people.
• As an author, I want the previewing of the printed page to load within half a second, so that I don’t have to wait. (hint: this is Non-functional)
• As an Author, when I try and print double sided, it fails to print at all. (hint: this is a defect)
• Etc….

All PBIs should have a high-level User Acceptance Criteria specified at a high level, for the development team to be able to understand the intent of the PBI and use them as a basis for potential test cases while working on the story

The Product Backlog needs to be kept up to date, reflecting and anticipating changes. The process of ensuring this, is known as Backlog Refinement. Although this process is run and managed by the Product Owner, the work itself requires input from the development team and therefore is usually done in a small team meeting.

Refining the backlog usually consists of:

• preparing product backlog items for the coming iteration – splitting items which are too large or assigning estimates or acceptance criteria to stories without them
• making changes to existing stories – either changing estimates in the light of actual performance or reassessing their priorities
• checking that the assessment of priorities is still correct and changing it as necessary
• creating new stories where a demonstration or feedback has suggested a new need
• removing stories which no longer appear necessary.

Benefits of refining the product backlog

• A backlog is not created with the aim of being an entire and accurate representation of requirements; it is expected that it should change during the project. Refining the backlog is the formal process of doing this. It enables development to begin while some ideas are vague – they can then be enhanced or broken-down during refining, once the Product Owner and team have learnt more during the first few iterations.
• A carefully refined backlog will make sprint planning meetings much faster and more efficient.
• Refining stops the product backlog from becoming an endless list, and helps the team focus on completing what is necessary rather than gold-plating. This helps curb complexity, as well as budget and time over-run.
• By checking the priority formally, the Product Owner ensures the backlog stays up to date with changing circumstances, including what the team have learnt in the last iteration.
• The Product Owner also remains aware of items ‘buried’ in the backlog – especially those that carry technical risk and can review them with the team well in advance of the actual sprint.
• The Product Owner is always Accountable for the Product and Sprint backlogs.

A Sprint Backlog describes what is planned for the sprint to meet the purpose of the Sprint, called the Sprint Goal . It’s essentially a subset of the most important items from the Product backlog Before a Sprint can start, the Sprint Planning session is held. Here, the Product Owner discusses with the team what is most important to work on next, to meet the Sprint Goal. The team and the product owner discuss each potential sprint story looking to understand any architectural, testing, or development tasks, issues, or risk. At the end of the Sprint Planning session, the team have committed to achieving the Sprint Goal, and they have an approved and prioritised Sprint Backlog.

Approvals

As can be seen, both the Backlog Refinement and Sprint Planning sessions, are key governance and approval steps to ensure we Build the Right System.

There are many ways teams document evidence of the Sprint Backlog approval. The worse approaches often result in duplicating information:

• Before the Sprint can start, exporting the tool based Sprint Backlog into a URS document, that is then approved to indicate that the requirements for the sprint are ready to work on.
• Exporting and approving a URS after multiple sprints, when they are ready to perform their final end to end Acceptance or UAT Testing of the release.

These approaches to creating a document version of the backlog, are merely snapshots in time and so they are duplicating information. These duplications are extremely prone to becoming out of date with the actual Product backlog, tests, and code, as time moves on. Having a single source of truth, is more important than the perceived need for a document file.

Acceptance instead of Approval

There is a misconception that if you are using a tool, then you need to use Electronic Signatures.

Tools like Jira, Microsoft AzureDevops, etc, all have immutable change logs built into them. These logs record exactly Who, did What, and When, against each PBI. Plus these tools can be configured to enforce security rights over exactly who can do what.

The tools also have a ‘Start Sprint’ concept that officially starts the clock of the Sprint, which is also recorded within the logs.

These logs are the record of the Sprint Backlog (plan), and a record of what PBIs (requirements) are Approved to be worked upon during the sprint. Teams use this record in place of an electronic signature on a URS document.

During the sprint, PBIs are worked upon and typically moved from a To Do state, to an In Progress state, and finally to a Done state, once the team and the product owner are satisfied the individual PBI is actually finished.

By limiting who can change the status of a PBI to Done to only the Product Owner (or some other authorised team member e.g. Quality Manager), teams are also able to show a record of evidence that the PBI has been satisfactorily completed, works as specified, and is sufficiently tested, and therefore Accepted by the Product Owner.

Don’t be afraid to use tools. Our industry, regulators, etc. have agreed for many years that tools and systems are the only sensible way to maintain and manage GxP records and data related to the pharmaceutical product lifecycle, and that paper documents and records are typically not effective.

Also keep in mind the US FDA CDRH direct that records should be maintained because they are of value to the organization, rather than for a regulator or external auditor.

But what about inspections?

Whilst it might be uncomfortable for some to use a tool to document requirements, it’s worth noting that companies including pharmaceuticals and in industries like critical medical devices, defence, telecommunications, and power generation and distribution have controlled their URS in Requirement Management Tools instead of documents over the last two decades. Tool usage isn’t new. How we handle changing requirements is.

Conclusion

Many pharmaceutical organisations still expect to see a fully formed User Requirements Specification when developing a GxP regulated system, hopefully this article has demonstrated that by planning and storing requirements differently and follow agile principles, we can successfully deliver in a controlled way that is compliant with the spirit of the GxP regulations.

In our next article, we will be discussing the various tool categories and how they help with the Mechanics of building the right system and build the system right.