Agile Dokumentation in Scrum-Projekten

Das Agile Manifest als Grundlage auch von Scrum-Projekten benennt es doch glasklar: „Funktionierende Software ist wichtiger als umfassende Dokumentation.“ Warum dann über Dokumentation noch groß reden? Weil das Agile Manifest Kommunikation im Projekt besonders hervorhebt.

Zwar bevorzugen agile Ansätze den direkten persönlichen Austausch. Dennoch soll jede Zeile Code im Team aus Vertretern der Stakeholder, im Scrum-Team also durch den Product-Owner, und den Entwicklern kommunikativ reflektiert werden.

Doch eine solche Art der Qualitätssicherung, die Kommunikation letztendlich bewirken soll, kann nur durch Dokumentation intersubjektiv nachvollzogen werden. Und Benutzerdokumentation als Bestandteil der User-Experience (UX) ist damit einerseits noch nicht definiert und andererseits im Agilen Manifest gar nicht angesprochen.

Für die schriftlich festgehaltene Kommunikation im Projekt definiert Scrum das sogenannte Product-Backlog als im Prinzip beliebig große Anzahl von Anforderungen an das zu entwickelnde Produkt. Für die Rolle von Dokumentation im Scrum-Framework müssen wir uns also insbesondere die Funktion des Product-Backlogs näher anschauen.

Scrum definiert als Framework drei Rollen, drei Artefakte und fünf Events.

Scrum, Backlogs und Dokumentation

Aus dem Agilen Manifest und dem Framework Scrum lassen sich nun mit Blick auf die Dokumentation sehr wohl kritische Fragen ableiten:

Scrum legt für das Sprint-Backlog keine Details fest. Zwar ist das Sprint-Backlog als weiteres Artefakt genannt, tatsächlich ist es nur eine Widerspiegelung von Teilen des Product-Backlogs. Änderungen an den Backlog-Einträgen während eines Sprints werden als Änderungen in das Product-Backlog eingepflegt und werden als „Product-Backlog-Refinement“ bezeichnet. Ein Sprint-Backlog „überlebt“ einen Sprint nicht, um den „Single Source of Truth“ (eine einzige gültige Quelle) zu erhalten.

Keine eindeutige Spezifikation der Dokumentation …

Um es klar zu sagen: Scrum ist ein Rahmenwerk und spezifiziert weder die eigentliche Produktgestaltung noch die externe Dokumentation (Benutzerdokumentation). Die interne Dokumentation (Entwicklerdokumentation) besteht aus dem Product-Backlog, nur lässt der Scrum-Guide offen, wie das Backlog im Detail aussieht.

… auch nicht in Normen

Auch in der klassischen Softwareentwicklung gibt es kein allgemein akzeptiertes Rahmenwerk, das Dokumentation eindeutig spezifiziert. Es sind die Begriffe „Lastenheft“ (fachliche Orientierung) und „Pflichtenheft“ (technologische Orientierung) sowie „Benutzerdokumentation“, die im klassischen Entwicklungsumfeld als allgemein bekannt angesehen werden können. Zwar gibt es Normen, die die Begriffe Lasten- und Pflichtenheft aufgreifen:

Allen Normen gemeinsam ist, dass eine festgelegte Struktur und Sequenz für interne Dokumentation und deren Rolle als Input für eine Benutzerdokumentation nicht festgelegt werden. Insbesondere die Norm 26515 für agile Entwicklungen zeigt nun einen möglichen revolutionären Weg: „In order to minimize unnecessary work and duplication of effort, technical writers may be asked to produce or contribute to life cycle documentation. The user documentation may itself become the design specification for the product under development […].“

Die überwiegende Praxis zeigt, dass die klassische Idee der aufeinander abgestimmten Dokumente mit den jeweils unterschiedlichen Zielgruppen Stakeholder und Entwickler in einer Welt der permanenten Änderungen (Volatilität) und der zunehmenden Komplexität einfach nicht mehr effizient umsetzbar ist. So akzeptiert selbst das aktuelle V-Modell als bekanntestes öffentlich zugängliches Framework für Software-Entwicklungen zumindest in der Erweiterung „V-Modell XT Bund“ auch agile Ansätze.

Für Scrum findet man auf der Website www.scrum.org mit dem kostenlosen Scrum-Guide „die Bibel“ von Scrum.

Product-Backlog ist Dreh- und Angelpunkt

Der Scrum-Guide beschreibt das Product-Backlog als Dreh- und Angelpunkt jeglicher Entwicklung, vermeidet aber eine weitergehende Spezifizierung: „Im Product-Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. Ein Product-Backlog-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert. Product-Backlog-Einträge enthalten oft Testbeschreibungen, die ihre Vollständigkeit nachweisen, wenn sie fertig [,Done‘] sind.“

Definition of Done: Was bedeutet „FERTIG“?

Als einzig weiteren Aspekt verlangt der Scrum-Guide, sogenannte Definition-of-Done-Kriterien (DoD) festzulegen.

Ein Beispiel für Definition-of-Done-Kriterien:

Kriterien müssen festgelegt und dokumentiert werden.

Eine DoD-Liste muss von einem Unternehmen und/oder dem Entwicklungsteam als Qualitätsrahmen verabschiedet werden. Es sei noch einmal gesagt: Die Festlegung von DoD-Regeln ist Projektaufgabe und kein Bestandteil des Scrum-Guides.

Die weiteren Ausführungen zu diesem spannenden Thema finden Sie in unserem Praxismodul „Technische Dokumentation“.