Wie Story Maps Scrum-Projekte retten

Bei der Software-Entwicklung nach agilen Methoden wie Scrum zerlegen Programmier-Teams die Anforderungen in kleine Stückchen. Die Folge: Der Überblick kann verloren gehen. Um das zu verhindern, hat der Amerikaner Jeff Patton Story Maps erfunden. Im Interview erklärt Marcus Winteroll, wie diese Methode, Projekte zu visualisieren, funktioniert. Winteroll ist Trainer und Berater mit Schwerpunkt auf Analyse und Verbesserung von Abläufen bei Oose Innovative Informatik aus Hamburg, einem Anbieter von Schulungen und Coachings rund um Software-Entwicklung und Projektmanagement.

CIO.de: Sie schreiben, beim Aufteilen der Anforderungen in kleine User Stories bei agilen Projekten gehe Kontextwissen verloren. Was heißt das?

Marcus Winteroll: Bei agilen Projekten werden die Anforderungen im sogenannten Product Backlog hinterlegt. Darin stehen zum Teil sehr weit gefasste Dinge, zum Beispiel Kundenverwaltung. So etwas muss man erst zerlegen in Teile wie die Aufnahme eines neuen Kunden oder Änderung von Kundendaten. Die Teile müssen so klein sein, dass sie in einer Iteration machbar sind. Weil sie anschließend unterschiedlich priorisiert werden, werden Dinge, die zusammen gehören, zeitlich oft sehr verteilt bearbeitet. Das macht es schwierig, sie im Zusammenhang zu sehen und den Überblick zu behalten.

CIO.de: Anforderungen in Einzelteile zu zerlegen ist ja etwas, das Scrum auszeichnet. Und genau das wird zum Problem?

Winteroll: Es kann bei Scrum in purer Form zum Problem werden. Im Scrum-Guide von Ken Schwaber und Jeff Sutherland stehen allenfalls vage Hinweise, wie man den Überblick über das Gesamtbild behält. Dieser Punkt wurde vernachlässigt. In der Praxis kompensieren das sicherlich oft gute Leute. Ein sehr guter Product Owner ist in der Lage, den Überblick zu behalten. Das ist aber sehr anspruchsvoll.

CIO.de: Sie schlagen als Lösung den Einsatz von Story Maps vor. Auf den ersten Blick sieht das nicht spektakulär aus: Karteikarten in unterschiedlichen Farben an einer Pinnwand. Wie genau funktionieren Story Maps?

Winteroll: Die Anordnung von links nach rechts stellt die grobe zeitliche Abfolge dar. Ihr entlang ordnet man typische Tätigkeiten an. Die Abfolge zeigt: Gibt es in dem System, das ich entwickle, einen sinnvollen Gesamtablauf oder fehlt womöglich etwas? Die verschiedenen Farben der Karten repräsentieren Abstraktionsebenen.

CIO.de: Welche sind das?

Winteroll: Die obere Ebene sind Aufgabenbereiche. Sie dienen als Überschriften zur Gliederung. Das können zum Beispiel Namen von Geschäftsprozessen sein. Darunter kommt die Ebene der Tätigkeiten, also von Abläufen. Auf ihnen liegt bei einer Story Map der eigentliche Fokus. Dritte Ebene ist die der Details.

Einzelheiten nicht zu Beginn besprechen

CIO.de: Wozu braucht man die?

Winteroll: Die sind gerade dann wichtig, wenn man mit dem Kunden über das Projekt spricht. Kunden nennen sehr oft Details. Zum Beispiel: Wir müssen für neue Kunden neben einer Lieferanschrift auch eine Rechnungsanschrift erfassen können. Doch bevor man sich mit solchen Details beschäftigt, müssen erst mal die grundsätzlichen Möglichkeiten der neuen Kundenverwaltung klar sein; also dass neue Kunden erfasst werden sollen, die Daten der vorhandenen veränderbar sein müssen und so fort. Die Details werden später wichtig, daher können sie schon mal aufgenommen werden, wenn der Kunde davon spricht. Gleichzeitig wird durch die Platzierung auf der Detailebene für den Kunden auch sichtbar: Wir sind hier schon bei den Details angelangt und sollten wieder eine Abstraktionsebene höher gehen - zu den Tätigkeiten.

CIO.de: In einem Schaubild über Story Maps haben Sie mehrere rote Tätigkeits-Karten übereinander angeordnet. Was sagt diese Anordnung aus?

Winteroll: Stellt man Tätigkeiten übereinander, steht das einerseits für Alternativen. Oder es kennzeichnet Prioritäten. Auf diesen Prioritäten basiert dann beispielsweise die Release-Planung. Ich stelle die Frage: Was bringt den meisten Nutzen? Das kommt in den ersten Release. Ein Ziel agiler Methoden ist ja gerade der schnelle Nutzen. Story Maps verschaffen mir Überblick, damit ich die wichtigsten Dinge wirklich alle in den erste Release packe.

CIO.de: Was braucht man, um Story Maps einzusetzen? Reichen eine Pinnwand und Karteikarten?

Winteroll: Eine gewöhnliche Pinnwand ist oft zu klein. Außerdem hat sich gezeigt, dass das Umpinnen von Karten mit Stecknadeln zu lang dauert. Bewährt haben sich dagegen Klebezettel auf einer großen freien Wand. Kärtchen auf Tisch oder Fußboden gehen auch, auf beiden kann man die Karten gut hin und her schieben. Wichtig ist, dass sich die Story Map leicht verändern lässt. Am besten steht sie die ganze Projektlaufzeit über im Projektraum, in dem sich das Team trifft. Wer dort zwischendurch Tisch oder Boden frei räumen muss, kann sie ja vorher fotografieren. Das ist auch dann sinnvoll, wenn man mit Klebezetteln arbeitet. Es könnte ja mal einer herunterfallen.

CIO.de: Wann erstellt man die Story Map? Ganz zu Anfang?

Winteroll: Fast. Vorher sollte man sich mit dem Kunden über Vision und gemeinsame Ziele klar werden. Dann ist die Story Map der nächste Schritt. Am besten erarbeitet der Auftragnehmer eines Projekts sie zusammen mit allen Stakeholdern. Alle, die nachher am Projekt arbeiten, sollten den Kontext kennen, auch die Entwickler.

Entwickler bei Story Map einbeziehen

CIO.de: Aber das ganze Team kann doch nicht von Anfang an dabei sitzen.

Winteroll: Mit 30 Leuten geht das natürlich nicht. Ideal sind sechs bis acht Personen, die Grenze würde ich bei zehn ziehen. Bei großen Projekten müssen eben die verschiedenen Seiten Repräsentanten schicken - die Entwicklersicht sollte auf alle Fälle vertreten sein.

CIO.de: Wie lässt sich die Story Map anschließend in den Projektverlauf einbinden?

Winteroll: Steht sie die ganze Zeit über im Projektraum, können Entwickler, die an einem kleinen Schritt arbeiten, ihre Arbeit mit Blick auf die Story Map immer wieder einordnen. Der zweite Nutzen hat mit den Veränderungen in agilen Projekten zu tun. Vieles ist dabei nicht in Stein gemeißelt. Wenn Dinge neu bewertet werden müssen, lässt sich das mithilfe der Story Map schnell darstellen.

CIO.de: Was beobachten Sie beim Einsatz von Story Maps?

Winteroll: Ein Effekt ist, dass sich ein gemeinsames Gesamtbild des Projekts entwickelt. Ohne Story Map hat jeder eine eigene Sichtweise, oft ohne dass es den Beteiligten bewusst ist. Die Story Map macht unterschiedliche Auffassungen deutlich. Ein weiterer Vorteil ist, dass man Abläufe lösungsneutral aufzeichnet. Das verhindert, was ich vorhin beschrieben habe: dass die Leute von Anfang an in konkreten Lösungen denken.

CIO.de: Wie wichtig ist Lösungsneutralität?

Winteroll: Sie ist wesentlich, das betont auch Jeff Patton, der Erfinder der Story Maps. Schon im klassischen Requirements Engineering ist davon die Rede, und in den Richtlinien zum Lean Software Development ist das zum Prinzip erhoben. Hintergrund ist: Wenn man Details später festlegt, weiß man schon viel mehr und entscheidet auf anderer Grundlage. Zuerst sollte man immer die Abläufe festlegen.

Größter Fehler: Gleich in Lösungen denken

CIO.de: Hat die Veranschaulichung mit Story Maps Grenzen?

Winteroll: Ja. Story Maps beschreiben Abläufe. Also sind sie vor allem für Systeme geeignet, die Abläufe unterstützen. Für die Entwicklung reaktiver Systeme, nehmen wir einen Videorekorder oder ein Textverarbeitungsprogramm, sind sie weniger brauchbar. Ein Grenzfall für die Anwendung sind auch schon bestehende Systeme. Da stellt sich die Frage, ob ich im Nachhinein noch das bereits entwickelte System auf einer Story Map dokumentiere für künftige Weiterentwicklungen. Aber auch das geht. Story Maps sind eine sehr leichtgewichtige Methode, viel schlanker als eine aufwändige Geschäftsprozess-Modellierung.

CIO.de: Wenn Sie Story Maps erklären, klingt die Methode leicht umsetzbar. Welche Fehler kann ich machen?

Winteroll: Viele Kunden denken gleich in Lösungen, beschreiben also zum Beispiel detailliert die Masken der neuen Anwendung. Schwer tun sich Entwicklungsteams und Auftraggeber oder Product Owner anfangs außerdem, das richtige Abstraktionsniveau zu finden: Sprechen wir von einem Aufgabenbereich, einer Tätigkeit oder einem Detail? Ich beobachte allerdings, dass die Leute dafür in der Regel schnell ein Gespür entwickeln..

CIO.de: Wie verbreitet ist die Methode?

Winteroll: Zahlen dazu habe ich keine. Story Maps sind noch recht neu. In Deutschland kennen die Methode noch sehr wenige. Ich habe auch schon mit erfahrenen Scrum Masters gesprochen, die Story Maps nicht kannten. In den USA haben sich die Story Maps schon stärker durchgesetzt.

CIO.de: Danke fürs Gespräch.