Du entwickelst und testest eine neue Software? Lies weiter, um zu erfahren, warum Du den Unterschied zwischen einer Definition-of-Done und Akzeptanzkriterien kennen solltest.
Warum Du den Unterschied zwischen einer Definition-of-Done und Akzeptanzkriterien kennen solltest
Euer Projekt wird agil nach der Scrum Methode entwickelt. Während des Daily Scrum besprecht Ihr im Team den aktuellen Fortschritt Eures aktuellen Sprints. Vielleicht kennst die Aussage eines Teammitgliedes beim Daily Scrum auch: „Ich bin fast fertig.“ oder: „Die Aufgabe ist zu 90% erledigt.“ Wie kann das Entwicklungsteam mit einer solchen Auskunft sicherstellen, dass das Sprintziel erreicht wird? Das Entwicklungsteam ist für das Erreichen des Sprintziels und die Qualität der Umsetzung verantwortlich.
Eine Lösung kann eine klare Definition der Definition-of-Done und der Akzeptanzkriterien sein. Das hilft Euch dabei, zu erkennen, ob eine User-Story erfolgreich umgesetzt wurde.
Jetzt stellt sich vielleicht die Frage, was ist jetzt eine „Definition-of-Done“, was sind Akzeptanzkriterien und warum Du den Unterschied zwischen einer Definition-of-Done und Akzeptanzkriterien kennen solltest
Was ist die „Definition-of-Done“ (DoD)?
Im offiziellen Scrum-Guide von Ken Schwaber und Jeff Sutherland, den Du hier laden kannst, ist eine Definition-of-Done beschrieben als:
Die Definition of Done beschreibt formale den Zustand der Software, den sie am Ende eines Sprints haben muss. Nur wenn diese Kriterien füllt sind, werden die einzelnen User Stories als fertig akzeptiert. Das Ergebnis eines Sprints wird als Inkrement bezeichnet. Die Definition of Done schafft Klarheit, indem sie allen ein gemeinsames Verständnis darüber vermittelt, welche Arbeiten als Teil des Inkrements abgeschlossen werden müssen.
Häufig entscheiden sich Organisationen dazu, ihre Definition of Done als Checkliste anzulegen. Das bietet die Option, einzelne Kriterien separat abzuhaken. Beispiele für Kriterien einer Definition-of-Done:
- Alle Akzeptanzkriterien werden erfüllt.
- Der Code ist vollständig implementiert und kommentiert.
- Der Code wurde im Pair-Programming erarbeitet und überprüft.
- Die Coding Standards von XYZ und die internen Konventionen ABC wurden eingehalten.
- Der Code steht unter Versionsverwaltung.
- Ein Code Review wurde durchgeführt.
- Die Unit-Tests wurden durchgeführt und bestanden.
- Eine Dokumentation wurde erstellt.
- Ein Eintrag im Changelog wurde angelegt.
Was sind Akzeptanzkriterien?
Akzeptanzkriterien beziehen sich immer konkret auf ein Backlog Item bzw. eine User Story. Sie sorgen für Klarheit: Was im Rahmen der konkreten User Story umzusetzen ist. Sie sind die Basis für Akzeptanztests.
Beispiel für eine User Story:
Als Nutzer einer Cloud-basierten Notizbuch-App will ich Notizen erfassen können, die in meinem persönlichen Speicherbereich abgelegt und von dort auf andere Devices (PC, Smartphone) synchronisiert werden, um die Notizen überall verfügbar zu haben.
Beispiel für Akzeptanzkriterien:
- Eine Notiz mit einem Zeichen wird korrekt erfasst und auf ein zweites Device synchronisiert.
- Eine Notiz mit eingebetteten Bildern (JPG, PNG, BMP) wird korrekt erfasst und auf ein zweites Device synchronisiert.
- Eine Notiz mit eingebetteten Audioaufzeichnungen (1 Minute, 3 und 5 Minuten) wird korrekt erfasst und auf ein zweites Device synchronisiert.
- Änderungen, die an der Notiz auf dem zweiten Device gemacht werden, werden auf das Ausgangsgerät korrekt zurücksynchronisiert.
- Wird die App auf einem ersten Device beendet, dann werden offline gemachte Änderungen an einem zweiten Device wieder synchronisiert, wenn die App auf dem ersten Device wieder geöffnet wird.
Akzeptanzkriterien und Definition of Done – was ist der Unterschied?
Die Definition-of-Done bezieht sich auf das Produkt Inkrement und definiert, wann die Arbeit des Entwicklungsteams abgeschlossen ist.
Akzeptanzkriterien beziehen sich auf einzelne Product Backlog Items, also den konkreten Anforderungen an die Software oder das System.
Tabelle 1: Gegenüberstellung DoD und Akzeptanzkriterien
Eine Gegenüberstellung der Definition-of-Done und der Akzeptanzkriterien findest Du in Tabelle 1.
Abbildung 1: Zusammenhang zwischen der Definition-of-Done und den Akzeptanzkriterien
In Abbildung 1 ist der Zusammenhang zwischen der Definition-of-Done und den Akzeptanzkriterien zu sehen. Die Akzeptanzkriterien beziehen sich jeweils auf ein einzelnes Product Backlog Item (PBI) und sind vielleicht von PBI zu PBI unterschiedlich.
Weitere Kriterien für die Definition-of-Done (DoD)
Bei der Vorstellung der Definition-of-Done weiter oben im Artikel, wurde als Beispiel aufgeführt „Die Unit-Tests wurden durchgeführt und bestanden“. Das ist ein sehr schwaches Kriterium für die Lieferung eines Produkt Inkrements oder eines Releases. Daher ist es sinnvoll, weitere Kriterien für die DoD auf unterschiedlichen Teststufen zu definieren. In meiner Checkliste, die Du hier laden kannst, stelle ich noch weitere Beispiele für eine Definition-of-Done vor.
Vorbereitung zur Prüfung als Blended Learning Online Kurs
Wenn Du mehr wissen willst, wie Du gute Anforderungen formulieren, oder wie Du Dich optimal auf die Zertifizierungsprüfung vorbereiten kannst, buche meinen online Kurs. Informiere Dich auf meiner Webseite der Projektstart Akademie über das Angebot.
Zusammenfassung
In diesem Beitrag habe ich Dir gezeigt, warum Du den Unterschied zwischen einer Definition-of-Done und Akzeptanzkriterien kennen solltest.
Die Definition-of-Done bezieht sich auf das Inkrement oder Release.
Die Akzeptanzkriterien beziehen sich auf ein konkretes Product Backlog Item (PBI).
Warum bekomme ich diesen Newsletter?
Wir hatten in der Vergangenheit Kontakt und Du hattest Interesse an weiteren Informationen der Projektstart GmbH. Falls Du keine weiteren Informationen wünschst, kannst Du Dich gerne vom Newsletter abmelden, aber das wäre sehr schade.
Viele erfolgreiche Projekte wünscht
Projektstart GmbH
Gerhard Wirnsberger
schreibe mir eine email:
Hinterlasse einen Kommentar