Agiles Anforderungsdokument: ein praktischer Leitfaden

Das Problem mit traditionellen Anforderungsdokumenten

Ein Produktmanager verbringt zwei Wochen damit, ein detailliertes Anforderungsdokument zu verfassen. Es durchlauft drei Runden der Stakeholder-Prufung. Wenn das Entwicklungsteam den ersten Sprint startet, haben sich bereits zwei zentrale Annahmen geändert. Das Dokument bleibt unberührt in einem geteilten Ordner, wahrend das Team etwas anderes baut als das, was es beschreibt.

Dieses Szenario wiederholt sich in Organisationen überall. Traditionelle PRDs wurden zu 20-seitigen Spezifikationen, die versuchten, jedes Detail eines Produkts vorherzusagen, bevor eine einzige Zeile Code geschrieben wurde. Teams verbrachten Wochen damit, sie zu perfektionieren. Stakeholder unterzeichneten sie wie Vertrage. Dann traf die Realität ein, Anforderungen änderten sich und niemand aktualisierte das Dokument.

Agile Teams brauchen einen anderen Ansatz. Das Product Requirements Document hat immer noch eine Rolle, aber sein Zweck hat sich grundlegend verändert. Es ist keine Spezifikation mehr, der buchstabengetreu zu folgen ist. Es ist ein Werkzeug zum Aufbau eines gemeinsamen Verständnisses innerhalb eines funktionsubergreifenden Teams.

Was ein agiles PRD tatsächlich leistet

Ein Product Requirements Document im agilen Kontext erfüllt drei Funktionen. Erstens richtet es das Team auf das zu losende Problem und die erwarteten Ergebnisse aus. Zweitens erfasst es genügend Kontext, damit Designer und Entwickler ohne Mehrdeutigkeit mit der Arbeit beginnen können. Drittens bietet es einen Referenzpunkt, der sich gemeinsam mit dem Produkt weiterentwickelt.

Die Betonung liegt auf genügend. Ein agiles PRD vermeidet bewusst erschöpfende Details. Es vertraut darauf, dass das Team die richtigen Losungen durch Iteration und Feedback entdeckt, anstatt sie im Voraus vorzuschreiben.

Sechs Abschnitte, die jedes agile PRD braucht

Die effektivsten agilen PRDs sind kurz. Ein bis drei Seiten sind typisch. Sie teilen eine gemeinsame Struktur, die Richtung mit Flexibilität in Einklang bringt.

Ziele und Hintergrund

Beginnen Sie damit, warum diese Arbeit wichtig ist. Welches Geschäftsziel dient sie? Wie fügt sie sich in die Produktstrategie ein? Ein Product Owner, der dies nicht in zwei oder drei Sätzen formulieren kann, braucht wahrscheinlich mehr Discovery-Zeit, bevor er etwas anderes schreibt.

Annahmen und Einschränkungen

Jede Produktentscheidung beruht auf Annahmen. Sie explizit zu machen, verhindert spätere Missverständnisse. Beispielsweise konnte ein Team, das eine Aussendienst-Anwendung entwickelt, annehmen, dass Techniker die App auf Tablets mit intermittierender Konnektivität nutzen werden. Diese Annahme aufzuschreiben zwingt das Team, sie frühzeitig zu validieren und entsprechend zu gestalten. Wenn eine regulatorische Einschränkung oder eine Abhängigkeit von einem anderen Team besteht, erfassen Sie sie hier. Annahmen, die sich als falsch erweisen, werden zu wertvollen Lernmomenten statt zu Überraschungen.

User Stories

User Stories sind das Rückgrat eines agilen PRD. Sie beschreiben, was ein Benutzer erreichen muss und warum, ohne die Umsetzung vorzuschreiben. Eine gut geschriebene User Story folgt dem bekannten Format: Als [Benutzertyp] mochte ich [Fähigkeit], damit [Nutzen]. Das PRD gruppiert verwandte Stories zusammen und liefert genügend Kontext, damit das Team schätzen und planen kann.

Interaktionsdesign

Wireframes, Mockups oder sogar grobe Skizzen gehören in das PRD. Visuelle Referenzen reduzieren Mehrdeutigkeit weit effektiver als schriftliche Beschreibungen. Sie müssen nicht poliert sein. Ein Whiteboard-Foto oder ein schneller Wireframe gibt dem Entwicklungsteam ein gemeinsames mentales Modell davon, wie die Funktion aussehen und sich anfühlen soll.

Was wir nicht tun

Dies ist der am meisten unterschätzte Abschnitt in jedem PRD. Das explizite Auflisten von Funktionen und Anforderungen, die ausserhalb des Umfangs liegen, verhindert Scope Creep. Es spart auch Zeit in zukünftigen Diskussionen. Wenn jemand eine Funktion vorschlagt, die bereits erwogen und ausgeschlossen wurde, kann das Team auf die hier dokumentierte Begründung verweisen, anstatt die Debatte neu zu eröffnen.

Offene Fragen

Ehrliche PRDs erkennen an, was das Team noch nicht weiss. Offene Fragen aufzulisten signalisiert, dass die Discovery noch lauft, und lädt Beitrage des gesamten Teams ein. Ein PRD, das vorgibt, alle Antworten zu haben, ist ein PRD, das Zusammenarbeit entmutigt.

Drei Anti-Patterns, die Sie vermeiden sollten

Selbst Teams, die agile PRDs einfuhren, tappen in häufige Fallen.

Das Freigabe-Ritual. Wenn ein PRD die formelle Genehmigung mehrerer Stakeholder erfordert, bevor die Arbeit beginnen kann, wird es zum Engpass. Agile PRDs sollten kollaborativ geprüft werden, nicht sequenziell genehmigt.

Das lebende tote Dokument. Ein PRD, das nach dem ersten Sprint nie aktualisiert wird, ist schlimmer als gar kein Dokument. Es erzeugt ein falsches Gefühl der Ausrichtung, wahrend das Produkt von dem abweicht, was ursprünglich beschrieben wurde. Wenn das Team aufhört, darauf Bezug zu nehmen, hat das Dokument versagt.

Die verkleidete Spezifikation. Manche Teams benennen ihre 30-seitige Spezifikation in „agiles PRD“ um und andern sonst nichts. Die Lange ist ein Signal. Wenn ein PRD drei Seiten überschreitet, versucht es wahrscheinlich vorherzusagen statt zu leiten.

Wer schreibt es und wann

Der Product Owner treibt typischerweise die PRD-Erstellung voran, aber das Dokument sollte nie eine Einzelleistung sein. Die besten PRDs entstehen aus Gesprächen zwischen Produktmanagement, Design und Entwicklung. Der Product Owner schreibt den ersten Entwurf. Das Team hinterfragt Annahmen, fügt technische Überlegungen hinzu und verfeinert User Stories gemeinsam.

Das Timing ist ebenfalls wichtig. Ein PRD, das zu früh geschrieben wird, fehlt es an Erkenntnissen aus der Discovery. Zu spät geschrieben, kann es die Planung nicht mehr beeinflussen. Der richtige Zeitpunkt liegt nach der initialen Discovery und vor der Sprint-Planung für das erste Inkrement.

PRDs und User Stories arbeiten zusammen

Ein häufiges Missverständnis ist, dass agile Teams zwischen PRDs und User Stories wählen müssen. Sie dienen unterschiedlichen Zwecken. Das PRD liefert den strategischen Kontext: das Problem, die Ziele, die Grenzen. User Stories liefern taktische Details: spezifische Fähigkeiten, die gebaut und getestet werden sollen. Ein PRD ohne User Stories mangelt es an umsetzbaren Details. User Stories ohne PRD fehlt die strategische Grundlage. Die stärksten Teams nutzen beides, wobei das PRD als verbindendes Gewebe dient, das einzelne Stories zu einer kohärenten Produktvision verknüpft.

Die beste Anforderungsdokumentation ist ein Nebenprodukt guter Zusammenarbeit, kein Ersatz dafür. Wenn ein Team das Problem, das es lost, wirklich versteht, schreibt sich das Dokument fast von selbst.

Weiterführend