Wirklich wirkungsvolle Agilität mit Business Storys
In agilen und nicht-agilen Entwicklungen liegt unser Fokus nach wie vor auf Ergebnissen. Wir betrachten Produktinkremente, bewerten die Geschwindigkeit/ Velocity des Teams und zählen die Anzahl der Features. Dabei vergessen wir allzu oft, dass die Ergebnisse am Ende Wirkung erzielen müssen. Wirkung für alle Interessengruppen an einem Produkt, also für alle Nutzer, aber auch für alle anderen, die durch das Produkt einen irgendwie gearteten Nutzen ziehen.
In diesem Artikel diskutieren wir, wie mittels Business Storys wirklich Wirkung erzielt und somit die Mission der Agilen Softwareentwicklung erfüllt werden kann.
Wo ist da die Wirkung?
Agile Vorgehensweisen haben in der Produktentwicklung viel verändert. Statt langwierige Projektpläne zu entwickeln und diese dann sequentiell umzusetzen, nutzen Unternehmen die Leistungsfähigkeit ihrer Teams, um kleine möglichst wertvolle Ergebnispakete zu schnüren, diese schnell und konzentriert umzusetzen und regelmäßig an ihre Kunden auszuliefern. Das bietet extreme Vorteile: früheres Feedback vom Markt, schnellere Anpassbarkeit, Reduktion der Time to market und damit schnellerer Break-even.
Auf diese Weise wird viel schneller Wert zu den Interessengruppen geliefert. Als Interessengruppen werden alle diejenigen bezeichnet, die ein berechtigtes Interesse (Erwartung, Anspruch, Anteil) an den Wirkungen eines Produktes haben. Diese umfassen beispielsweise die Nutzer und Nutznießer, aber auch die Sponsoren eines Produktes. Zur Beschreibung der Nutzer und Nutznießer mit ihren Bedürfnissen und Problemen werden häufig Personas eingesetzt. Personas sind fiktive Repräsentanten von Personen oder Personengruppen.
Aber was ist wirklich "Wert" bzw. was macht ein Produkt wertvoll? Auf den ersten Blick ist erstmal alles das wertvoll, was irgendwie eine positive Wirkung hat. Meist bezieht sich diese Wirkung auf die Nutzer (z. B. einfache digitale Unterstützung bei der täglichen Aufgabenbewältigung) und/oder Nutznießer (z. B. Remonetarisierung des Invests). Dabei verfolgen neue Produktideen meist hehre Ziele in Bezug auf diese erhofften Wirkungen. Im besten Fall gibt es eine schicke Produktvision, mit einem entsprechend emotionalisierenden Wirkversprechen. Doch geht es an die Umsetzung verliert sich der Fokus auf die versprochenen Wirkungen. Wird z. B. das große Business-Thema, das "eine Million neue Kunden bringt" in kleine User Storys heruntergebrochen, wird die übergeordnete Wirkung immer diffuser. Wie zahlt z. B. die Story, dass der Nutzer "die Druckfunktionalität uneingeschränkt nutzen kann" auf das große Ziel der "eine Million neue Kunden" ein? Wie viele Kunden könnten damit potentiell gewonnen werden? Wie viele springen wieder ab? Diese Fragen stellen sich die wenigsten und noch seltener kommt es zu einer Überprüfung dieser Annahmen nach Fertigstellung der Story. Die Wirkung wird, wenn überhaupt, erst viel später, auf ganz anderer Ebene und völlig entkoppelt von der Priorisierung und Erstellung von Storys überprüft. Das erschwert es, das Nutzer-Feedback einzuordnen und sinnvoll zur Verbesserung des Produktes und dessen Entwicklung zu verwenden. Um die Lücke zwischen Produktvision und Epic bzw. User Story zu füllen kommen Business-Storys ins Spiel.
Wirkung mit Business-Storys fokussieren
Eine Business Story beschreibt eine Wirkung, die wir für die unterschiedlichen Interessengruppen erzielen wollen. Eine Wirkung meint hier allerdings nicht nur einen Wert, also eine positive Wirkung (=Nutzen), wie sie oben beschrieben ist, sondern wir wollen hier explizit auch prüfen, ob eine Business Story auf einzelne Personas auch eine negative Wirkung haben kann oder haben wird (=Schaden).
Nehmen wir als Beispiel einen Möbelhersteller, der Standardmöbel über Möbelhäuser und über einen eigenen Webshop verkauft. Dieser möchte seinen Internetkunden die Möglichkeit geben, die existierenden Möbel anzupassen (Maße, Farben, Materialien). Abb. 2 zeigt dafür eine Business Story.
Die Kunden sollen die Möglichkeit erhalten, Anpassungen an unseren Standardmöbeln vorzunehmen, so dass diese besser in ihre Wohnungen und Häuser passen. Wir erhoffen uns als Unternehmen davon, dass wir zusätzliche Umsätze durch die Anpassungsleistungen generieren und neue Kunden gewinnen, die keine Standardmöbel kaufen. Unsere Annahmen dahinter sind, dass wir aktuell Kunden haben, die bereit sind, zusätzlich Geld für angepasste Möbel auszugeben und dass es Kunden gibt, die jetzt noch nicht bei uns kaufen, dies aber tun würden, wenn wir angepasste Möbel anbieten würden.
Die Wirkung wird selten mehr als ein Best Guess sein. Zunächst kann niemand sicher sagen, ob und wie schnell die gewünschte Wirkung hergestellt werden kann. Daher ist der Feedbackzyklus extrem wichtig. Wir sollten Klarheit darüber herstellen, wie häufig die Wirkung evaluiert wird (im Beispiel: monatlich) und welche Kriterien dabei in erster Linie zur Evaluation herangezogen werden (siehe unten). Auf der anderen Seite sollten wir schon vor Beginn der Umsetzung gemeinsam festlegen, unter welchen Umständen wir die Umsetzung nicht fortführen wollen, da wichtige Hypothesen widerlegt wurden oder sich der Business Case nicht mehr rechnen kann.
Nicht zuletzt werden die Beteiligten festgehalten, die es braucht, um die Wirkung zu erzielen. In den meisten Fällen ist bereichsübergreifende Zusammenarbeit gefragt. In unserem Fall wollen wir beispielsweise eine neue Zielgruppe erschließen (Menschen, die keine Standardmöbel kaufen), so dass nennenswerte Aufwände für Marketing inkl. Marktforschung entstehen werden.
Ein solches Inspect & Adapt auf Wirkungsebene schafft echte Business Agility.
Die Evaluationskriterien der Business Storys unterscheiden sich deutlich von den Akzeptanzkriterien der User Storys. Für User Storys kann man im Sprint oder spätestens im Sprint Review feststellen, ob die Akzeptanzkriterien erfüllt sind. Das ist möglich, weil sie sich auf das Produkt (das Ergebnis des Sprints) beziehen. Bei Business Storys sieht die Situation anders aus. Sie beziehen sich auf die Wirkung, die mit dem Produkt erzielt werden soll. Diese Wirkung ist erst nach dem Release im Einsatz feststellbar und sie braucht die "Mitarbeit" der Nutzer. Sie können daher nicht sicher vorhergesagt werden. Ziel- oder Planwerte für Evaluationskriterien sind eine gute Idee, um Klarheit zu schaffen. Wir sollten aber nicht der Illusion erliegen, dass sie mehr sind als ein Best Guess. Wir können davon ausgehen, dass sich die Realität anders entwickelt und unsere Ziel- und Planwerte regelmäßig von der Realität abweichen. Wir dürfen sie also nicht benutzen, um jemanden zu belohnen oder zu bestrafen. Wir nutzen sie, um wertvolle Dialoge zu führen, in denen wir herausfinden, was die konkrete Abweichung für das Unternehmen und das weitere Vorgehen bedeutet. Ein solches Inspect & Adapt auf Wirkungsebene schafft echte Business Agility.
Business Storys kleiner machen
Business Storys werden im ersten Wurf groß sein. Wir wollen Wirkung allerdings möglichst früh herstellen, um Lernen und Wertschöpfung zu optimieren. Nach unserer Erfahrung sind gute Business Storys maximal 3 Monate lang. Daher müssen große Business Storys klein geschnitten werden. Die Idee ist ähnlich zum Kleinschneiden von Epics und User Storys: Wir wollen Epics und User Storys so runterbrechen, dass wieder User Storys entstehen und nicht etwa technische Tasks. Business Storys wollen wir so runterbrechen, dass wieder Business Storys entstehen und nicht Epics oder User Storys. Und genauso wie das Runterbrechen von Epics und User Storys braucht auch das Runterbrechen von Business Storys Übung.
Wenn wir uns die oben beschriebe Business Story des Möbelherstellers ansehen, erkennen wir schnell, dass diese groß ist: Es braucht eine umfangreiche Webanwendung, mit der die Möbel konfiguriert werden können. Wir haben ein breites Sortiment und die Anpassungsmöglichkeiten für Regale unterscheiden sich deutlich von denen von Sofas (Abmessungen, Materialien etc.). Also müssen spezielle Konfiguratoren je Möbeltyp entwickelt werden. Möglicherweise braucht es eine 3D-Voransicht der konfigurierten Möbel, so dass die Kunden sich ein möglichst gutes Bild von dem machen können, was sie bestellen.
Um die neue Zielgruppe der Käufer von Maßanfertigungen anzusprechen, sind vielfältige Marktforschungs- und Marketingmaßnahmen notwendig.
Dazu kommen neue interne Prozesse. Die Produktion muss in der Lage sein, die Maßanfertigungen herzustellen, ohne dass dadurch die Produktion von Standardmöbeln Schaden nimmt. Und nicht zuletzt ist die Auskunft über das Lieferdatum deutlich komplizierter als bei den Standardmöbeln und hängt unter Anderem vom Ausmaß der Anpassung ab.
Viele Projekte neigen in so einem Kontext dazu, ein umfangreiches Product Backlog mit den notwendigen Epics und User Storys erstellen und diese in Sprints zu entwickeln. So könnte es mehrere Jahre dauern, bis die Business Story abgeschlossen ist. Wir können aber deutlich früher Wert schöpfen und damit Risiken minimieren, wenn es uns gelingt, die Business Story in mehrere kleinere Business Storys aufzuteilen. Wir haben in der Praxis wiederkehrende Muster identifiziert, die helfen, Business Storys kleiner zu schneiden (s. Abb. 3).
Es lohnt sich, die verschiedenen Muster nacheinander auszuprobieren, um Inspirationen zu generieren. Nicht jedes Muster führt in jedem Kontext dazu, dass die Business Story tatsächlich relevant kleiner wird.
Reduzierte Wirkung
Im o. g. Möbel-Beispiel hatten wir zwei Wirkungen für die Kunden und zwei für das Unternehmen identifiziert. Diese werden – zum Beispiel im Rahmen eines Business Cases – quantifiziert. So könnte z. B. für die Kundenwirkung herauskommen:
- Kunden können passende Möbel für Wohnung oder Haus maßanfertigen lassen.
- Kunden können sich individuelle Möbel nach ihrem Geschmack anfertigen lassen.
- Wir wollen, dass mind. 100.000 Kunden im Jahr von den neuen Konfigurationsmöglichkeiten Gebrauch machen.
Für die Unternehmenswirkung könnte herauskommen:
- Steigerung des Umsatzes mit Bestandskunden um mind. 10 Mio. Euro.
- Erschließung neuer Kundengruppen mit einem Umsatz von mind. 50 Mio. Euro.
Mit dem Muster "Reduzierte Wirkung" würde man die o. g. Wirkungen drastisch reduzieren, z. B.
- Wir wollen, dass mind. 100 Kunden im ersten Jahr von den neuen Konfigurationsmöglichkeiten Gebrauch machen.
- Steigerung des Umsatzes mit Bestandskunden um mind. 10.000 Euro
- Erschließung neuer Kundengruppen mit einem Umsatz von mind. 50.000 Euro
Für sich genommen wird der Business Case für die reduzierten Wirkungen vermutlich nicht wirtschaftlich sein, weil die Entwicklungsaufwände vermutlich über den Mehreinnahmen liegen. Die reduzierten Wirkungen führen aber vermutlich dazu, dass deutlich weniger Marketing mit deutlich geringerem Vorlauf notwendig ist. So können wir früher Feedback vom Markt bekommen, wie unsere Idee ankommt.
Einzelne Wirkungsdimensionen
Wir können die Business Story auch entlang der einzelnen Wirkungsdimensionen aufsplitten und hätten dann einzelne Business Storys wie diese hier:
- Konfiguration der Maße von Möbeln.
- Konfiguration von Stoffen und Farben der Möbel.
- Umsatzsteigerung mit Bestandskunden.
- Erschließung neuer Kundengruppen.
Vermutlich würde die Aufsplittung von 1 und 2 tatsächlich bereits zu deutlich kleineren Business Storys führen (sowohl was den Konfigurator im Web als auch was die Umstellung der Produktionsprozesse angeht). Die Aufsplittung von 3 und 4 dürfte für die Bereiche Marketing und Vertrieb einen erheblichen Unterschied machen. Für Business Story 3 muss man "nur" mit den existierenden Kunden in Kontakt treten. Für Business Story 4 muss man neue Zugangswege etablieren und die Marke erst bekannt machen.
Und natürlich kann man so entstandende einzelne Business Storys wieder kombinieren. Man könnte hier beispielsweise die Business Storys 1 und 3 zusammenfassen.
Fokus auf Unternehmenswirkung
Auf die Unternehmenswirkung zu fokussieren, ist im Grunde ein Spezialfall von "Einzelne Wirkungsdimensionen". Wir würden die Kundenwirkung erstmal hinten anstellen und eine neue Business Story nur mit der Unternehmenswirkung formulieren:
- Umsatzsteigerung mit Bestandskunden.
- Erschließung neuer Kundengruppen.
Das "Wie" kann dabei vollkommen anders aussehen als bisher gedacht. Vielleicht kann man beides nur durch Marketing erreichen und braucht gar keinen Möbelkonfigurator?
Fokus auf Kundenwirkung
Wie bei "Fokus auf Unternehmenswirkung" liegt auch hier ein Spezialfall von "Einzelne Wirkungsdimensionen" vor. Wir würden auf die Kundenwirkungen fokussieren und die Unternehmenswirkungen erstmal nach hinten stellen:
- Kunden können passende Möbel für Wohnung oder Haus maßanfertigen lassen.
- Kunden können sich individuelle Möbel nach ihrem Geschmack anfertigen lassen.
Da damit die Umsatzziele erstmal sekundär sind, würden weniger Kunden ausreichen, die diese Funktionen nutzen und man könnte auch überlegen, angepasste Möbel erstmal ohne Aufpreis anzubieten (um einen ruinösen Ansturm zu vermeiden könnte man dieses Angebot erstmal nur wenigen ausgewählten Kunden machen). Auf jeden Fall könnte man durch eine solche auf Kundenwirkung beschränkte Business Story zunächst auf Marketingaktionen verzichten.
Ergebnisse
Eine weitere Möglichkeit zum Schneiden von Business Storys liegt darin, sie entlang der Ergebnisse oder Ergebnistypen zu schneiden. Im Möbel-Beispiel könnten wir uns zunächst darauf beschränken, die Konfiguration nur für Regale anzubieten. Das würde nicht nur die Entwicklungsaufwände für den Web-Konfigurator deutlich reduzieren, sondern auch die notwendigen Anpassungen der Produktion.
Discovery Story
Manchmal führen alle beschriebenen Muster zum Aufsplitten von Business Storys nicht zum Erfolg. Dann kann man die Muster "Discovery Story" und "Walking Skeleton" in Betracht ziehen. Sie führen zu kleineren Vorhaben, die für sich aber keine Business Storys sind.
Bei der Discovery Story steht die Reduktion des Marktrisikos im Vordergrund. Es gibt größere Unsicherheiten darüber, ob die Kunden die angedachten Produkte/Features überhaupt wollen, ob sie bereit sind, dafür ausreichend Geld zu bezahlen oder wie genau diese Produkte gestaltet sein müssen. Dann können wir eine oder mehrere Discovery Storys aus der Business Story ableiten, um mehr über die Kundenbedürfnisse und den Markt zu erfahren. Meistens müssen wir dafür das eigentliche Produkt bzw. Softwaresystem noch gar nicht entwickeln. Stattdessen bringen uns Interviews, Beobachtungen, Prototypen etc. häufig schon ans Ziel.
In unserem Fall sind wir uns z. B. unsicher darüber, ob die Kunden bereit sind, den Mehrpreis für die Konfiguration zu bezahlen. Wir könnten das darüber prüfen, dass wir alle oder ausgewählte Kunden über eine E-Mail-Aktion über unser Vorhaben informieren und fragen, wer zu dem Thema für ein Gespräch bereit steht. In den Interviews könnten wir das generelle Interesse abfragen und ein Gefühl dafür entwickeln, wie hoch der Mehrpreis sein dürfte.
Walking Skeleton
Beim Walking Skeleton steht die Reduktion technischer Risiken im Fokus. Wir erstellen hier einen funktionsfähigen Durchstich durch die Software und/oder den Prozess und gewinnen so Sicherheit, dass die Einzelteile zusammen geeignet sind, um das Ziel zu erreichen. Das Fleisch wird dann später an das Skelett gehängt.
In unserem Möbel-Beispiel könnten wir auf der Webseite einen Button "Konfigurierte Möbel" anbieten (ggfs. nicht für alle, sondern nur ausgewählte Kunden). Wenn der Kunde darauf klickt, landet er auf einer Webseite mit den Kontaktdaten des Vertriebs. Tritt der Kunde mit dem Vertrieb in Kontakt, ermittelt dieser im Gespräch die Anpassungswünsche und sorgt dann dafür, dass das gewünschte Möbelstück produziert, geliefert und in Rechnung gestellt wird. Darüber würden wir die Sicherheit generieren, dass unser Unternehmen überhaupt in der Lage ist, konfigurierte Möbel anzubieten. Und dann kann der Prozess schrittweise automatisiert werden.
Kombination der Muster
Die vorgestellten Muster können natürlich kombiniert werden. Wir könnten uns entscheiden, zunächst auf Regale zu fokussieren (Muster "Ergebnisse"), diese neue Funktion nur den Bestandskunden anzubieten (Muster "Einzelne Wirkungsdimensionen") und diese erstmal als Walking Skeleton zu entwickeln.
Abgrenzung zu anderen Konzepten
Es gibt eine ganze Reihe von Konzepten, die Überschneidungen mit Business Storys haben. Die folgenden Abschnitte stellen Überschneidungen, Ähnlichkeiten und Unterschiede dar.
Produktvision
Insbesondere in Scrum ist es üblich, mit Produktvisionen zu arbeiten, obwohl der Scrum Guide dies nicht fordert. Produktvisionen fokussieren so wie Business Storys auf Wirkung. Im Gegensatz zu Business Storys sind Produktvisionen unkonkreter und deutlich größer. Produktvisionen sollen langfristig Orientierung geben (häufig: mehrere Jahre).
Business Storys sind also Produktvisionen untergeordnet und helfen dabei, bei der immer besseren Umsetzung der Produktvision Zwischenziele zu definieren und dabei den Wirkungsfokus beizubehalten.
Epics & User Storys
Epics (sehr große User Storys) haben eine ähnliche Granularität wie Business Storys. Epics fokussieren allerdings auf das Ergebnis/Produkt, Business Storys auf die Wirkung. Wer mit Business Storys arbeitet, braucht keine Epics mehr. User Storys haben wie Epics einen Ergebnis-/Produktfokus und eine deutlich kleinere Wirkung als Business Storys. Das führt dazu, dass User Storys häufig nicht einzeln an Kunden ausgeliefert werden können: Die User Story zum Anlegen neuer Artikel wird man erst ausliefern, wenn auch Storys zum Wiederfinden und Bearbeiten von Artikeln implementiert sind.
Produktziel
Die neueste Version des Scrum Guides [1] fordert ein Produktziel als Bestandteil des Product Backlogs. Der Scrum Guide definiert nicht genauer, wie das Produktziel aussehen soll. Business Storys eignen sich als Produktziel. Sie verbinden den Ergebnisfokus der Product-Backlog-Einträge mit der Wirkung, die erzielt werden sollen.
Sprintziel
Das Sprintziel ist als Konzept in Scrum lange bekannt, in der Praxis aber selten verwendet. In der neuesten Version des Scrum Guides ist das Sprintziel Bestandteil des Sprintbacklogs – äquivalent zum Produktziel im Product Backlog.
Wenn Business Storys klein geschnitten werden, können sie sich als Sprintziel eignen. Sprintziele, die so auf Wirkung fokussieren sind auf jeden Fall wirkungsvoller als solche, die auf Ergebnisse fokussieren. Allerdings braucht es viel Erfahrung, um Business Storys ausreichend klein zu schneiden und in einigen Kontexten wird es anspruchsvoller sein als in anderen. Mitunter werden also mehrere Sprintziele (und damit Sprints) eine Business Story umsetzen.
Roadmap
Häufig werden in der Praxis feature-orientierte Roadmaps verwendet: Ein Bündel von Produkteigenschaften wird unter eine Überschrift gebracht und mit einem Termin versehen. Featureorientierte Roadmaps vertragen sich schlecht mit agiler Vorgehensweise – sie erzeugen de facto eine festpreisartige Konstellation: ein vorab definierter Scope ist zu definierten Kosten zu einem festgelegten Termin zu liefern. Außerdem defokussieren sie, weil nicht mehr ein Ziel verfolgt wird, sondern ein Sammelsurium von Dingen umgesetzt werden soll.
Roman Pichler stellt den feature-orientierten Roadmaps die zielorientierten Roadmaps gegenüber [2], die jeweils Ziele im Sinne einer Wirkung in den Vordergrund stellen und die dazu notwendigen Features untergeordnet und sehr grobgranular betrachten. Man könnte hier auch von wirkungsorientierten Roadmaps sprechen. Diese harmonieren deutlich besser mit agilem Vorgehen als feature-orientierte Roadmaps. Im Grunde kann man ziel- bzw. wirkungsorientierte Roadmaps so verstehen, dass sie aus einer Sequenz von Business Storys bestehen, die mit einem Termin versehen sind. Dadurch, dass Business Storys die Ergebnisse allenfalls am Rande benennen, lassen wirkungsorientierte Roadmaps viel Flexibilität bei der Erreichung der Wirkung, so dass das iterative Vorgehen mit seinen Inspect-&-Adapt-Zyklen sein Potential ganz entfalten kann.
Objectives & Key Results (OKRs)
OKRs oder andere Varianten des Management by Objectives (MbO) haben eine vergleichbare Granularität wie Business Storys (s. auch Tabelle 1). OKRs werden z. B. jeweils für ein Quartal definiert. Allerdings werden diese Zielführungssysteme in der Praxis meist entlang der existierenden Hierarchie ausgeführt: Übergeordnete Ziele werden entlang der Hierarchie in Subziele aufgeteilt. Business Storys werden nicht an die existierenden Unternehmensstrukturen angepasst und erzwingen damit bereichsübergreifende Zusammenarbeit viel stärker als das z. B. bei OKRs in der Praxis der Fall ist. Desweiteren lassen sich mittels OKRs sowohl Wirkungs- als auch Ergebnisziele definieren. Business Storys fokussieren auf die Wirkung und beschreiben keine Ergebniszeile.
Je nach Kontext können Business Storys parallel zu OKRs eingesetzt werden oder diese ganz oder teilweise ersetzen.
Bezug zu anderen Konzepten
Tabelle 1: Gemeinsamkeiten und Unterschiede von Business Storys zu anderen Konzepten
| Business Story im Vergleich zu | Abgrenzung | Gemeinsamkeiten |
| Produktvision | Die Produktvision ist größer und unkonkreter als eine Business Story. Business Storys helfen, eine Produktvision umzusetzen, sind ihr also untergeordnet. | Produktvision und Business Storys fokussieren auf Wirkung, nicht Ergebnisse. |
| Epic | Epics fokussieren auf Ergebnisse, Business Storys auf Wirkung. Business Storys ersetzen Epics. | Vergleichbare Größe |
| User Story | User Storys fokussieren auf Ergebnisse und sind kleiner als Business Storys. Eine Business Story wird in der Regel durch eine Reihe von User Storys umgesetzt. Damit sind User Storys den Business Storys untergeordnet. | |
Produktziel (gefordert in der neuen Fassung des Scrum Guides als Teil des Product Backlogs) | Der Scrum Guide legt nicht fest, wie Produktziele im Detail aussehen. Business Storys sind klarer definiert. | Eine (große) Business-Story kann als Produktziel genutzt werden. |
| Sprintziel | Der Scrum Guide legt nicht fest, wie Sprintziele im Detail aussehen. Business Storys sind klarer definiert. | Mit etwas Übung können Business Storys so klein geschnitten werden, dass sie als Sprintziele genutzt werden können. |
| Roadmap | Die üblichen feature-orientierten Roadmaps fokussieren auf Ergebnisse nicht Wirkung. | Eine Sequenz von Business Storys bildet eine ziel-/wirkungsorientierte Roadmap. |
| OKR / MbO | Die Verfahren lassen Ergebnis- und Wirkungsziele zu. Business Storys lassen nur Wirkungsziele zu. OKR/MbO orientieren sich meist an der Unternehmenshierarchie. Business Storys tun das nicht und erzwingen damit bereichsübergreifende Zusammenarbeit. | Granularität ist ähnlich. Führen über Ziele ist OKR/MbO und Business Storys gemeinsam. |
Anwendung in der Praxis
Bei einem unserer Kunden (Online-Händler) ist die Performance der Webseite ein großes Thema. Die Mitarbeiter gehen davon aus, dass eine zu geringe Performance der Webseite dazu führt, dass viele Kunden den Bestellprozess frühzeitig abbrechen. Die allgemeine Annahme ist, dass eine Verbesserung der Performance zu weniger Abbrüchen im Bestellprozess führt und damit zu gesteigerten Umsätzen. Die Business-Story sah folgendermaßen aus:
Diese Business Story ist sehr groß und die Performance-Optimierung hätte hohe Investitionen in die Infrastruktur erfordert. Der Online-Händler entschied sich, die Business Story so zu schneiden, dass zunächst die Annahmen möglichst simpel und schnell überprüft werden konnten. Hierzu entwickelte ein Infrastruktur-Team die Idee, im ersten Schritt einige Monitoring-Tools temporär zu deaktivieren. Dadurch wurde die Webseite merklich schneller. Die daraus entstehende, kleinere Business Story sah im wesentlichen aus wie die ursprüngliche Business Story. Da sie nur auf eine kurzfristige Verbesserung der Performance abzielte, betraf sie nur das Infrastruktur-Team. Nach der grundlegenden Entscheidung zur Umsetzung waren keine weiteren Managemententscheidungen mehr notwendig und die Umsetzung konnte innerhalb eines Evaluationszyklus' erfolgen.
Im Rahmen der Evaluation hat der Online-Händler festgestellt, dass eine Erhöhung der Webseite-Performance keine Auswirkungen auf die Abbrüche im Bestellprozess, die Kundenzufriedenheit oder den Umsatz des Unternehmens hatte. So konnte der Online-Händler früh in der Umsetzung der Business Story umschwenken und sich auf andere potenzielle Ursachen für häufige Abbrüche im Bestellprozess konzentrieren. Investitionen in Infrastruktur sowie Arbeitszeit der Infrastruktur- und Entwicklungsteams konnten für wirkungsvollere Themen genutzt werden.
Zusammenfassung und Abschluss
Wenn wir weniger auf Ergebnisse und stärker auf Wirkung fokussieren, können wir schneller Wert für alle Interessengruppen schaffen. Wir können die unterschiedlichen Wirkungen auf die unterschiedlichen Personas als Vertreter der Interessengruppen gegeneinander abwägen und so eine fundierte Entscheidungsgrundlage für Priorisierung und Fokussierung schaffen.
Des Weiteren können wir prüfen, ob User Storys wirklich auf die Business Story einzahlen und somit dem Ideal näher kommen, nach jedem Sprint oder sogar noch schneller wertvolle Produkte zu liefern.
Business Storys helfen dabei, die Aufmerksamkeit der diversen Interessengruppen (Management, Product Owner, Stakeholder, Team, ...) auf Wirkung zu lenken und somit auch ein gemeinsames Verständnis für die diversen Interessen herzustellen. Ein gemeinsames Verständnis auch füreinander. Letzteres macht Diskussionen über Wert einfacher.
Business Storys können wie Epics und User Storys kleiner geschnitten werden und stellen damit ein nützliches Hilfsmittel dar, um früher mehr Wert zu schaffen.
Die hier vorgestellten Konzepte wurden von Laura Austermann, Frank Düsterbeck und Henning Wolf mit geprägt. Laura Austermann und Stefan Roock haben erste Ideen zu Business Storys in der Agile Review veröffentlicht [3].
- Der Scrum Guide
- Roman Pichler: Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting, 2016
- Laura Austermann, Stefan Roock: Business Storys - Bereichsübergreifender Fokus auf die Wirkung, Sonderausgabe Agile Review 2021
Weitere Informationen:
Das vorgestellte Business-Story-Template gibt es zum Download bei it-agile oder HEC.
