Boost your Backlog – Teil 2

10 Praxistipps für Product Owner und solche, die es werden wollen 

6. Boost: Liefern Sie pro Story eine testbare Spezifikation, die dem Team hilft!

Hauptbotschaft von Boost 1 war: Eine Story ist etwas anderes als ein Requirement, und sie enthält nicht alle Details, die das Team zur Erledigung der Arbeit im Sprint benötigt. Wie aber kommt das Team denn nun an diese Details?

Ron Jeffries hat schon 2001(!) mit seinem CCC-Prinzip [13] darauf hingewiesen, dass Storys etwas Soziales anhaftet: Sie sollen zur “Communication” anregen – neben “Card” (= eine Story ist ein Planungsartefakt) und “Confirmation” (= eine Story braucht testbare Akzeptanzkriterien) sein drittes “C”. Ganz im Geiste des agilen Manifests soll sich das Team also während des Sprints mit dem Product Owner, den Kunden, anderen Teams, mit sich selbst – mit wem auch immer es nötig ist! – austauschen und sich so direkt die benötigten Detailinformationen holen, anstatt sich Tickets zuzuschieben oder umfangreiche Dokumente zu durchwühlen. Dagegen ist nichts zu sagen – aber in manchen Situationen hilft ein anderer Weg dem Team sogar mehr.

Angenommen, eine Story verlangt, dass je nach Nutzer-Rollen und -Rechten ein Ergebnis unterschiedlich ausfallen soll. Warum dieser Story – diesem Arbeitspaket und “Container”! – nicht eine Entscheidungstabelle mitgeben, die kompakt, verständlich und gut testbar spezifiziert, welche Rollen-Rechte-Kombinationen zu welchem Ergebnis führen sollen?

Genau hier ist also die Stelle, wo sich der Werkzeugkasten des “klassischen” RE für agile Teams als nützlich erweisen kann: Wenn sich herausstellt, dass ein Stück dokumentierte Spezifikation (z.B. eine UI-Skizze, ein Prozessdiagramm, eine Entscheidungstabelle, ein Klassenmodell, …) dem Team dabei hilft, den Auftrag schneller und besser zu verstehen und dadurch im Sprint einen besseren Job zu machen – warum dann nicht dieses Artefakt zur Story hinzufügen? Das ist pure Agilität: ausprobieren, dazulernen, verbessern – was immer dem Team hilft, ist erlaubt.

Abbildung 3: Reaktion eines Scrum Masters nach Anwendung des 6. Boosts

Eine Frage, die an diesem Punkt übrigens unweigerlich gestellt wird, lautet: Und wer erstellt diese Artefakte? Heißt das etwa, dass jeder Product Owner ein ausgebildeter Requirements Engineer oder Business Analyst sein muss? Die Antwort heißt “nein” (gleichwohl es natürlich kein Schaden wäre): Die Artefakte werden von demjenigen erstellt, der es kann – dem PO selbst, oder jemandem aus dem Team, z.B. ein/e ehemalige/r RE-Experte/Expertin, oder von beiden zusammen im Pairing.

Bei Interesse: Hierfür haben wir ein leichtgewichtiges Hilfsmittel entwickelt, die sogenannte „Helpful Artifact Map“ (HAM), auf der PO und Team diejenigen Dokumenttypen (“Artefakte”) versammeln, die in verschiedenen Story-Situationen geholfen haben. Als Kirsche auf dem Kuchen versammelt dieses Poster nicht nur gesammelte Teamerfahrung, sondern schlägt pro Artefakt auch gleich noch geeignete Testentwurfsmethoden vor, wodurch Testbarkeit und Testaufwandsschätzung verbessert werden können. Details dazu finden Sie in [1].

Abbildung 4: Aufbau einer “Helpful Artifact Map”

7. Boost: Dokumentieren Sie nur, was einen Wert hat! Und ja, das können sogar Modelle sein!

Das zweite Wertepaar im agilen Manifest besagt nicht, dass “nichts mehr dokumentiert werden soll” – leider ein weiteres anzutreffendes Missverständnis. Es besagt vielmehr, dass keine Dokumentation nur um des Dokumentierens willen erstellt wird, denn das Ergebnis endet zu oft als staubbedeckte “Schrankware”. Agiles Dokumentieren heißt, nur zu dokumentieren, was für irgendjemanden einen Wert und Nutzen hat!

Wie aber entsteht dieser Wert? Zwei Möglichkeiten:

• Entweder, ein Dokument muss zu einer Story erstellt werden (weil vertraglich, prozessual oder regulatorisch gefordert) – dann sollte das aber ohnehin in der „Definition of Done“ festgehalten sein.
• Oder das Dokument hilft dem Team – d.h. das Team hat entschieden, dass dem Dokumentationsaufwand ein erkennbarer Nutzen für Entwicklung und Test des fraglichen Backlog Items gegenübersteht.

Für diese Art Nutzen haben wir bereits zwei Beispiele gesehen: die Use-Case-Modellierung samt anschließender Prozessspezifikation in Boost 2 und die “Helpful(!) Artifact Map” in Boost 6. Zeit für ein Geständnis: Ihnen wurden in diesem Blogbeitrag also bereits mehrere klassische RE-/Modellierungstechniken untergejubelt, obwohl wir hier über agile Teams reden. Tat nicht weh, oder? Modellierung hat es seit dem Aufkommen agiler Frameworks besonders schwer gehabt, weil Modelle von vielen agilen Teams komplett über Bord geworfen wurden, wahrgenommen ausschließlich als „Ballast“, weil UML, BPMN & Co. ja “nur Dokumentation sind” (was nicht stimmt) und viele Modellierungswerkzeuge zugegeben nicht gerade durch einfache Benutzbarkeit bestechen.

Tatsächlich aber können Modelle – an der richtigen Stelle und wohldosiert – jedem Product Owner und jedem agilen Team nützlich sein. Denken Sie beispielsweise an Customer Journeys! Ein ausführliches Praxisbeispiel zu dieser These finden Sie in [14], deshalb hier nur noch zwei abschließende Tipps:

• “Wohldosiertes” Modellieren heißt auch, nicht zwingend alle Modellelemente einer Notation zu verwenden. Denken Sie an das Use-Case-Beispiel aus Boost 2: Der Nutzen wurde erreicht, ohne „extend“- oder „include“-Beziehungen oder andere fortgeschrittene Konstrukte zu gebrauchen. Unverständliche Modelle entfalten keinen Nutzen (krass misslungene Beispiele dafür finden Sie in [15]), drum bitte beim Modellieren immer an Ziel und Zielgruppe denken.
• Und was in agilen Teams richtig rockt: Modellierung mit Post-Its. Gemeinsam im Team einen Prozess beschreiben, ohne dass man Prozessschritte durchstreichen oder Pfeile neu und quer übers Flipchart ziehen muss – einfach Post-Its als Knoten ans Whiteboard hängen und bei Bedarf umarrangieren – und am Ende erstmal ein Fotoprotokoll ablegen und gut ist! Macht außerdem Spaß.

8. Boost: Das Schneiden großer Storys

Über das Schätzen von User Storys – ob mittels Story Points, T-Shirt-Größen, “Tieren, die einem Angst einflößen” (kein Witz!) oder “idealen Tagen” – könnte man auch heute noch problemlos ein ganzes Buch schreiben. Kein Wunder: Teams, die vor ihrer agilen Transition regelmäßig stundengenaue Schätzungen über Arbeitspakete an einen Projektleiter abliefern mussten, tun sich schwer damit, sich von dieser Stunden-Denkart zu lösen oder mit “relativen” Größen anhand einer Referenz-Story zu arbeiten. Aber das alles sind Themen, bei denen Ihr Scrum Master dem Team helfen kann. Gehen wir also für alles Folgende davon aus, dass Ihr Team eine funktionierende Schätzmethodik praktiziert und dass es Informationen über seine “Team-Velocity” besitzt, denn: Beides ist nötig, um eine Aussage wie “Diese Story passt nicht in den nächsten Sprint!” treffen zu können. Wenn dieser Satz fällt, müssen Sie ran an Ihr Backlog und Storys “schneiden”.

Die gute Nachricht: Es gibt einen ganzen Sack voller nützlicher Heuristiken zum “Story Splitting”, aus dem Sie sich bedienen und mit der Zeit Ihren eigenen Fundus an Hilfsmitteln aufbauen können. Angefangen beim Splitting anhand von Signalwörter wie “und/oder”, können Sie Storys entlang von Prozessschritten aufteilen (siehe Boost 7 – ja, auch hier kann ein Modell helfen!), oder nach Rollen, nach Normal- und Alternativabläufen (… Modelle! …), nach Akzeptanzkriterien u.v.m. Eine Sammlung finden Sie z.B. in [16]. Wichtig dabei: Dies alles sind fachliche Kriterien zum Schnitt, die sich weitgehend noch im Problemraum bewegen und die Sie deshalb kennen sollten.

Prinzipiell ist auch ein Story-Schnitt nach technischen oder organisatorischen Kriterien möglich – z.B. nach Architekturerwägungen, Teamwissen, Verfügbarkeit von Platzhaltern in Testumgebungen, ja sogar nach der Abwesenheitsplanung des Teams. Die Empfehlung: Wägen Sie diese gemeinsam mit dem Team ab, aber bevorzugen Sie den Schnitt nach fachlichen Kriterien. Schließlich geht es um User (!) Storys, die einen Business (!) Value besitzen sollen. Mehr dazu gleich in Boost 9.

PS: Product Owner fragen mich immer wieder, wie sie „ihre Storys am besten schätzen“ sollen. Meine Antwort: gar nicht! Schätzen von Arbeitspaketen ist Aufgabe des Teams! (Priorisieren hingegen fällt unter Ihre ureigene Verantwortung als PO! Falls Sie das übrigens schwierig finden sollten, werfen Sie mal einen Blick auf “Impact Mapping”.) Deshalb ist es auch so wichtig, dass Sie sich beim Refinement neuer Storys frühzeitig eine erste Grobschätzung vom Team holen. Auch dazu erfahren Sie mehr im nächsten Boost.

9. Boost: Wie Sie das meiste aus einem Refinement herausholen können

Mit den bisher versammelten Hilfsmitteln lässt sich schon ganz gut ableiten, wie Sie als PO ihr Backlog Refinement so gestalten können, dass aus Sicht des Teams maximaler Nutzen entsteht. Welche Ziele sollten Sie mit dem Refinement verfolgen?

• Frühes Verständnis und Planungs-Transparenz: Das Team entwickelt frühzeitig ein akkurates Bild, welche Kundenwünsche im kommenden Sprint voraussichtlich implementiert werden sollen. Es kann folglich “auf kleiner Flamme” erste Gedanken über mögliche Lösungsansätze entwickeln und diskutieren und bei anstehenden Entscheidungen ggf. diesen “Ausblick” mit einfließen lassen.
• Frühes Feedback zu geplanten Storys: Sie als PO erfahren, zu welchen der entstehenden Storys welche Spezifikation vom Team als hilfreich empfunden und deshalb gewünscht wird (siehe Boost 6), und können diese idealerweise bis zum Planning noch vorbereiten. Außerdem erhalten Sie erste Signale aus dem Team zur Schätzung der Storys und zum Schnitt, genauer: Die Grobschätzung des Teams hilft Ihnen, nicht zu viele Storys ins nächste Planning-Paket zu schnüren. Und sie erhalten bei Storys, die schon jetzt als “zu groß für einen Sprint” eingeschätzt werden, neben diesem wichtigen Hinweis zusätzliche (technische) Ideen vom Team, wie man solche Storys aufteilen könnte (siehe Boost 8). Zuletzt: Auch zu Ihren vorbereiteten Akzeptanzkriterien können Sie erstes Feedback zu deren Verständlichkeit und Durchführbarkeit einholen – vor allem von den Test-ExpertInnen im Team (siehe Boost 5).

Als Konsequenz erreichen Sie, dass Effizienz und Effektivität der Sprint Plannings so ausfallen, dass das Team diese Scrum-Zeremonie gerne absolviert, Routine und Rhythmus entstehen, und die Plannings sich nicht in ausufernden Diskussionen verlieren.

Die Ziele sind damit klar, hier noch ein Wort zur Organisation. Manche Teams gönnen dem Refinement in jedem Sprint einen festen Zeitslot mit dem gesamten Team, also einen Regeltermin – das unterstützt die o.g. Ziele, ist aber vergleichsweise teuer. Manche Product Owner lassen die Refinement-Aktivitäten hingegen als “Grundrauschen” quasi im Hintergrund mitlaufen und holen sich pro Story gezielt einzelne Teammitglieder als Sparringspartner für eine Refinement-Session im „Pairing“. Beides funktioniert, und Sie sollten gemeinsam mit Ihrem Team experimentieren, welche Organisationsform Ihnen am meisten hilft. Ihr Scrum Master unterstützt Sie sicher gerne dabei.

10. Boost: Keep your backlog DEEP

“DEEP” ist hier ein Akronym und steht für

• Detailed appropriately: Storys, die demnächst umgesetzt werden sollen, sind detaillierter beschrieben und ausgearbeitet als solche, die erst später, irgendwann oder vielleicht auch gar nicht zum Zuge kommen. Außerdem sind sie typischerweise „kleiner“ als andere Storys (siehe Boost 8).
• Emergent: Ihr Product Backlog lebt und verändert sich permanent. Wenn Sie als PO täglich daran arbeiten, sollten Sie sich also keine Sorgen machen – im Gegenteil!
• Estimated: Storys, die erst in der Zukunft bearbeitet werden, sind vom Team noch nicht besprochen und ausreichend verstanden, folglich sind die damit verbundenen Schätzungen zwangsläufig grob. Umgekehrt sollten die Schätzungen anstehender Storys belastbarer sein.
• Prioritized: Die Storys mit dem höchsten Geschäftswert sollten am höchsten priorisiert und damit als nächstes für das Team vorgesehen sein.

Damit erhalten Sie eine hilfreiche Metapher, wie Ihr Product Backlog “im Ganzen” aussehen sollte: Stellen Sie sich Ihr Backlog wie einen Trichter vor (oder, wenn Sie’s lieber anders herum vorziehen, wie einen Eisberg). Neue Wünsche und Ideen werden oben in den Trichter eingekippt und sind meistens noch grob, knapp, unklar, unabgestimmt und damit weit entfernt von denen, die schließlich unten aus dem Trichter fallen und vom Team als “ready for the next sprint” bewertet werden. Ihr Job als PO ist es, alle diese Items zu sichten und je nach Business Value weiterzuentwickeln – also zu entscheiden, ob es sich überhaupt um Storys handelt (siehe [10]!), und falls ja, diese mit den Kunden/Stakeholdern abzustimmen, zu priorisieren, zu beschreiben, zu schneiden, mit Akzeptanzkriterien zu versehen und zu “refinen”, bis Sie sie schließlich irgendwann ins Product Planning mitbringen können. Diesen Prozess des Auswählens und “Wanderns” von Backlog Items durch das Backlog zu gestalten, ist eine Ihrer zentralen Aufgaben. Hilfsmittel dazu haben Sie in den vorhergehenden Boots erhalten, und Details zu DEEP finden Sie z.B. in [17].

Wie gut Sie das Backlog im Griff haben, sieht man als Außenstehender oft schon daran, wie “aufgeräumt” Ihr Product Backlog aussieht, d.h. wieviele und welche Backlog Items sich darin befinden und wie die Items aussehen, die für einen der nächsten Sprints vorgesehen sind. Treten Sie also am besten selber ab und zu einen Schritt zurück und fragen Sie sich: Befriedigt mich die Qualität meines Backlogs? Und wenn nicht, was könnte ich besser machen?

Zum Schluss noch zwei kurze Praxistipps:

1. Es ist ideal, als PO immer einen “Vorrat fertiger Storys” für die nächsten 1-2 Sprints im Backlog parat zu haben. Denn manchmal verschätzt sich das Team, oder im Planning tauchen Showstopper auf, an die im Refinement niemand gedacht hat – dann ist es nützlich, eine Reserve an alternativen Arbeitspaketen für das Team in der Hinterhand zu haben.
2. Und – sofern Sie Einfluss darauf haben, denn manche Tools und deren Konfiguration sind unternehmensweit gesetzt – halten Sie die Zahl an Item-Ebenen in Ihrem Backlog möglichst gering! Ganz ehrlich: Mit “Epics” und “Storys” (Tasks entstehen erst im Sprint Backlog und gehören außerdem dem Team), ergänzt um “Themes” zum Tagging nach Themen-Zusammengehörigkeit, komme ich in den meisten Product Backlogs schon sehr weit. Überlegen Sie sich genau, ob Sie weitere Elemente wie Features, Requirements u.s.w. wirklich brauchen – denn nicht nur wird Ihr Backlog mit jeder Ebene komplizierter, sondern Sie fangen sich auch müßige Diskussionen ein wie “Ist das hier noch ein Epic oder schon ein Feature?”. Bevorzugen Sie einfache Lösungen, ganz im agilen Sinne.

Fazit

Vermutlich werden Sie in der Rückschau auf diesen Beitrag nicht alle 10 Praxistipps gleichermaßen hilfreich finden, aber diese Bewertung fällt erfahrungsgemäß von PO zu PO anders aus. Hoffentlich waren aber auch für Sie einige neue Tipps dabei, die Sie in den nächsten Sprints gemeinsam mit Ihrem Team ausprobieren und in einer der folgenden Retrospektiven bewerten können.

Und wenn Sie sich als “Newbie” in der Product-Owner-Rolle wahrnehmen und von all diesen Tipps und Begriffen eben etwas erschlagen wurden, hier ein letzter Tipp: Als “Starter Kit” für neue Product Owner empfehle ich gerne den Dreiklang aus

• Use Cases & Story Maps – zum Finden werthaltiger Storys für Ihr (initiales) Backlog,
• Specification By Example – für testbare und vorführbare Akzeptanzkriterien an jeder Story,
• Spezifikationen & HAM – als Sammlung hilfreicher Artefakte, mit denen Sie Storys für Ihr Team bei Bedarf anreichern.

Dazu noch kontinuierliches “Pairing” mit den Teammitgliedern von Anfang an, und Sie sollten einen erfolgreichen Start als PO hinbekommen. Viel Erfolg auf Ihrer Reise!

Hinweise:

Interessieren Sie sich für weitere Erfahrungen aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] Brandes, Christian: Verständnis durch story-spezifische Artefakte: Requirements Engineering in agilen Projekten
[2] Podcast: Agiles Requirements Engineering – wie geht das?
[3] Blog: User Stories are not requirements
[4] Frank Zappa: Jazz isn’t dead. It just smells funny.
[5] Jeff Patton: “User Story Mapping”, O’Reilly 2015
[6] Schubert, Monika: Von der Impact Map zu User Storys
[7] Podcast: Sind Job Stories eine echte Alternative zu User Stories?
[8] Blog: Feature Teams vs Component Teams
[9] Blog: Why technical user stories are bad
[10] Podcast: Wie passen nicht-funktionale Requirements und technische Stories in ein agiles Backlog?
[11] Gojko Adzic: “Specification By Example”, Manning Publications 2011
[12] Podcast: Akzeptanzkriterien als konkrete Beispiele – wie geht das genau?
[13] Ron Jeffries: Essential XP: Card, Conversation, Confirmation
[14] Brandes, Christian: Modellieren im agilen Requirements Engineering – wohldosiert und leichtgewichtig
[15] Henschel, Gerhard: „Die wirrsten Diagramme der Welt“, Hoffmann und Campe 2003
[16] Blog: Splitting User Stories
[17] Pichler, Roman: Make the Product Backlog Deep

Von QualityMinds finden Sie im t2informatik Blog weitere Beiträge:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.