Ready und Done

Der zehnte und letzte Teil der Werkzeugkiste des Product Owners. Der Backlog des Ferientools ist priorisiert. Bleiben zwei Checklisten, eine an jedem Ende des Sprints.

Definition of Ready

Die Definition of Ready ist eine Checkliste mit Kriterien, die ein Backlog-Eintrag erfüllen muss, bevor er vom Product Backlog in einen Sprint Backlog wechseln darf.

Sie stellt sicher, dass die Informationen für den nächsten Schritt da sind, damit das Team nicht mit Einträgen anfängt, die zu ungenau beschrieben sind. Das verursacht Mehrarbeit und Mehrkosten. Die Definition of Ready ist die Checkliste des Teams für die Qualität eines Backlog-Eintrags. Ihr Gegenstück, die Definition of Done, ist die Checkliste für die Qualität des Produktinkrements.

Verschiedene Arten von Einträgen brauchen verschiedene Definitionen. Ein Epic ist aus anderen Gründen bereit als eine Story.

Das Team schreibt die Definition of Ready am Anfang gemeinsam, für jede Art von Eintrag, und das ganze Team ist dafür verantwortlich, sie einzuhalten. Überprüf sie regelmässig, zum Beispiel in der Sprint-Retrospektive. In der Praxis sind die üblichen Gründe für eine Anpassung:

• die Rahmenbedingungen des Vorhabens ändern sich,
• die Backlog-Einträge sind nicht gut genug,
• die Ansprüche an die Qualität steigen.

Eine User Story ist bereit, wenn sie:

• die INVEST-Kriterien erfüllt,
• so geschrieben ist, dass ihre Leser sie verstehen,
• mit den Stakeholdern abgestimmt ist,
• in sich stimmig und widerspruchsfrei ist,
• klar mit ihrem Feature verknüpft ist,
• mindestens ein Akzeptanzkriterium hat,
• priorisiert ist,
• das Bedürfnis beschreibt, nicht eine technische Lösung,
• mit den Stories verknüpft ist, von denen sie abhängt, falls es solche gibt.

Ein Feature ist bereit, wenn es:

• auf hoher Ebene und für seine Leser geschrieben ist,
• mit den Stakeholdern abgestimmt ist,
• in sich und mit anderen Features stimmig ist,
• einem übergeordneten Geschäftsbedürfnis dient,
• mindestens ein Akzeptanzkriterium hat,
• nach Relevanz oder Risiko gewichtet und priorisiert ist,
• das Bedürfnis beschreibt, nicht eine technische Lösung,
• nachvollziehbar in Stories geschnitten ist,
• seine Abhängigkeiten zu anderen Features zeigt.

Eine Warnung: Eine Definition of Ready kann zum Wasserfall-Tor werden. Wenn das Team jede Story ablehnt, die nicht perfekt ist, schreibt der Product Owner wieder Spezifikationen, und wir sind zurück beim vierzigseitigen Dokument aus Teil zwei. Die Definition of Ready soll ein Gespräch anstossen, nicht ersetzen.

Definition of Done

Die Definition of Done ist die Liste der Kriterien, die ein Eintrag erfüllen muss, bevor er auf «Done» gesetzt werden kann.

Entscheidend ist, dass sie festhält, was das Scrum-Team und die Stakeholder gemeinsam unter «fertig» verstehen. Auch hier brauchen verschiedene Arten von Einträgen verschiedene Definitionen.

Das Scrum-Team schreibt sie gemeinsam und nimmt Vorgaben von ausserhalb des Teams auf, etwa Qualitätsstandards. Die Kriterien können sich mit der Zeit ändern, und die Definition of Done ändert sich mit, meistens in der Retrospektive. Häng sie dort auf, wo alle sie oft sehen. Eine Definition of Done auf Seite 14 eines Wikis definiert gar nichts.

Eine User Story ist fertig, wenn:

• der Code geschrieben ist und den Standards des Teams entspricht,
• die Akzeptanzkriterien erfüllt sind,
• alle Teilaufgaben erledigt sind,
• Unit- und Integrationstests durchlaufen,
• Bugs behoben oder zurück in den Backlog gestellt sind,
• der Product Owner das Inkrement geprüft und bestätigt hat, dass die Akzeptanzkriterien erfüllt sind.

Ein Feature ist fertig, wenn:

• die End-to-End-Integration abgeschlossen ist,
• die nicht-funktionalen Anforderungen erfüllt sind,
• die Regressionstests durchlaufen,
• das Nutzerbedürfnis erfüllt ist, für das es geschrieben wurde.

Weniger ist mehr. Fang mit vier oder fünf Kriterien an, die das Team wirklich jedes Mal prüft, und ergänze weitere, wenn du sie brauchst. Eine lange Liste, die niemand prüft, ist schlechter als eine kurze, die alle prüfen.

Was ich behalten würde

Das ist die Werkzeugkiste: Vision, Just-in-time-Spezifikation, Epics als Wetten, Personas und Journeys, Features und Story Maps, Stories und die drei Amigos, Schneiden, Backlog-Management und Priority Poker, Ready und Done. Zehn Werkzeuge, ein Ferientool, von einer Excel-Datei bis zu einer Abwesenheit, die im Teamkalender erscheint.

Wenn ich nur drei behalten dürfte:

1. Eine Vision, die Nein sagt. Sie erspart mehr Diskussionen als jedes andere Werkzeug und macht jede spätere Entscheidung günstiger.
2. Das Gespräch. Card, Conversation, Confirmation, mit allen drei Amigos im Raum. Die meisten Bugs beginnen als Missverständnis, über das niemand geredet hat.
3. Eine kurze Definition of Done. Vier oder fünf Zeilen, die das Team wirklich prüft. Dort hört Qualität auf, ein Versprechen zu sein.

Alles andere hilft. Für diese drei würde ich in einem Team kämpfen, das keines davon hat.