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)
- 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.
We have to de-agile our project and split it into phases:
- Development: here we do Scrum at its best - but we are never able to ship our product after any sprint
- Documentation: all documents will be finished, translated and ready to be shipped
- System Release Testing: the shippable product will be tested from scratch
- Quality Management: all documentation and project results will be reviewed and the final "Go" is expected
- "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