Wann ist der richtige Zeitpunkt für Dokumentation?

Produktdokumentation ist wichtig. Das habe ich jetzt verstanden, aber während des Sprints ist oftmals nicht viel Zeit. Das Team ist ausgelastet mit der Spezifizierung und Implementierung der Anforderung. Dann muss auch noch getestet werden und das Review bereitet sich auch nicht von alleine vor. Wann bleibt also noch Zeit für Dokumentation? Mache ich sie vor dem Sprint, danach oder doch währenddessen?

Dokumentation vor dem Sprint

Im Rahmen einer Projektdokumentation entstehen viele wichtige Dokumente vor einem Sprint. Während User Stories die Anforderungen kurz und prägnant beschreiben, zeigen erste Skizzen oder Ablaufdiagramme wie die Software funktionieren könnte, wenn sie dann mal implementiert wurde. Und genau das ist der Punkt. Nutzt man die Projektdokumentation als Grundlage für die Produktdokumentation, läuft man Gefahr zum Märchenerzähler zu werden. Denn nichts ist älter als die Anforderungen von gestern, oder wie das Sprichwort geht. Während der Implementierung kann sich noch so viel ändern. Gerade, wenn erste Tests an der fertigen Software durchgeführt wurden und man feststellte, dass es sich doch anders anfühlt, als zuvor durchdacht. Es liegt also nahe spät, nach der Implementierung und nach ersten Tests zu dokumentieren.

Dokumentation nach dem Sprint

Gerade wenn der Sprint von der Programmierung neuer Features, System- und Nutzertests geprägt war, bleibt kaum Platz für eine umfangreiche Dokumentation. Warum also die Dokumentation nicht auf den folgenden Sprint verschieben? In der Tat wird das von vielen so praktiziert und empfohlen.

Hier lohnt sich ein Blick auf die Definition of Done und wie sie selbst defininiert ist:

Das Team einigt sich bei der Definition of Done (DoD) auf ein gemeinsames Verständnis von Kriterien, die erfüllt sein müssen, um eine Anforderung oder User Story erfolgreich beenden zu können. Die Transparenz über die Kriterien sorgt u.a. dafür, dass man nichts Wichtiges vergisst.

Dokumentation gehört zur Software dazu, nicht selten steht sie deshalb auf der Definition of done mit dabei. Wird sie nicht erfüllt, ist das Inkrement nicht potenziell auslieferbar. Das ist wichtig und sinnvoll, denn der Folgesprint steht mitunter unter einem ganz andern Sprintziel und man muss wieder neu Themen vom vorherigen Sprint aufrollen. Vielleicht gehen Themen vergessen, auf jeden Fall geht an dieser Stelle Produktivität verloren.

Dokumentation während des Sprints

Wenn vor und nach dem Sprint keine geeigneten Zeitpunkte für die Produktdokumentation sind, liegt es am Team, während des Sprints zu dokumentieren. Aber wie schafft man das? User Stories sind i.d.R. nicht nur kurz und knapp formuliert, sondern auch klein geschnitten. Das bedeutet, dass pro User Story im optimalen Fall nicht viel neue Fachlichkeit dazu kommt. Wenn man es also schafft, kontinuierlich zu jeder Story zu dokumentieren, ist man im Thema drin und muss nicht nochmal neu überlegen. Während die Entwickler programmieren können Business Analysten oder technische Redakteure schon die Fachlichkeit niederschreiben und z.B. die Wiki-Seiten eingliedern. Ist die Umsetzung final, müssen dann nur noch Kleinigkeiten angepasst werden. Es ist sinnvoll im Planning zu jeder Story einen Doku-Task aufzunehmen, um diese Kontinuierlichkeit sicherzustellen.

Mit Scrum schafft man Stück für Stück Kundenwert, also sollte man auch Stück für Stück an der Produktdokumentation arbeiten, während des Sprints!

Referenzen

• Projektmagazin.de
• Agile Dokumentation – Johannes Dreikorn
• Definition of Done