Transition of the Definition of Done in Regulated Environments

Projects in regulated environments have to follow strict guidelines and rules. Laws, normative regulations, product risk analysis, and detailled development processes are defined and controlled by Quality Management departments. Besides of that you have to deal with external groups like editorial staff for documentation.

From a User Story's point of view all of the following is necessary for a proper Definition of Done:

• Done: internal Scrum DoD (specified, implemented, unit tested, reviewed, UI tested, integrated, and so on)
• Done-Done: external Documentation DoD (readme edited, online help edited, user manual edited, translated, layouted, printed)
• Done-Done-Done: external System Release Testing DoD (regression tested, all stories tested, documentation tested, system interoperability tested, etc.)
• Done-Done-Done-Done: external Quality Management DoD (risks analyzed, overall risks reviewed, remedial actions defined, project documented, and much more)

One could argue to change the organization to move the external departments into the agile team. Not only laws and regulations make this impossible but there are simple economic and time issues as well:

• Documentation can't be translated on a User Story basis every time something changes. This would get too expensive and it is much easier for an external translator if she has the final document ready at hand. Nevertheless a translation into a dozen languages may take up to 4 weeks.
• System Release Testing can't be started until everything is finished and shippable. Unfortunately some unexpected behavior on a User Story basis may be reported which need instant action (code adaptation, re-documentation, re-review, re-testing).
• Quality Management departments traditionally follow a very waterfalling approach. After every other thing has beed finished they start to look at a project, do some reviews, read project documentation, and - worst of all - start asking questions and suggesting changes here and there. These changes may have impact on single User Stories.

So how do we deal with all these "Dones"?

We have to de-agile our project and split it into phases:

1. Development: here we do Scrum at its best - but we are never able to ship our product after any sprint
2. Documentation: all documents will be finished, translated and ready to be shipped
3. System Release Testing: the shippable product will be tested from scratch
4. Quality Management: all documentation and project results will be reviewed and the final "Go" is expected

Next, we move as many DoD parts as possible from the later phases to development:

• "documentation drafted" from Documentation to Development: sketch the documentation changes for every single User Story. I recommend to find a semi-team member in the documentation department and deliver all drafts after each sprint to her for a first review.
• "risk analyzed" from Quality Management to Development: think about product risks of every single User Story. Again I recommend  to closely work with a QM guy after each sprint.
• In general "any small thing finished" from later phases to Development

With this approach we are able to strengthen the DoD we are tracking in our Daily Scrums. We move as many tasks as possible to the early development phase and thus we handle risky things right from the start.

The big advantage of more early "Dones" is the expansion of the agile, iterative development phase. Agile progress tracking can unfold its power with much more tasks being finished during development. As a result all later phases have less risk of failure.