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.
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:
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.
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).
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).
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.
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.”).
So how will your project meet the regulatory requirements? Here’s how I would do it:
Yes you do! And you have to deliver to a deadline. Now if time is getting short, which would you prefer?
Even if you really have to deliver everything, option 3 is your best choice, for your customer and your reputation!