How do you do Scrum in a regulated environment?

I hear this question often from people in the pharmaceutical branch, air traffic control, banking and finance – any place where strict regulatory compliance is required, and it came up again at my last CSM course.

Regulated environments are complex, both because of the regulations themselves and the high risks associated with the domain being regulated, which means that Scrum is well suited to developing products in this sector. Let’s look at Scrum’s building blocks, some objections to using Scrum in a regulated environment, and then, using traceability as an example, let’s look at how Scrum can be used to address a regulatory requirement.

Building blocks

Scrum is designed for solving complex problems as a team, without defining any domain-specific process. Scrum gives you several building blocks to ensure that your delivered product meets all of the necessary requirements:

• The Product Backlog, a planning instrument
• The Definition of Done, an agreement to ensure quality, 
• The Increment, an additional slice of customer value, integrated into the previously developed slices, and
• The Product Owner, a role that takes responsibility for the whole product

Scrum does not tell you to write any particular documents, but if creating and maintaining certain documents is required for your project, Scrum gives you the mechanisms to ensure that they get written and maintained properly.

Product Backlog

The Product Backlog is the source of all requirements, both functional and non-functional, for a project. All requirements belong on the backlog. Non-functional requirements should appear high on the backlog, so that the Implementation Team and Product Owner can discuss the implications early in the project. Usually non-functional requirements will get translated into functional requirements and/or items in the definition of done to ensure compliance.

The Product Backlog is ordered. The top most item will be done first. Then the next one, then the next one, etc, until “all” the backlog items have been implemented. (More formally, the Product Owner decides when “all” features have been implemented).

Definition of Done

The definition of Done is simply common understanding among everyone in the project on what it means when you say, ‘This feature is done.’ So for instance, if a release note must be written for every feature, then writing the release note belongs in the definition of done. A definition of done typically requires proof that the new functionality has been implemented correctly and that all previously implemented functionality is still working correctly.

The goal is that there should be no undone work at the end of sprint. If that goal is achieved — and teams that achieve it often do so with the help of automated testing — then the Product Owner can call for a release at least at the end of any sprint (and possibly more often, depending on the teams engineering practices).

The Increment

Under Scrum, teams deliver solutions incrementally, once slice at a time. These slices are integrated together to create the entire product. The increment at the end of the sprint should be ‘potentially deliverable’ – there is no undone work, so if the product owner believes there is more value in releasing than not releasing, she can call for a release.

These “slices” are defined by entries in the Product Backlog (and are often called stories). The stories get mapped to acceptance criteria, which can be logged or documented as appropriate. When the acceptance test is green — and the remaining aspects of the definition of Done are satisfied — the story is considered done.

Even if it is not practical to actually deliver at the end of each sprint, it is still desirable to have granular control of what is done. It is by implementing features in small slices and by insisting that there be no undone work at the end of sprint that Scrum teams achieve the ability to deliver predictably. By measuring progress in terms of deliverable functionality, they gain the ability to predict when the total package will be finished.

The Product Owner

When is the whole product really done? When can we really release? That is the decision of the Product Owner. The P-O decides which items will be done first, whether a feature is really done, and when the product as a whole can be released (even if release means “released to the approval process.”).

Meeting Regulatory Requirements

So how will your project meet the regulatory requirements? Here’s how I would do it:

1. Identify the requirements of the relevant regulations, both functional and non-functional, requirements, non-functional requirements, or deliverables – whatever! 
2. Prioritize these at the top of the product backlog. So in the first sprint or two, the team will figure out how to satisfy these requirements. Probably they will produce new backlog items and/or entries in the definition of Done. 
3. Treat the regulators as stakeholders. Identify their needs. They have (or should have, and maybe need help to develop) a definition of ready – when is a product ready for approval. Try to understand that and you can make it easier to get your product approved. Although it may seem impossible, I would try to reach out to them to start a dialogue, explain how we are developing, what Done means in our process. Regulators are people too.

Handling a regulatory requirement