Nichts ist älter als die Dokumentation des letzten Sprints

In den letzten Blog-Beiträgen empfahl ich immer wieder, die Dokumentationstätigkeiten direkt in den Sprint zu ziehen und einen entsprechenden Task an die konkrete Story zu hängen. Durch diese inkrementelle Dokumentation schreiben wir Dokumente, die im Folge-Sprint oftmals schon wieder veraltet sind. Wie schafft man den Spagat, um wenig sinnlos zu dokumentieren, aber trotzdem noch im Thema zu sein?

Das inkrementelle Vorgehen in Scrum betrifft nicht nur die Software, sondern hat auch Effekte auf die Dokumentation. Feature-Epics werden idealerweise in handhabbare User Stories geschnitten. Ein unabhängiger User-Story-Split ist zwar wünschenswert, aber selten möglich, gerade wenn man mehrwertstiftende Software ausliefern möchte. Aus diesem Grund dokumentiert man in frühen Phasen des Epics Dinge, von denen man weiß, dass sie sich ohnehin im nächsten oder übernächsten Sprint ändern werden. Dokumentiert man sie nicht, läuft man Gefahr, wichtige Details zu vergessen oder die Produktdokumentation als  solche immer wieder zu verschieben, weil andere Dinge wichtiger erscheinen.

Auch wenn es manchmal schmerzhaft ist, Dokumentation für die Mülltonne zu schreiben, hat es trotzdem Vorteile. Ähnlich wie in der inkrementellen Softwareentwicklung kann eine inkrementelle Dokumentation frühzeitig an die Leserschaft ausgeliefert und gereviewed werden. Das Feedback kann dann in der nächsten Iteration berücksichtigt werden oder eventuell sogar schon konzeptionelle Missverständnisse innerhalb des Teams auflösen. Gute Produktdokumentation wird ohnehin nicht einmalig geschrieben, sondern stetig weiterentwickelt. Durch folgende Sprints entstehen neue Kapitel, aber alte werden auch aktualisiert.

Gerade wenn es absehbar ist, dass ein Epic vollendet wird, kann man sich den Flickenteppich an Dokumentation, der mitunter im Sprintalltag entstanden ist, ganzheitlich ansehen. Mit etwas Abstand kann man dann aus einem Guss die Dokumentation glattziehen, anhand der Informationen, die im Sprint notiert wurden. Ich empfehle daher weder ausschließlich im Sprint, noch danach zu dokumentieren, sondern ein gutes Mischverhältnis zu finden.

Obwohl frühzeitige Produkdokumentation meist für die Mülltonnen geschrieben wird, kann sie helfen, teaminterne Missverständnisse zu klären und Feedback von der Leserschaft einzuholen, um die Art und Weise der Dokumentation anzupassen und zu verbessern. Sie dient zusätzlich als Leitfaden für eine ganzheitlichere Dokumentation, wenn der betroffene Softwareteil eine gewisse Reife erreicht hat. Sinnlose Dokumentation ist etwas anderes!