Agile Entwicklung erfordert ein tief gehend Verständnis jeder Anforderung zum Zeitpunkt der Umsetzung. Product-Owner und Business-Analysten sind verantwortlich für den Inhalt des Product-Backlog. Und sie bereiten sich auf die Fragen der Entwickler und Tester vor. Ihr wichtige Aufgabe ist es, das cross-funktionale Team in die Lage zu versetzen, eigenverantwortlich und effizient Software zu “fertigen”.

08 Dokumente für das Backlog

Hilfreich

Die Methode CARDS+ unterstützt uns bei diesem Vorhaben. Wir zerlegen die Anforderung in kleine Teile, die wir beherrschen. Wir wollen uns um genau einen fachlichen Aspekt der Anforderung kümmern.

ktip Cases sind keine Vorgabe für die Struktur der Software.

Mit einem Case erklären wir zuerst immer die Ausgangslage. Das kann ein ganz konkreter Anwendungsfall sein. Die Ausgangslage sollte immer “lösungsoffen” formuliert sein. Es hat sich gezeigt, dass es sehr sinnvoll ist, in einem Case auch wichtige Testfälle zu beschreiben. Sie fördern das Verständnis. Die Lösung selbst wird im Team entwickelt. Ob das Refinement-Meeting reicht oder ein Workshop notwendig ist, hängt vom Case ab.

Der Inhalt für den Baustein Case wird nach dem INVEST-Prinzip erstellt:

  • Independent (unabhängig)
  • Negotiable (verhandelbar)
  • Valueable (wertorientiert)
  • Estimatable (schätzbar)
  • Small (klein)
  • Testable (testbar)

Diese Zerlegung eines Epic in Cases ist sehr wichtig, weil sie uns zeigt, wo wir aus der fachlichen Perspektive Unterschiede in den Anwendungsfällen vermuten. So eine Zerlegung ist nicht nur bei der Implementierung hilfreich, sondern mit Sicherheit auch später, wenn wir Fehler suchen oder die Funktionalität des Systems erweitern.

Vollständig

Die Summe aller Cases in einem Epic repräsentiert eine konkrete abgeschlossene Aufgabenstellung, die sich aus einem Bedarf der Nutzer oder einer anderen Anforderung ergeben hat. Das heißt aber keineswegs, dass ein Epic nicht verändert werden darf. Im Gegenteil: Im Sprint gibt es oft zusätzliche Erkenntnisse. Diese Erkenntnisse führen dazu, dass wir während der Programmierung oder beim Testen neue Cases entdecken. Wir beschreiben sie sofort im Wiki als neuen Case, wenn sich das Sprint-Ziel dadurch nicht ändert. Oder es kann ein Feedback an den Product-Owner sein.

Praktisch

Durch die Zuordnung zu einem Topic kennen wir den Kontext des Epic. Im Epic selbst finden wir einen groben Überblick der konkreten Aufgabenstellung und eine Abgrenzung zu anderen Epics.

Die weitere Analyse bewegt sich parallel auf zwei Ebenen:

  1. Anwendungsfälle beschreiben wir mit Cases.
  2. Die Benutzeroberfläche definieren wir mit Layouts.

Wurden alle Cases ausreichend beschrieben und alle Layouts definiert, dann ist die Produktdokumentation fertig und bereit für die Verwendung im Product-Backlog. Fertig beinhaltet in diesem Zusammenhang auch die Durchführung eines Reviews von mindestens einem Analysten oder dem Product-Owner.

Das Epic wird nun im Rahmen eines Refinement-Meetings den Entwicklern vorgestellt. Zur Vorbereitung des Meetings erstellt der Product-Owner User-Stories für das Product-Backlog. Die Faustregel ist eine User-Story pro Case oder Layout. Der Titel der User-Story entspricht dem Titel der Seite im Wiki. Dadurch wiederholt sich die Struktur des Wiki auch im Product-Backlog. Der Text der User-Story besteht aus der Verknüpfung zur Seite im Wiki.

Mit den Akzeptanzkriterien steuert der Product-Owner den Umfang der Story im Product-Backlog. Er kann sich mit einer Story auf die Umsetzung der reinen Fachlogik konzentrieren. Mit einer weiteren Story zum gleichen Case kann er dann beispielsweise die Robustheit der Implementierung verbessern. Dieses Vorgehen lässt den Entwicklern ausreichend Spielraum, um jede Art von nicht-funktionaler Anforderung im Product-Backlog zu verankern.

Nachhaltig

Am Ende des Refinement-Meeting sind Stories im Product-Backlog nun bereit zur Umsetzung. Der Product-Owner hat die Beschreibung im Wiki verbessert oder wichtige Annahmen als Akzeptanzkriterien in der Story erfasst. Die Entwickler hatten Zeit, Fragen zu stellen. Analysten werden ihre Antworten zur Verbesserung der Qualität der Beschreibung im Wiki nutzen. Bis zum Planning-Meeting habe Entwickler und Tester die Chance, durch Kommentieren der Seiten im Wiki weiteres Feedback zu geben – ohne Refinement-Meeting, aber im selben Sinn.