Max von der Nahmer

Die “Definition of Done” (dt. Fertigstellungskriterien) ist eine Vereinbarung zwischen dem Entwicklungsteam und dem Product Owner, welche besagt, welche Maßnahmen während des Sprints ergriffen werden, um eine Story zu finalisieren. Gemeinsam strebt das Team danach, sich in Richtung einer perfekten „Definition of Done“ zu verbessern. Die „Definition of Done“ ist erfüllt, wenn die Story ein an den Kunden auslieferbares Produkt / Feature („Potentially Shippable“) beinhaltet.

Die Bedeutung von „done“ explizit zu definieren reduziert Verschiebungen und die Wahrscheinlichkeit unfertiger Arbeit. Außerdem kann bei Einhaltung der Definition of Done der Fortschritt unmissverständlich bewertet werden („done“ oder „not done“), wodurch die Transparenz erhöht wird.

Perfekte Fertigstellungskriterien beinhalten alles, was aus Sicht des Entwicklungsteam von Nöten ist, um dem Kunden ein fertiges Produkt liefern zu können. Dies zu erreichen sollte für eine, aus einem Team bestehende, Produktgruppe relativ einfach sein. Wenn das Team nicht in der Lage ist, die perfekte „Definition of Done“ zu erzielen, wird eine Teilmenge der perfekten Zusammenstellung als „done“ definiert. Das Ziel des Teams ist es, sich so zu verbessern, dass die „Definition of Done“ eines Tages perfekt ist und jeder Sprint (oder mehr) ein auslieferbares Produkt beinhaltet.

Was beinhaltet die Definition of Done?

Die „Definition of Done“ ist eine abgestimmte Liste mit Kriterien, die jedes Feature / Story des Product Backlog erfüllen muss. Um dieses Vollständigkeitslevel zu erreichen muss das Team eine Liste an Aufgaben ausführen. Wenn alle Aufgaben absolviert wurden, ist das Feature vollständig. Die „Definition of Done“ darf nicht mit den Akzeptanzkriterien verwechselt werden. Diese stellen spezifische Bedingungen jedes einzelnen Objekts dar, die erfüllt werden müssen. Die „Definition of Done“ dagegen gilt gleichermaßen für alle Bestandteile des Product Backlog.

Vorteile

  • Die „Definition of Done“ stellt eine Checkliste zur Verfügung, die auf nützliche Weise die Maßnahmen vor der tatsächlichen Anwendung leitet: Diskussion, Bewertung, Design.
  • Die „Definition of Done“ limitiert die Kosten einer Überarbeitung, sobald ein Bestandteil als „done“ akzeptiert wurde.
  • Eine gemeinsame Verteinbarung zwischen dem Entwicklungsteam sowie dem Kunden oder Product Owner zu habenm beschränkt das Risiko von Missverständnissen und Konflikten.

Die Schlüsselfrage ist: „Welche Aktivitäten sind derzeit nötig um unser Produkt zu liefern?“ Liefern bedeutet „dem Endkunden ein Produkt zuzusenden“ und nicht „ein Produkt aus dem Entwicklungszentrum zu entlassen.“

Typen

  • „Definition of Done“ für ein Feature (Objekt der Story oder des Backlogs)
  • „Definition of Done“ für einen Sprint (Sammlung an Features, die innerhalb eines Sprints entwickelt werden)
  • „Definition of Done“ für eine Freigabe (Status der Lieferbarkeit an den Kunden)

Die Schlüsselfrage ist: „Welche Maßnahmen einer Definition of Done können pro Sprint umgesetzt werden?“ Diese Kriterien sind die ursprüngliche „Definition of Done.“ Eine „Definition of Done“ ist schwach, wenn sie am Ende des Sprint nur eine kleine Teilmenge beinhaltet und stark, wenn diese nahezu dem Status „Potentially Shippable“ entspricht.

Das Entwicklungteam wählt gemeinsam alle Maßnahmen einer Definition of Done aus, die von den Teams als realistisch eingeschätzt werden, während dem Sprint erfüllt zu werden. Das ist die ursprüngliche „Definition of Done“. Teams, die mehr erreichen können und wollen, können ihre „Definition of Done“ innerhalb ihres Teams erweitern.

Zusammenfassung

  • Eine „Definition of Done“ ist orthogonal zu den Akzeptanzkriterien der Nutzer im Sinne der funktionalen Akzeptanz.
  • Sie ist eine umfassende Checkliste der notwendigen, wertsteigernden Maßnahmen, die die Qualität aber nicht die Funktionalität der Maßnahme gewährleistet.
  • Basis ist eine realistische Einschätzung des Team, welche Maßnahmen Sie innerhalb eines Feature / Sprint vollziehen können und wollen.

Beispiel

Phase Kriterium
Aufwandsschätzung
Refinement
  • Die Asana-Sub-Tasks wurden abgehakt.
  • Die offenen Confluence-Fragen wurden beantwortet.
Entwicklertests
  • Die Builds laufen ohne Fehler.
  • Unit Tests wurden geschrieben und erzeugen keine Fehler.
  • Ein grundlegener Acceptance Test der User Stories wurde durchgeführt.
  • Der Code-Sniffer zeigt keine Fehler.
  • Funktionen und Variablen wurden kommentiert.
Peer Review
  • Code Review wurde durch einen anderen Entwickler durchgeführt.
  • HTML wurde erfolgreich validiert.
Abnahme
  • Deployment auf dem Dev-Server.
  • Abnahme durch den Feature / Product Owner.
  • Device Check durch den Feature / Product Owner.
  • Die Definition of Done wurde vollständig abgehakt.

Hintergrundwissen

scrumalliance.org Verifying that your team’s DoD meets these criteria will ensure that you are delivering features that are truly done, not only functionality but quality
less.worksFormally defining the meaning of ‘done’ reduces variability and the likelihood of undone work and measuring progress unambiguously (‘done’ or ‘not done’) increases transparency.

Videos

Wie hat Ihnen diese Seite gefallen?

Kontakt & Rückruf

Max von der Nahmer

Hinweise zur Verarbeitung Ihrer Daten finden Sie in unserer Datenschutzerklärung. Sie können der Verarbeitung jederzeit widersprechen.