Definition of Done – More Precisely

Als ich Scrum einführte hat das Team mit mir unsere “Definition of Done” erarbeitet. Seitdem hängt sie öffentlich an der Wand und jeder kann sie einsehen. Die Punkte ähneln vermutlich denen, die jedes gute Scrum-Team festgehalten hat: “Potential shippable”, so weit wie möglich mit Unit-Tests abgedeckt, unseren Coding-Standards entsprechend, getestet und dokumentiert.

Nun ist mir aufgefallen, dass wir jedes mal, wenn wir ein neues Release freigeben, überlegen müssen, ob das Changelog auch alle (für den Anwender interessanten) Änderungen enthält. Bei neuen Features ist das ja noch relativ einfach: Userstories abschreiben. Bei Bugs wird es schon schwerer – da müssen nämlich unter Umständen etliche rote Zettel am Taskboard durchgeschaut – und sich dann noch erinnert werden, was die Stichpunkte darauf bedeuten.

Um die Sache zu optimieren haben wir unsere Definition of Done erweitert: Die Aktualisierung des Changelogs, sobald eine Story (oder ein Bugfix) implementiert wurde ist neu dazu gekommen. So kann man die DoD auch prima als Checkliste dafür verwenden, ob ein Zettel am Taskboard auch tatsächlich nach “Done” umgehängt werden darf.

Hinterlasse eine Antwort

Pflichtfelder sind mit * markiert.

*


*