What to put in the Defenition of Done
Like "implement this requirements but make sure you have done system testing and integration testing". As the guide says, it should be used to assess the product increment.
My question is can I put some weak formulatings in it or is it recommended only to be hard, measureable facts?
I want to structure the DoD that there is space to include best practises on software development and rules the Development Team made themselve. For Example: "Make your function name explaining what the code does." or "Try to avoid commenting you code and make it self explaining".
This could be evaluated by a code review. On the other hand I could shift this into a coding guidline and refere from the DoD like: Code review must be done against the coding guidline.
The second point is about technical depts like in the discussion https://www.scrum.org/Forums/aft/663#3526. In this case I mean smelly code that needs to be refactured to gain maintainabillity.
I would like to put in the DoD: Code must stay maintainable. Every action that is needed must be made by the Development Team to ensure maintainabillity.
Or should I define a test or metric to ensure maintainabillity?
This is all about code and product quality and therefore I want to have this in the DoD.
Another point to have it there is that the Product Owner (PO) and the Development Team (DT) aggreed on this quality level.
In my opinion the Development Team knows very good what make sense to produce high quality products, but under pressure they start to trade qualtiy against velocity.
The PO tries to get more for less and might not see how he accidentily causes the DT to focus on velocity and they start to forget their good intentions to produce high quality code.
And I understand this as it seems that nobody but the DT seems to concern about the quality. The truth is that the quality standards are just not transparent. But If I put this in the DoD then it is like an aggreement between the PO and the DT that they get the time to produce qualtiy and that they have to produce this kind of qualtiy.
I look forward to get your responses
> My question is can I put some weak formulatings in it or is it recommended only to be hard, measureable facts?
The hard, measurable fact is that work is either Done or not Done. The Definition of Done can consist of weak formulations as long as it is agreed, by the end of the Sprint, that the work is fit for potential release by the Product Owner. The stronger those formulations are the easier this will be.
> I want to structure the DoD that there is space to include best practises...
That's not a good idea, because the purpose of a DoD is to determine whether or not an increment is potentially releasable. If certain practices must be observed in order to meet that criterion, then they are essential practices and not just best ones.
Unit testing may be essential, as might a certain degree of code coverage. They could reasonably make it into a DoD and no release would be possible unless those terms are satisfied. On the other hand, following certain commenting conventions might be a best practice, but should a release be held hostage to it?
> I would like to put in the DoD: Code must stay maintainable
That depends upon whether or not maintainability is considered essential for release. This is a joint Scrum Team decision based upon the Product Owner's strategic vision for the product, and the Scrum Master and Development Team's understanding of how future work could be affected.
> should I define a test or metric to ensure maintainabillity?
If you can define a test or metric to ensure maintainability you are set to make a fortune.
I will not put an best practise document into the DoD as you suggested. With the whole Scrum Team together I will formulate a kind of manual tests set and reviews that must be done before an increment could be released in order to have a certain level of quality.
I will start with the most easy formulating of these test cases or acceptance criteria and adapt if neccessary.
Thank you for your advice!