How does Schematron fit in with Scrum?
This a follow-up to Error Messages and Diagnostics should be Inputs to the Developer not Outputs. According to that, error messages and diagnostics should be provided through the Product Manager as details on the appropriate Product Backlog items.
In Scrum terms, you want to add Schematron validity as part of the Definition of Done (i.e. the criteria used by the development team to know that the current increment of software is really completed and potentially ready for release) for all work in the project.
It might be something like this
(An exception may be made for small, simple ephemeral documents that are consumed as soon as they are produced, which must be validated by unit tests. DOMs may also be validated as part of unit testing. )
(An exception may be made for small, simple ephemeral documents that are consumed as soon as they are produced, which must be validated by unit tests. DOMs may also be validated as part of unit testing.)
If you are using some subset of a large standard schema, or while your application only accepts subsets of some larger schema, you may also want to have a similar rule for input firewalling: rejecting input documents (real or test) that have features that are not implemented yet. It depends on whether this is an issue for your system. (These kind of assertions are implementation guards rather than business rules or schema rules.)
There are other rule possible too, which may be more suitable if your sprint involves developing new schemas:
There may be other wrinkles and exclusions. You need to come up with a common understanding of the difference between a document schema rule and a business rule, being aware that standard schemas often have simple business rules embedded, such as lists of allowed attributes, which may mean you cannot be too strict about the partition.
It is increasingly common for Scrum teams to also have a Definition of Ready, which is the bottom-line acceptance level for items on the Product Backlog to be accepted into a Sprint Backlog. The more that the acceptance tests can be defined the better for estimating the tasks involved. So for Schematron, you just want to formulate the assertion texts. Don’t write a Schematron schema or any XPaths, just make a list in words, perhaps using a template like “An X should have Y, because/so that Z”.