Erste Schritte mit einer Definition of Done

Das erste Thema in meiner Arbeit mit einem neuen Team ist deren definition of done. Mit agilem Vorgehen unerfahrene Teams tun sich hier zu Beginn oft schwer. Wozu braucht man eine DoD, wie startet man, was ist zu beachten?

DoD, die ersten Schritte: Was muss getan werden

Am Ende eines Sprints steht die Releasefähigkeit. Alles, woran das Team gearbeitet hat, womit es fertig ist, muss release-bar sein. Die Begründung dafür ist simpel: Wenn wir nicht regelmäßig bis zur Releasefähigkeit arbeiten, wird die für ein Release nötige Arbeit mehr, komplizierter und schwerer nachvollziehbar. Sie wird fehleranfälliger und langwieriger.

Was aber ist »fertig«? Diese Frage beantwortet das Development-Team mit einer definition of done. Eine DoD ist eine Checkliste, die man gegen jedes Ticket, jede Story halten und prüfen kann, ob dieses Ticket erledigt ist, oder nicht.

Hier ein Beispiel:

• All assets are finalized and available as agreed
• Code style is met
• Implementation tests out in Unity Editor
• No errors related to implemented feature
• Report error for other features
• If possible, feature is reviewed by assigned reviewer (see Task Definition in DoR)
• If feature is UI related it must be viewed in device simulator
• New and previously created Unit tests passed
• Committed & pushed to current branch with appropriate comment(s)
• Commits are part of a build
• Build working on Unity Cloud Build
• Create a release notes for changes in the build
• Feature is reviewed by assigned reviewer on a device
• Create enduser documentation for features in Confluence

Diese DoD ist vier Sprints alt, also noch frisch. Man bemerkt das an den sehr konkreten, kleinteiligen Spiegelstrichen. Dennoch kann das Team damit arbeiten jede Aufgabe prüfen: »done or not done.«

Der Software Development Lifecycle und die DoD

Hinter der DoD scheint der Software Development Lifecycle durch, der die zur Lieferung potenziell nützlicher Software notwendigen Tätigkeitsfelder zeigt — in Abgrenzung zur Definition of ready, bei der es darum geht, ob ein Backlog-Item umsetzbar ist.

Die Definition of Ready ist für die Aufgaben nützlich, die auf Verständnis und Lösungsoptionen abzielen. In der Umsetzung hilft dann die Definition of Done.

Man nutzt den SDLC im Zusammenhang mit der DoD zur Prüfung der Zusammenstellung des Development-Teams. Tauchen in der DoD Aufgaben auf, für die dem Team die passende Expertise fehlt, sollte dem nachgegangen werden. Wird das nicht geprüft, könnte das Team nicht in der Lage zu sein, seine Aufgabe zu erfüllen. Es wäre immer wieder von anderen Teams abhängig, und könnte somit nicht selbst-organisiert arbeiten.

#NoEstimates

Storypoints und T-Shirt-Größen, oder Schätzungen der benötigten Zeit sind hart diskutierte Themen. Doch ein eingespieltes Team wird allein anhand der DoD eine sehr gute Schätzung dessen angeben können, was es in einem Sprint liefern kann. Ist es aber nicht notwendig, zu wissen, ob Aufgabe A einen halben Tage mehr braucht als Aufgabe B, oder ob Aufgabe C in dreieinviertel Stunden machbar ist? Wozu dient diese Angebe dem Development-Team? Wenn Sie darauf, natürlich mit dem Team, keine gute Antwort finden, warum sollten Sie das Team dann mit der Ermittlung dieser Werte belasten? Weil Scrum, und auch die DoD, immer auf das in einem Sprint Erreichbare schaut.

Ob eine Aufgabe innerhalb eines Sprints länger dauert als eine andere, spielt keine Rolle. Wenn das Team als Teil des Refinements zeitliche Schätzungen abgeben soll, damit Sie als Product-Owern*in das Backlog anhand dieser Angaben sortieren können, zum Beispiel um möglichst viele Backlog-Items umsetzen zu können, verringern Sie im Zweifel den lieferbaren Wert. Selbst wenn das nicht zuträfe, es bleibt dabei: Eine Schätzung als explizit angegebener Zeit schafft keine Mehrwert gegenüber einer implizite Abwägung des Teams anhand der DoD.

Zumal über das Planning hinaus die explizite zeitliche Schätze keine relevante Kenngröße mehr ist. Für Abweichungen gibt es immer Gründe — im Zweifel solche, die nicht im Team selbst liegen.

Definition of Done im Überblick

Die definition of done hilft dem Team, den vollen Umfang der nötigen Arbeit zu verstehen, die zur Erfüllung eines Backlogs-Items getan werden muss.

Das ist wichtig für das Team, um einschätzen zu können, wie viele beziehungsweise welche Backlog-Items es für einen Sprint auswählen kann.

Wenn ein Team zum ersten Mal zusammenkommt, um an ihrer DoD zu arbeiten, werden verschiedene Aspekte und Details zur Sprache kommen. Das Team hat die Wahl, sich zu Beginn auf wenige Aspekte zu konzentrieren, in der Regel auf diejenigen, die am meisten mit der Produktqualität zu tun haben. Mit der Zeit wird ein Team an ihrer DoD arbeiten und immer mehr Aspekte einbeziehen. Auf diese Weise hilft ein DoD dem Team, wertvollere Software zu entwickeln. Bestimmte DoD-Angaben, wie im obigen Beispiel »Code style is met«, helfen bei der Automatisierung, was wiederum Zeit freiräumt.

Und wenn wir keine DoD haben?

Die definition of done hilft, den vollen Umfang der nötigen Arbeit zu verstehen, die zur Erfüllung eines Backlogs-Items getan werden muss.

Wenn Sie keine DoD haben, müssen Sie immer wieder, für jede Aufgabe neu überlegen und formulieren, was zu tun ist, um dieses Stück Arbeit bis zur Releasefähigkeit zu entwicklen. Das ist anstrengend und fehlerfällig. Leicht geht vergessen, dass ja noch Integrationstests machen, Dokumentation zu schreiben, Assets komprimiert, Konfigurationsangaben zu ändern sind. Eine Stunde vor dem geplanten Release ist es dafür zu spät.

Hat man nicht diese gesamte Arbeit auf dem Schirm, kann das Team auch keine belastbare Aussage über den Umfang der im Sprint leistbaren Arbeit treffen. Sprintziele werden nicht erreicht oder es bleibt keine Zeit für Bugfixing, am Ende kann das Team nicht liefern, was es liefern wollte.

Ihr Sascha A. Carlin

Als Agile Coach verhelfe ich Führungskräften in der Softwareentwicklung zu mehr Wirksamkeit.

Kontaktaufnahme jederzeit via E-Mail oder Telefon +49 30 40782375.