Wir tauschen heute Anekdoten über die „Definition of Done“ aus, in denen es darum geht, wer die DoD beeinflussen kann und darf, wie wir sicherstellen, dass die DoD auch verwendet wird und wie man die DoD kontinuierlich weiterentwickeln kann. Zuletzt erörtern wir noch die Sinnhaftigkeit einer „Release Definition of Done“.
- Scrum Guide (Ken Schwaber, Jeff Sutherland): http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-German.pdf
- The Definition of Done workshop (Dominik Ehrenberg): https://agileblogorg.blogspot.com/2012/08/the-definition-of-done-workshop.html
- Definition of Done traffic light (Dominik Ehrenberg): https://agileblogorg.blogspot.com/2012/11/definition-of-done-traffic-light.html
- Growing DONE – How to make the Definition of Done work for your team (Richard Lawrence): http://agileforall.com/growing-done-how-to-make-the-definition-of-done-work-for-your-team/
In unseren Teams haben wir gute Erfahrung mit der Abbildung von Punkten der DoD in Tasks. Für uns ist sie so wie eine Checkliste für alle Storys. Ungünstig ist, dass zum Beispiel ein Spike typischerweise keinen Changeprozess im Fachbereich auslöst oder ein Codereview braucht.
Es erhöht aber die Transparenz bezüglich noch zu erledigender Arbeit enorm!