View Source

{excerpt}
_Definitions and suggestions for enforcement._
{excerpt}


h4. Different definitions of _Done_

[Scrum Alliance - What is DoD? | http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod]

[Agile Software Development - DoD | http://agilesoftwaredevelopment.com/2006/05/definition-of-done]

[Agile faq - What is DoD? (example) | http://agilefaq.net/2007/10/24/what-is-definition-of-done/]


h4. How to enforce _Definition of Done_

One practice we have come to value is that another team member reviews and accept a task before it is considered done. This should not be a time consuming or formal process! The obvious advantage of this practice is the Quality Assurance aspect: The chosen solution is verified by another pair of eyes. This often leads to suggestions for improvement. Another benefit is that knowledge sharing within the team comes at very little cost since at least two people will know any piece of the application.


_Peer_ programming might be considered an extreme version of this practice. The [Definition of DONE! 10 Point Checklist | https://www.101ways.com/definition-of-done-10-point-checklist/] seems like a good starting point for defining DoD. Note that that this they accept _pair_ programming as "enough" for done. Pair programming is only that two people is programming together, while peer entails that the two are at equal competence level. Peer programming is a lot better for QA than pair programming, while both support knowledge transfer. We would thus suggest that _peer_ programming automatically entails acceptance of the produced code, while _pair_ does not.

h4. Resources

* [Done Done, by James Shore|http://jamesshore.com/Agile-Book/done_done.html]