Boost your Backlog – Teil 1

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

Viele Product Owner fangen vor einem solchen Hintergrund an, ihre ersten Storys oder PBIs (Product Backlog Items) zu erstellen, aber so einfach, wie der gerade mal 20-seitige Scrum-Guide das vielleicht suggeriert, gestaltet sich die tägliche Arbeit im und am Backlog dann doch nicht. Die gute Nachricht: Mit dieser Erfahrung sind Sie nicht allein, und wir haben es durch die Bank mit lösbaren Problemen zu tun. Dieser Beitrag versammelt zehn – zugegeben subjektiv ausgewählte – Lösungen und Techniken, die Product Ownern und agilen Teams im Coaching immer wieder geholfen haben. Er konzentriert sich dabei, wie der Titel verrät, auf das Product Backlog, und blendet andere Themen wie etwa die Produktvision oder das “Big Picture” eines agilen Requirements Engineerings bewusst aus. (Wenn Sie hierzu mehr erfahren wollen, finden Sie Details in [1] und [2].)

Die gesammelten 10 Praxistipps lassen sich grob in die drei Themenblöcke „Storys finden“, „Storys schreiben“ und „Storys verbessern“ einteilen. Sie sind unterschiedlich groß und unterschiedlich konkret, aber jeder Tipp wurde ausgewählt, weil er Ihnen bei der Erstellung und Pflege eines Backlogs nützliche Dienste leisten kann. Gleich der erste sorgt vor allem für grundsätzliches Verständnis und kommt Ihnen vermutlich noch wenig operativ vor, aber das wird sich spätestens ab dem 2. “Boost” ändern. (Und noch ein letzter Hinweis, bevor wir loslegen: Die meisten Tipps werden am Beispiel Scrum erklärt, da dies nach wie vor das “Tempo unter den agilen Taschentüchern”, also das am weitesten verbreitete agile Framework in IT-Projekten ist.)

1. Boost: User Storys sind keine Requirements

Hier liegt ein weit verbreitetes Missverständnis vor, auf das bereits andere Autoren hingewiesen haben (siehe etwa [3]): User Storys sind Arbeitspakete, also Planungsartefakte, die einen äußerst sprechenden Namen sowie idealerweise testbare Akzeptanzkriterien tragen. Sie spielen also keineswegs die Rolle von “Requirements”! Vielmehr sollten Sie sich Storys als “Container” vorstellen, deren Name allein – also die “Story” im wohlbekannten Format mit Rolle, Funktionalität und Wert – nicht alle Details in sich trägt, die das agile Team für die Bearbeitung benötigt, und die deswegen um Details “aufgefüllt” und angereichert werden müssen. Das geschieht vor allem durch direkte Kommunikation im Sprint, nur ist das nicht immer ausreichend oder die bestmögliche Lösung. Geben Sie sich also bitte nicht dem Bild hin, dass die IT-Disziplin des “Requirements Engineering” komplett durch “Storys an einem Board” abgelöst wurde! Frei nach Frank Zappa gilt im Agilen höchstens: „RE is not dead, it just smells funny.“ [4]

Anders gesagt: Storys benennen ein Requirement, aber sie beschreiben es nicht. Das Story-Template adressiert das “Was” und das “Warum” eines Kundenwunsches (den sog. Problemraum, siehe Boost 3), liefert aber keine weiteren Details. Es hilft dem Team nur, das Arbeitspaket mit einem Blick schneller und besser zu verstehen. Eine Arbeitsplanung mittels Storys entbindet ein agiles Team also nicht von allen Aufgaben zum Requirements Engineering und zur Dokumentation!

Sobald Sie diese fundamental wichtige Botschaft zu User Storys verinnerlicht haben, sind Sie vorbereitet für mehr. Aber zuerst noch etwas Geduld bitte. (Weiterführende Tipps zu Akzeptanzkriterien werden Sie im Boost 5 erhalten und zu Story-Spezifikationen im Boost 6.)

2. Boost: Wie Sie mit Use Cases & Story Maps systematisch Storys finden können

Use-Case-Modellierung, zentrales Hilfsmittel in der objektorientierten Analyse, hat zwar soooo einen langen Bart, aber trotz des ehrwürdigen Alters zeigt sich, das man damit als Product Owner zügig, leichtgewichtig und systematisch eine erste Ladung User Storys (genauer: „Epics“, also große Storys) für sein initiales Backlog erarbeiten kann.

In der Praxis genügt dafür eine Wand/ein Whiteboard/ein Flipchart sowie etwas Zeit mit Kundenvertretern und Stakeholdern. Ein elementares Use Case Diagramm beschreibt die Außensicht auf das angestrebte Produkt, also eine Black-Box-Sicht aus Anwenderperspektive, und gibt eine Antwort auf die Frage: “Wer bekommt was vom Produkt?” Sie erhalten damit eine erste Partitionierung des Produkts entlang zu entwickelnder Funktionen für bestimmte Nutzergruppen.

Die Nutzergruppen heißen im Diagramm “Akteure” und die identifizierten Funktionen “Use Cases” (dt. Anwendungsfälle), die sich – halten Sie sich fest! – dadurch auszeichnen, dass sie mit einem Geschäftswert für den Nutzer einhergehen. (Wenn Sie User Storys kennen, sollten Sie jetzt ein Déja-Vu haben.) Ein moderierter erster Workshop vor der o.g. Wand führt erfahrungsgemäß dazu, dass die Stakeholder sich auf Rollen, Bezeichnungen und Funktionen einigen; das dauert nicht lange und ist für den weiteren Projektverlauf hilfreich. Deshalb geben Use Cases auch ein praktisches Hilfsmittel für die Erstellung einer Produktvision ab, aber das nur am Rande.

Gute Use Cases tragen im Namen ein Verb (also “Buch bestellen”) und sind über eine einfache Linie verbunden mit den Akteuren, die den Use Case jeweils anstoßen/”triggern” dürfen. Und das war’s schon: Jede Kombination aus Akteur und Use Case lässt sich schon fast mechanisch ins Story-Format überführen (nur den Business Value – den es per Definition aber zu jedem Use Case geben soll! – müssen Sie noch explizit dazuschreiben), und damit erhalten Sie erste werthaltige PBIs für Ihr Backlog. Die sind meistens ziemlich grobgranular und deshalb zu groß für einen einzelnen Sprint, drum behandeln wir sie in der Regel als Epics.

Und dann? Dann helfen Story Maps ganz ausgezeichnet weiter.

Der Reihe nach: In der traditionellen Analyse werden identifizierte Use Cases im nächsten Schritt dergestalt ausspezifiziert, dass die internen Abläufe beschrieben werden, die zur Erbringung des gewünschten Ergebnisses jeweils nötig sind. Diese Abläufe werden häufig unterteilt in “Normalablauf/Happy Path”, “Alternativabläufe”, “Fehlerbehandlung” o.ä. Wenn Sie nun zu jedem Use Case (=Epic) einen Normalablauf als Sequenz von Prozessschritten beschreiben und dann zu jedem Prozessschritt sammeln, was das Produkt alles können/bereitstellen muss, haben Sie eine “Story Map” nach Jeff Patton ([5]). Und damit eine ganze Menge weiterer Storys für Ihr Backlog! Ein Beispiel für eine solche Map sehen Sie in Abbildung 2: Ersetzen Sie darin einfach “1. Aktivität” durch “Use Case”, betrachten Sie die gelb markierten Schritte als Prozess-Modellierung eines Ablaufs/Szenarios zu diesem Use Case, und die “Detailfunktionen” sind dann Story-Kandidaten.

Abbildung 2: Beispiel für eine Story Map (aus [6])

Details finden Sie in [5] und [6]. Das geschilderte Vorgehen funktioniert in der Praxis ganz ausgezeichnet, unterstützt Sie außerdem bei Themen wie MVP oder Releaseplanung, und es lässt sich natürlich völlig analog auf weitere identifizierte Abläufe/Szenarien pro Use Case anwenden. Probieren Sie’s aus!

3. Boost: User Storys bleiben im Problemraum!

Im Problemraum beschreiben wir das “Was” (der Kunde will) und das “Warum” (der Kunde etwas will), aber noch nicht das “Wie”, also die technische Umsetzung – das ist dann Bestandteil des sog. Lösungsraums. Die Grenze zwischen den beiden ist zugegeben nicht immer deutlich zu erkennen, aber Sie sollten versuchen, sie nicht aus dem Auge zu verlieren. User Storys der Geschmacksrichtung “Als Anwender möchte ich neben dem Eingabefeld <XYZ> eine weitere Schaltfläche, mit der ich…”, die sich von Anfang an im Lösungsraum bewegen („Schaltfläche“ in einer User Story? Mehr Lösungsraum geht gar nicht!), gilt es im Backlog möglichst zu vermeiden. Warum?

Die Erarbeitung einer technischen Lösung für einen fachlichen Wunsch ist Sache des Entwicklungsteams. Wann immer Ihre Stakeholder schon mit technischen Lösungen – so naheliegend und verführerisch sie auch wirken mögen – um die Ecke kommen, stellen sich mehrere Folgefragen:

• Wer sagt, dass das die “beste” technische Lösung ist?
• Warum bleibt das kreative und technische Potenzial des Teams ungenutzt?
• Und vielleicht ist die in der Story vorweg genommene “Lösung” technisch gar nicht umsetzbar oder gefährdet Vorgaben zu Benutzerführung, Barrierefreiheit u.s.w.?

Fachspezialisten sind in der Regeln keine technischen Experten, und eine der Aufgaben eines Product Owners ist es eben, zwischen diesen beiden Welten zu vermitteln.

Ein Tipp: Wenn ein Stakeholder schon mit Lösungsideen unterwegs ist, nehmen Sie seine Lösung ruhig für das Team als “Beispiel” mit (denn es mag dem Team helfen, besser zu verstehen, was der Kunde braucht), aber weisen Sie darauf hin, dass nicht garantiert ist, dass exakt diese Lösung gebaut wird und dass die Entwicklung möglicherweise mit noch besseren Vorschlägen aufwarten wird. Außerdem bohren Sie nach: Warum will der Stakeholder z.B. diese Schaltfläche? Die “5-Whys“-Technik besagt, dass Sie maximal 5x “Warum?” nachfragen müssen, bis Sie den tatsächlichen fachlichen “need” des Kunden vor sich haben. Und genau diesen “need” gießen Sie dann in eine Story!

Vielleicht hilft folgendes Gedankenexperiment: Lassen Sie sich erklären, wie das Gewünschte in einer Vor-IT-Welt, also z.B. papierbasiert aussehen würde, in der es noch keine Klicks, Excel-Exporte und Apps gibt. Ziel für einen PO sollte sein, sich in der Sprache der fachlichen Domäne zu bewegen (also “Neukunde anlegen” anstatt “auf <XYZ> klicken”). Trennen Sie Fachlichkeit und Implementierung wo immer möglich!

Fußnote: Sollten Sie es bei dieser Arbeit übrigens manchmal schwierig finden, die Rolle im Story-Template anzugeben, experimentieren Sie und ihr Team mit “Job Storys” [7]. Die bleiben aber auch im Problemraum.

4. Boost: Vermeiden Sie “technische Storys”!

Bleiben wir noch etwas bei der Grenze zwischen Fachlichkeit und Technik. “Technische User Stories” erkennen Sie daran, dass als Rolle nicht ein Anwender, sondern ein Projektmitarbeiter oder gar eine IT-Komponente genannt wird. Beispielsweise:

• “Als Tester möchte ich…”
• “Als Entwickler möchte ich…”
• “Als Backend möchte ich…”
• “Als API möchte ich…” (einer meiner Favoriten)

Außerdem – Sie ahnen es – bewegen sich diese Storys fast ausschließlich im Lösungsraum (siehe Boost 3).

Dahinter steckt oftmals schlicht das Missverständnis, dass als Folge einer agilen Transition alle Wünsche und Anforderungen zwingend im Story-Format vorliegen müssten. Oder aber Ihr Projekt, das aus mehreren agilen Teams besteht, ist in sog. “Komponenten-Teams” organisiert, also entlang der Architektur des Produkts (z.B. ein UI-Team, ein Backend-Team, ein Storage-Team, ein Team für Komponente X etc.). In solchen Konstellationen hat natürlich nicht jedes Team unmittelbar “Kontakt” mit der fachlichen Domäne und den Wünschen des Anwenders, und wenn ein solches Team ein eigenes Backlog mit Stories füllen möchte, nimmt der Anteil an technischen Stories erfahrungsgemäß zu. (Randnotiz: Falls noch möglich, denken Sie in einer solchen Situation lieber über “Feature-Teams” [8] nach und bekämpfen Sie statt den Symptomen die Ursachen.)

In der Praxis sorgen technische Storys regelmäßig dafür, dass der PO Probleme hat, sie zu priorisieren oder ihren “Business Value” zu benennen. Kein Wunder, denn der “Value” dieser Storys besteht fast immer im Versprechen einer höheren Team-Velocity in der Zukunft. Und auch die Formulierung von Abnahmekriterien und die Beantwortung von Team-Rückfragen während des Sprints kann bei technischen Stories knifflig für den PO werden.

Technische Aufgaben, wie etwa ein Ausbau des Testautomatisierungs-Frameworks oder Code-Refactorings, müssen vom Team natürlich in einem Sprint eingeplant und eingepreist werden – aber es gibt andere Lösungen, als solche Aufgaben ins Story-Format zu pressen und damit das Format einer “User(!) Story” zu missbrauchen. Am häufigsten funktionieren dafür stattdessen Tasks – also technische Tasks, die in der Hoheit des Teams liegen und die im Sprint Backlog gesammelt werden. Entweder das Team findet für solche Tasks jeweils eine passende Story, oder es spendiert sich eine eigene Swimlane am Board für Arbeiten “unter der Haube” und reduziert die Velocity z.B. um eine Art technische Flatrate. Beratschlagen Sie sich hierzu mit Ihrem Scrum Master, aber lassen Sie sich nicht zu technischen Storys überreden – bleiben Sie standhaft! Details finden Sie z.B. in [9] und [10].

5. Boost: Eine Geheimwaffe – Akzeptanzkriterien in Form konkreter Beispiele

Auf den “German Testing Days 2018” hielt ich einen Pecha-Kucha-Vortrag mit dem dramatischen Titel “Akzeptanzkriterien – verkannt, geschunden, verschwendet”. Leider werden die Chancen, die in testbaren Akzeptanzkriterien schlummern, tatsächlich oftmals vertan, und stattdessen wird bei “Akzeptanzkriterien” zu einer Story – auch wenn es hart klingen mag – alles mögliche angegeben: zusätzliche/weitere/neue Requirements, nichtfunktionale Anforderungen, Unentscheidbares wie “das System muss schnell reagieren”, oder einfach gar nichts (“sind ja eh klar”). Hier lernen Sie eine Methode kennen, die dieses ungeliebte Pflichtfeld zu einem echten “Boost” im agilen Team werden lassen kann.

In einer idealen Welt wären Akzeptanzkriterien von vornherein Testfälle, also ausführbar beschrieben, klar entscheidbar und wiederholbar. Falls Sie und Ihr Team das bereits so handhaben: Glückwunsch! Das mindeste, was gute Akzeptanzkriterien aber immer sein sollten, sind konkrete Beispiele. Dieser schlaue Ansatz trägt einen eigenen Namen: “Specification By Example” ([11]). Sie finden solche Beispiele zu einer Story mit folgendem kleinen Gedankenexperiment: Nehmen Sie an, Ihr Team signalisiert, es wäre mit einer Story fertig und Sie könnten zur Abnahme schreiten – und nehmen Sie weiter an, Sie hätten für diese Abnahme nur 10 Minuten Zeit! Was würden Sie dann in diesen 10 Minuten sehen oder tun wollen, um nach Ablauf der Zeit über eine Abnahme entscheiden zu können? Genau das schreiben Sie als Akzeptanzkriterien auf, und das Ergebnis sind – Beispiele! Probieren Sie’s aus.

Nach meiner Erfahrung passt das sehr gut, denn eine Abnahme kann und soll ja keinen systematischen, methodischen, risikobasierten Test ersetzen. Abnahme ist Vertrauenssache, und Sie müssen sich fragen, was Sie sehen wollen, um dem Team und seinem Arbeitsergebnis zu vertrauen. Das können unverzichtbare Standardabläufe sein, die immer und überall funktionieren müssen, oder besonders knifflige Exoten-Konstellationen, oder Testergebnisse des Teams, oder eine Mischung aus all dem: Die Entscheidung darüber liegt alleine beim PO!

Wenn Sie diese Beispiele nun (angelehnt ans “Behavior Driven Development”) schon sehr testfallnah aufschreiben – etwa mit der Dreiteilung “Given/When/Then”, mit konkreten Eingabe- und Ausgabedaten, aber möglichst ohne UI-Details (siehe Boost 3) – fahren Sie und Ihr Team gleich mehrere Vorteile ein:

• Storys, die mit solchen Beispielen ausgestattet sind, versteht das Team schneller und besser. Logisch: Wenn Sie etwas Neues lernen und verstehen wollen, sind Sie ebenfalls für Beispiele dankbar!
• Diese Beispiele sind ein lohnender Startpunkt für Testentwurfs-Aktivitäten im Team.
• Sie sind heiße Kandidaten für automatisierte Regressionstests, da sie ausdrücken, was dem Auftraggeber (in diesem Fall Ihnen als Product Owner) “am wichtigsten” ist.
• Das Team muss sich nicht mehr fragen, was es zu einer fertigen Story in einer Demo vorführt – denn genau das ist mit den Beispielen schon beschrieben.
• Und diese Beispiele können in Online-Hilfen, Schulungsunterlagen und anderen Dokumentationen wiederverwendet werden.

Nicht schlecht, oder? Deshalb nenne ich „Beispiele als Akzeptanzkriterien“ eine Geheimwaffe. Weitere Details finden Sie z.B. in [12]. 

Ausblick

Dies war der erste Teil der zweiteiligen Serie “Boost your Backlog”. In Teil 2 geht es um testbare Spezifikationen, wertvolle Dokumentation, das Schneiden von Storys, ein optimales Refinement und um DEEP. Dieses Akronym steht für … ach, das verrate ich Ihnen einfach in Teil 2 meines Beitrags. Würde mich freuen, wenn Sie dann hier wieder vorbeischauen.

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?

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

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.