Kitabı oku: «Roadmap durch die VUCA-Welt», sayfa 7

Yazı tipi:

Diese Aufgaben werden dann in das Sprint BacklogSprint Backlog übertragen. Dieses stellt somit eine Teilmenge des Product Backlogs dar und wird jeden Sprint neu angelegt. Die Aufgaben im Sprint Backlog werden so verfeinert, dass das Team jederzeit überprüfen kann, wie sein Fortschritt in Hinblick auf die Erreichung des Sprintziels ist. Es werden nur so viele Aufgaben in das Sprint Backlog übernommen, wie das Team meint, im nächsten Sprint fertigstellen zu können.

Im Laufe des Sprints erstellt das Entwicklungsteam ein Inkrement. Ein Inkrement besteht aus dem Ergebnis des aktuellen Sprints sowie den Ergebnissen aller vorheriger Sprints. Ein Produkt Inkrement wird also von Sprint zu Sprint immer größer und umfangreicher.

Damit die Arbeit selbstorganisiert stattfindet und möglichst gut abgestimmt wird, trifft sich das Entwicklungsteam täglich zur selben Zeit am gleichen Ort für ein Planungs- und Abstimmungsmeeting, dem Daily Scrum. Das Daily Scrum findet in aller Regel im Stehen statt (daher auch der alternative Name Daily-Stand-Up). Dies soll dazu dienen, dass die Teilnehmer sich kurzfassen und schnell zum Wesentlichen kommen. Alle Scrum Events haben eine Timebox (Zeitrahmen), also eine maximale Dauer, die nicht überschritten werden darf. Das Daily Scrum soll maximal 15 Minuten dauern und ist somit das kürzeste Scrum Event. Hervorzuheben ist, dass das Daily Scrum nicht dazu gedacht ist, den aktuellen Status zu berichten. Das Team soll sich gezielt abstimmen, wo man im Hinblick auf das Sprint Ziel steht, was noch zu tun ist, was in den nächsten 24 Stunden (bis zum nächsten Daily Scrum) erledigt werden kann und wie man sich am sinnvollsten aufteilt. Zudem sollen Hindernisse (Impediments) sichtbar gemacht werden, die die Arbeit behindern oder sogar verhindern.

Damit eine Aufgabe vom Team als erledigt gekennzeichnet werden kann, muss sie der Definition von Fertig (Definition of Done) entsprechen. Diese Definition stellt eine Checkliste dar, die alles enthält, was erfüllt sein muss, damit eine Aufgabe fertiggestellt ist. Diese wird häufig von dem Unternehmen vorgegeben, damit alle Scrum Teams nach den gleichen Qualitätsstandards arbeiten. Wenn auch nur eine geringe Kleinigkeit fehlt, darf eine Aufgabe nicht als fertig deklariert werden.

Am Ende des Sprints präsentiert das Scrum Team allen Interessierten das fertige Inkrement (also alle Aufgaben, die gemäß der Definition von fertig abgeschlossen wurden). Dies geschieht im sogenannten Sprint Review, das eine öffentliche Veranstaltung ist und zu dem der Product Owner alle interessierten Stakeholder einlädt. Gemäß dem Leitsatz von Scrum – Inspect & Adapt (Feedback einholen und Anpassen) – wird hier das Produkt Inkrement gezeigt und Feedback eingesammelt. Auch das Review ist somit kein einfaches Statusmeeting, um einen Fortschritt zu präsentieren, sondern eine wichtige Gelegenheit, um Feedback einzuholen und strategische Entscheidungen zu treffen. Neue Erkenntnisse hält der Product Owner im Backlog fest, mit dem er dann in das nächste Sprint Planning gehen kann.

Im Anschluss erfolgt dann ein weiterer Schritt, der dazu dient, Feedback einzuholen und eventuelle Anpassungen vorzunehmen: die Sprint Retrospektive. Hier kommt das Scrum Team zusammen und reflektiert gemeinsam den Entwicklungsprozess mit dem Ziel, Verbesserungsmaßnahmen zu definieren, die im Laufe des nächsten Sprints angewendet und in der folgenden Retrospektive auf ihre Wirksamkeit hin untersucht werden können. Diese werden dann auch gleich in das Sprint Backlog des nächsten Sprints eingetragen, damit das Team bei der Planung diese Aufwände mitberücksichtigen kann.

Prinzipiell geht der Zyklus an dieser Stelle wieder von vorne los, allerdings zeigt die Erfahrung, dass das Team auch eine gewisse Zeit in die Pflege und die Verfeinerung des Product Backlogs investieren muss. Diese Aktivität wird als Refinement bezeichnet. Der Scrumguide macht hier, im Gegensatz zu den klar definierten Scrum Events, keine klaren Vorgaben, wie das Refinement abzulaufen hat. Aber er gibt eine Empfehlung, die darin besteht, dass das Team bis zu 10 % seiner Zeit im Sprint für Refinement aufwenden sollte. Das Ergebnis – ein gepflegtes und feingranulares Product Backlog – wird dann als Eingabe für das nächste Sprintplanning genutzt.

Auch in Scrum gibt es Metriken, die helfen sollen, den Prozess kontinuierlich zu verbessern. Allerdings schreibt Scrum hier nichts vor. Viele Praktiker messen zum Beispiel gerne die Menge der Arbeit, die das Entwicklungsteam in einem Sprint erledigt hat. Dies wird dann als Velocity bezeichnet. Dafür muss die Größe der Aufgaben berücksichtigt werden, so dass man entweder alle Aufgaben in die gleiche Größe bringt oder aber die Größe schätzen und in Relation zueinander setzen muss. Hierfür werden meist Story Points verwendet. Dementsprechend wird auch die Velocity eines Teams in der Regel in Story Points pro Sprint angegeben.

Scrum und Kanban erheben beide nicht den Anspruch perfekt zu sein und die Antwort auf alle Fragen zu liefern. Im Gegenteil, sie ermutigen die Anwender dazu, Anpassungen vorzunehmen, um die Vorgehensweisen zu verbessern. Dies ist sicherlich eine gute Idee, denn die Erfinder konnten nicht jeden erdenklichen Kontext in ihre Überlegungen einbeziehen.

Shu-Ha-Ri und Cargo-Kult

Ich erinnere mich noch recht gut an einen Lieblingsfilm meiner Kindheit. Ein schmächtiger, schwarzhaariger Junge steht vor einem Auto. Ihm gegenüber steht ein kleiner Japaner mit einem Schwamm in der Hand. „Auftragen rechte Hand, polieren linke Hand“, leitet der kleine Japaner ihn an. Dabei solle er das Atmen nicht vergessen, ergänzt der wunderliche alte Mann, dann macht er die Bewegung noch einmal vor. Er übergibt dem sparsam dreinschauenden Jungen den Schwamm und überlässt ihn dann seiner Aufgabe. Der Junge ist verdutzt, will er doch eigentlich Karate lernen und sein Lehrer, Mr. Miyagi, lässt ihn nun mit einer Aufgabe stehen, deren Sinn er nicht versteht. Diese Szene aus dem Film „Karate Kid“ ist ein schönes Beispiel für ein Prinzip namens Shu-Ha-RiShu-Ha-Ri. Dieses Konzept aus der Kunst des fernöstlichen Kampfsports ist auch bei der Einführung und Umsetzung von Arbeitsweisen und Methoden hilfreich.

Die erste Stufe ist Shu, was so viel heißt wie „erhalten“ oder „gehorchen“. In dieser Phase sollte das, was der Lehrmeister sagt, minutiös befolgt werden, auch wenn der Sinn sich noch nicht so ganz erschließt. Bei den meisten Dingen, die wir neu lernen, verstehen wir manche Zusammenhänge erst, wenn wir sie mechanisch angewendet haben. So wie Daniel Larusso, der etwas verwundert ist, aber seinem Lehrmeister vertraut und seine Aufgaben erfüllt. Damit trainiert er Bewegungsabläufe ein, und wird immer sicherer bei deren Ausführung.

Abb. 15:

Shu-Ha-Ri in Kanji geschrieben

Wenn die Regeln befolgt wurden und wirklich verinnerlicht sind, dann folgt die zweite Stufe. Ha heißt in etwa „frei werden“ oder „abweichen“. Hier werden die Abläufe angepasst auf die jeweilige Situation. Es wird experimentiert und neues ausprobiert. Nur, wenn vorher die Regeln ganz genau befolgt wurden und verstanden wurden, ist das Verständnis da, warum manche Abweichungen funktionieren und manche eher nicht. Im Film ist Daniel schließlich in der Lage, die gelernten Bewegungsabläufe auch in einem Karate-Umfeld anzuwenden. Hier erscheint er erst noch überrascht, dass die Bewegungen fast von allein fließen. Da er aber aus den grundlegenden Übungen weiß, was ein positives Resultat und was ein negatives Resultat ist, kann er auch einschätzen, ob die kleinen Abwandlungen, die er vornimmt, hilfreich oder eher hinderlich sind.

Die dritte und höchste Stufe ist schließlich Ri. Übersetzt steht dies für „trennen“ oder „abschneiden“. Dies ist die Stufe der Meisterschaft. Die Prinzipien hinter den Regeln sind in Fleisch und Blut übergegangen und das Variieren, Anpassen und Entwickeln neuer Regeln stellt für den Meister keine Hürde mehr dar. Mister Miyagi ist in der Lage, die Elemente des Karate ganz einfach in Übungen zu übersetzen, die er seinem Schüler Daniel aufgibt. Als Meister ist er in der Lage einzuschätzen, dass auch das Polieren des Autos Daniel helfen wird, ein besserer Karatekämpfer zu werden. Er hat seinen eigenen Stil entwickelt, der seiner Persönlichkeit und seiner Individualität entspricht. Den Weg dorthin muss Daniel erst noch gehen, aber vielleicht wird er eines Tages auch selbst ein Meister sein. Dann wird er sich wahrscheinlich losgelöst haben von der Technik des Mister Miyagi und seinen ehemaligen Meister vielleicht sogar überflügeln. Dies ist ihm aber nur möglich, wenn er die vorherigen Stufen erfolgreich gemeistert hat.

Die beiden Autoren des Scrumguides Ken SchwaberSchwaber, Ken und Jeff SutherlandSutherland, Jeff haben schon in den ersten Sätzen darauf hingewiesen, dass Scrum ein einfach zu verstehendes, aber schwierig zu meisterndes Rahmenwerk darstellt. Befolgt man die Regeln, die im Scrumguide festgelegt sind, so stehen die Chancen gut, dass Scrum funktioniert. Erst wenn die Elemente verstanden wurden, macht die Anpassung Sinn. Oftmals tendieren unerfahrene Anwender dazu, die Regeln aufzuweichen, wenn sie „weh tun“. Zum Beispiel, wenn Aufgaben innerhalb eines Sprints nicht fertiggestellt werden können oder wenn jeder im Team ein Spezialgebiet hat, für das er allein verantwortlich ist. Gleiche Gefahr gilt bei Kanban, wo sehr schnell das WIP-Limit bei unerfahrenen Anwendern in Frage gestellt und aufgeweicht wird.

Begibt man sich einmal in die – sehr aktive – agile Community, die in so gut wie jeder größeren deutschen Stadt vertreten ist, und hört man den Teilnehmern an den Diskussionen aufmerksam zu, so wird man viel Frustration bemerken. Vieles rührt von einer nicht sachgemäßen Anwendung der Frameworks her. Dann wird gerne vom sogenannten Cargo-Cult gesprochen.

Ursprünglich war der Cargo-Kult eine Bewegung aus dem Bereich der Fidschi-Inseln und Neuguinea. Hier trafen im zweiten Weltkrieg die Inseleinwohner, die zuvor sehr abgeschieden lebten, auf die US-Armee, die die Inseln als Basis nutzten. Sie errichteten provisorische Flughäfen und Landebahnen und warfen auch Lebensmittel und westliche Kleidung über der Insel ab. Die Einwohner beobachteten die merkwürdigen Fremden und sahen, dass sie auf komische Türme stiegen und so etwas wie Schalen auf den Ohren hatten. Sie winkten mit Stäben und ab und zu fielen von den Göttern gesandte Pakete vom Himmel oder große, stählerne Wesen kamen aus der Luft und aus ihren Mäulern kamen mehr Menschen und Lebensmittel.

Als die Amerikaner irgendwann die Insel verließen, wollten die Einwohner nicht auf den Reichtum aus der Luft verzichten. Um die Götter zur Rückkehr zu bewegen, bauten die Einwohner die Einrichtungen der Amerikaner nach, setzten sich Kopfhörern nachempfundene Konstruktionen auf den Kopf und winkten mit Stäben in den Himmel. Aber kein Paket segelte auf die Insel hinab und kein großes Wesen landete mehr auf den Inseln. Die Einwohner konnten das nicht verstehen, sie taten doch alles genauso, wie die merkwürdigen Fremden es zuvor auch getan hatten.

Der große Unterschied bestand darin, dass sie nicht verstanden, warum es funktionierte, wenn die Amerikaner in den Himmel winkten. Gleiches Risiko besteht auch bei der Anwendung von Methoden, deren Wirkweise man (noch) nicht durchschaut hat.

Häufig liegt die Ursache darin, dass unterschätzt wird, dass die Verwendung agiler Methoden auch Veränderung auf allen Ebenen mit sich bringt. Folglich werden dann zu Beginn nur auf Teamebene Methoden etabliert, die schnell auf organisatorische Grenzen stoßen. Werden diese Grenzen nicht durchbrochen, dann führt dies zu Frust und Resignation. Nicht selten endet das dann darin, dass die agilen Methoden wieder abgeschafft werden. Dies ist aber auf Dauer keine Lösung, weil die VUCA-Welt nach Agilität verlangt. Die Bereitschaft zur Veränderung und die Fähigkeit zu verändern, stellt eine wichtige Kompetenz dar.

➤ Tipps für VUCA-Helden

Agilität stellt eine wichtige Kompetenz des 21. Jahrhunderts dar. Die Anforderungen, die von der Umwelt an uns als Individuum, aber auch an Unternehmen und an die Gesellschaft gestellt werden, erfordern die Fähigkeit, mit Komplexität umzugehen und anpassungsfähig und innovativ zu sein.

1 Verstehen Sie die Ursprünge und Hintergründe von agilen Ansätzen.

Machen Sie sich bewusst, dass Agilität immer schon hilfreich war. Lernen Sie aus der Geschichte und beschäftigen Sie sich mit den ersten Ansätzen und den Kontexten, in denen diese entstanden sind.

Machen Sie sich auch klar, dass hier Entweder-Oder-Denken nicht hilfreich ist. Auch in einem (oftmals als sehr unagil bezeichnetem) Wasserfallmodell können agile Elemente untergebracht werden.

Wo sehen Sie in Ihrem Umfeld Denkweisen, die Sie als „agil“ bezeichnen würden?

Was ist Ihre eigene Definition von agil? Was wäre „unagil“?

In welchem Kontext wurde eine gewisse Methode erstmals angewendet und warum hat sie dort geholfen?

1 Seien Sie kein Dogmatiker.

Der Grundsatz aller agilen Arbeitsweisen lautet „Inspect & Adapt“, also Feedback gewinnen und daraus Anpassungen ableiten. Schauen Sie sich Vorgehensweisen, Prozesse und Produkte kritisch an und nehmen Sie Anpassungen vor. Es mutet merkwürdig an, wenn Frameworks und „agile Gesinnungen“ dogmatisch vertreten werden. Eine Praktik oder Methodik sollte immer zum jeweiligen Kontext passen.

Warum sind Sie der Meinung, dass eine bestimmte Praktik, Methode oder Verhaltensweise genutzt werden sollte? Haben Sie eine zum Kontext passende Erklärung?

Haben Sie die Leitplanken und Regeln durchschaut, so dass Sie sich auf die dahinterliegenden Prinzipien und Werte beziehen können?

Passen die Werte und Prinzipien zu Ihren eigenen Werten (den Werten Ihres Unternehmens, Ihres Auftraggebers, Ihres Kunden, …)?

1 Nutzen Sie die Erfahrung von „Meistern“ bei der Einführung von neuen Methoden und Frameworks.

Gerade bei der Einführung von Frameworks, die das Potenzial haben, ganze Unternehmensstrukturen und Führungsparadigmen zu hinterfragen und die Kultur zu verändern, sollten Sie sicherstellen, dass Sie Menschen mit Erfahrung in diesem Bereich an Bord haben. Erinnern Sie sich an Shu-Ha-Ri. Wenn Sie selbst in Ihrem Umfeld niemanden haben, der mindestens auf dem Ha-Level ist, dann suchen Sie sich Unterstützung.

Nicht wenige agile Transformationen scheitern daran, dass sie halbherzig oder mit guten Absichten (aber schlechter Umsetzung) durchgeführt werden. Die Resultate sind dann häufig zerstörtes Vertrauen beim Management, frustrierte Mitarbeiter, Rückkehr zu alten Prozessen und Arbeitsweisen und Verlust von Mitarbeitern, die einen Einblick in eine neue Arbeitswelt bekommen haben, die sie fortan woanders suchen.

Suchen Sie sich erfahrene Coaches, Berater oder Unterstützer, die bei der Einführung von agilen Frameworks unterstützen. Wer kann Ihr „Mister Miyagi“ sein?

Bauen Sie eigene Kenntnisse auf und vernetzen Sie sich, so dass Sie selbst zukünftig in der Lage sind, Anpassungen vorzunehmen (Ha-Level).

Haben Sie die Wirkweise wirklich verstanden?

Der Kundennutzen steht im Mittelpunkt

Unternehmen müssen heute in einen Konkurrenzkampf um die Kunden treten. Die effiziente und kostengünstige Produktion selbst ist kein Erfolgsgarant mehr, denn die Technik und das Wissen, wie man beispielsweise ein Smartphone oder Tablet kostengünstig herstellt, sind keine Raketenwissenschaft. Die Preise und damit die Gewinnspanne für etablierte Produkte sinken. Die Kunden wollen nicht einen weiteren Klon eines schon vorhandenen Produkts, sondern sie erwarten Innovationen und Alleinstellungsmerkmale.

Dies gilt für fast alle Branchen und Produkte. In der Digitalisierung verlagert sich der Fokus der Produktentwicklung in Richtung Kunde. Diese sind oft schon sehr früh beim Produktdesign mit im Boot. Der kreative und innovative Umgang mit Kunden und deren Wünschen ist eine wichtige Kompetenz geworden.

Zur Verdeutlichung möchte ich an dieser Stelle eine Geschichte nacherzählen, die für mich die Kundenzentrierung auf den Punkt bringt. Sie zeigt sehr anschaulich, worauf es auch in Zeiten der Digitalisierung ankommt. Diese Geschichte stammt von Reinhard Sprenger (Sprenger 2018) und stammt mitten aus dem Alltagsleben, ohne viel Technik oder neuartige Apps.

Stellen Sie sich eine Familie vor, die an einem schönen Samstagabend in ein Restaurant zum Essen geht. Die Familie besteht aus Vater, Mutter und zwei Kindern. Alle sind gut gelaunt und es verspricht ein schöner Abend zu werden. Beim Blick auf die Speisekarte kündigt sich aber ein Problem an. Die Kinder finden nichts, was ihnen zusagen würde. Auf der Karte sind auch keine Pommes Frites zu entdecken. Als der Kellner an den Tisch der Familie kommt, fragt die Mutter nach, ob es denn möglich wäre, für die Kinder eine Portion Pommes Frites zu bestellen und der Kellner nickt freundlich und notiert den Wunsch auf seinem Notizblock. Der Abend ist gerettet und alle lassen sich ihr Essen schmecken. Als schließlich die Rechnung kommt und der Vater sie kontrolliert, bemerkt er, dass die Pommes Frites nirgendwo aufgeführt sind. Er weist den Kellner darauf hin und bekommt dann eine verwunderliche Erklärung, warum die Pommes Frites fehlten. „Oh, da haben Sie Recht“, räumt der Kellner ein. „Das liegt wohl daran, dass wir sie vom Restaurant auf der anderen Straßenseite geholt haben und dann vergessen haben, sie auf Ihre Rechnung zu setzen“.

Hier ist wahrlich der Kunde König und in den Mittelpunkt gestellt worden. Das Restaurant hat sich bemüht, einem Wunsch zu entsprechen, der über die standardmäßig angebotenen Leistungen hinausging. Dadurch gingen sowohl das Restaurant als auch die Gäste als Gewinner hervor. Und es zeigt auch gleich, dass Vernetzung und Zusammenarbeit eine wichtige Komponente in der Digitalisierung darstellen. Das Restaurant hat nicht nur nach innen geschaut und das geliefert, was es aufgrund der Produktionsmittel liefern konnte. Da es den Kundenwunsch nicht allein erfüllen konnte, hat es nach einer Kollaboration gesucht und sie im Restaurant gegenüber gefunden. Stellen Sie sich vor, was dies für ein Paradigmenwechsel für viele Unternehmen darstellen muss.

User Stories und Story Mapping

In vielen agilen Teams und Unternehmen verwendet man User StoriesUser Stories, um Anforderungen aus Kundensicht zu beschreiben. Das klassische Anforderungsmanagement versucht, klare Beschreibungen mit möglichst vielen Details vom Kunden zu bekommen. Diese werden dann in Lasten- und Pflichtenheften vertraglich festgelegt. Im Gegensatz zu klassischem Anforderungsmanagement ist im agilen Umfeld zu erkennen, dass die Anforderungen erst einmal technisch sehr unspezifisch formuliert werden. Dafür wird aber stets die Perspektive des Kunden eingenommen und die technische Lösung später gemeinsam entwickelt.

Ron JeffriesJeffries, Ron, einer der drei Väter des Extreme Programming, schlug schon 2001 den sehr populären 3C-Ansatz vor. Diese drei C stehen für Card, Conversation und Confirmation.

Card (Karte) soll daran erinnern, dass eine User Story auf eine kleine Karteikarte passen soll. Es soll eben bewusst nicht zu viel analysiert und spezifiziert sein. Details und konkrete Lösungswege sollen in einer Zusammenarbeit des Teams entstehen. Dafür steht das zweite C, Conversation (Konversation, Gespräch). Hier kommt das Team zusammen und spricht über die User Story, nimmt sie auseinander, schneidet sie kleiner, bringt neue Ideen ein. Schließlich kommt es zum dritten C, der Confirmation (Bestätigung). Hier wird noch einmal sichergestellt, dass die Ziele der Konversation auch erreicht wurden, also ein Verständnis für das Problem und mögliche Lösungsansätze vorhanden sind. Hier werden oftmals Akzeptanzkriterien auf die Rückseite der Karte geschrieben. Diese dienen dazu, sich schon vor Beginn der Umsetzung Gedanken zu machen, was genau das fertige Produkt leisten muss, damit es die User Story erfüllt.

Eine User Story ist bei ihrer Formulierung aus Sicht des Kunden beschrieben und liefert Antworten auf die folgenden Fragen:

Wer möchte etwas? (Rolle)

Was wird benötigt? (Funktionalität)

Wozu wird es benötigt? Welches Ziel soll erreicht werden oder welches Problem gelöst werden? (Wozu)

Zwar gibt es keine Vorgabe, wie eine User Story zu formulieren ist, allerdings hat sich unter Anwendern das Connextra-Muster etabliert, das User Stories in der folgenden Form vorschlägt:

Als <Rolle> möchte ich <Funktionalität/Ziel/Wunsch>, um <Nutzen/Warum>.

Im klassischen Anforderungsmanagement wird oftmals der Grund, warum etwas benötigt wird, nicht mittransportiert. Es entsteht eine sehr starke Fokussierung auf die konkreten und spezifizierten Anforderungen und bei der Lieferung der Lösung merkt man erst, dass das Problem nicht ganzheitlich verstanden wurde. User Stories helfen durch die Art ihrer Formulierung dabei, erst das Problem zu verstehen und erst dann gemeinsam nach Lösungen zu suchen.

Damit User Stories in einer Iteration von maximal vier Wochen auch erledigt werden können, müssen sie oftmals in kleinere Pakete unterteilt werden. Dafür gibt es eine ganze Reihe von hilfreichen Techniken. Ein Hilfsmittel zum sinnvollen Zerteilen der Stories ist die User Story Map, die durch Jeff Patton populär wurde (Patton/Economy 2015).

Beim sogenannten User Story Mapping arbeitet wieder das ganze Team zusammen. Ziel ist es, eine grobe Story (oft auch Epic genannt) zu verfeinern und in einer Art Landkarte darzustellen, die zum einen Teilaspekte sichtbar macht, zum anderen aber auch mögliche Versionen des Produkts, die man nacheinander veröffentlichen könnte.

An einem Beispiel von Jeff Patton können Sie sehr schön sehen, wie eine User Story Map aufgebaut wird und wie man damit arbeiten kann. Unsere kleine Abwandlung dieses Beispiels lautet: „Als VUCA-Held möchte ich mein Haus verlassen, damit ich zu meiner Arbeit gehen kann“. Dies stellt Ihr Epic dar. Jetzt dürfen alle Teammitglieder auf Karten notieren, welche Tätigkeiten ihrer Meinung nach durchgeführt werden müssten, um die Wohnung morgens zu verlassen. Diese können auch gleich als User Story formuliert werden. Im Anschluss schauen Sie sich an, welche User Stories entstanden sind und ob sich hier grobe Kategorien bilden lassen. Sie könnten zum Beispiel Stories zusammenfassen, die sich mit Kaffeekochen, Frühstücken oder Pausenbrote schmieren befassen. Dies könnte eine Kategorie „Verpflegung“ sein. Der morgendliche Ablauf könnte beispielhaft aus „Aufstehen“, „Hygiene“, „Verpflegung“, „Packen“ und „Verlassen“ bestehen. Dies stellt einen groben Ablauf dar und wird von Patton als „Backbone“ bezeichnet. Sozusagen ein Grundgerüst, dem sich die konkreten Stories zuordnen lassen.

Schauen Sie sich nun einmal die User Stories an, die vom Team zusammengetragen wurden. „Als Ehemann schalte ich den Wecker aus, damit meine Frau noch ein wenig weiterschlafen kann“, könnte eine mögliche Story sein. Ein anderes Teammitglied könnte eine Story hinzufügen, die in etwa so aussieht: „Als Hundebesitzer gehe ich eine schnelle Runde Gassi mit meinem Hund, damit dieser es aushält, bis ich wieder nach Hause komme“. An dieser Stelle können Sie sehen, dass es unterschiedliche Zielgruppen für das zu entwerfende Produkt geben kann. Das hilft dabei zu überlegen, ob eine erste Version des Produktes vielleicht nicht erst für die wichtigste Zielgruppe erstellt werden sollte.

Ein wichtiger Aspekt im agilen Umfeld ist das schnelle Gewinnen von Feedback. Dafür ist es hilfreich, sich zu überlegen, was minimal vorhanden sein müsste, damit man ein erstes Feedback von Anwendern bekommen könnte. Dafür überlegen Sie sich einen minimalen Anwendungsfall, der für sich genommen schon einen Mehrwert bringt. Stellen Sie sich vor, Sie bekommen nun die Information, dass Sie verschlafen haben. Aber es ist ein ganz besonderer Tag, denn in fünf Minuten kommt ein Taxi, das Sie abholen und zum Flughafen bringen soll. Sie haben einen wichtigen Termin mit einem Kunden, den Sie auf keinen Fall verpassen dürfen. Welche der User Stories aus unserem Beispiel ist nun noch von Belang, damit Sie das Haus innerhalb von fünf Minuten verlassen können? In einer solchen Situation wird wahrscheinlich ein Großteil der Stories unwichtig erscheinen.

Diese minimale Variante der User Story wird MVP (minimum viable product), das minimal funktionsfähige Produkt, genannt. Patton sieht das MVP als den minimalen Stand an, zu dem man sich schnellstmöglich Feedback einholen kann. Das heißt nicht, dass man hier auch schon ein zu kommerzialisierendes Produkt hat. Dieser Schritt folgt erst darauf.

Für eine erste Produktversion bietet es sich an, zu überlegen, für welche Zielgruppe diese erstellt werden sollte. Eine gängige Praxis dafür ist die Verwendung sogenannter Persona.

Eine Persona ist ein fiktiver Benutzer des Produkts, der ein bestimmtes Bedürfnis und einen definierten Hintergrund hat. In der Tabelle finden Sie drei mögliche Persona als Beispiele, die in der beschriebenen StorymapStorymap eine Rolle spielen könnten. Für kreative Teams ist es oftmals hilfreich, sich mit einem bestimmten Anwendertyp etwas besser identifizieren zu können, um aus seiner Sicht das Problem bestmöglich zu lösen.

Im weiteren Verlauf fügen Sie, angepasst an die Zielgruppe, die Stories hinzu, die für eine erste Version in Frage kommen. Auf diese Art und Weise sind Sie nun in der Lage, eine Roadmap zu erstellen und verschiedene Produktveröffentlichungen zu planen. Wie eine solche User Story Map am Whiteboard aussehen könnte, sehen Sie in Abbildung 16.

Persona	Beschreibung	Bedürfnis	Kontext
Lisa	Lisa schläft gerne lange, frühstückt ausführlich und kümmert sich morgens um ihre beiden Katzen Bijou und Felix.	stressfreier Morgen, mit reichhaltigem Frühstück und Zeit für die Katzen	Lisa lebt mit ihrem Mann zusammen, der immer nach ihr das Haus verlässt.
Hans	Hans steht früh auf und frühstückt nie. Er liebt seine Arbeit und verbringt gerne seine Zeit dort.	schnell und gepflegt aus dem Haus zur Arbeit gelangen	Hans lebt allein und hat auch keine Haustiere. Er ist ein Karrieremensch.
Peter	Peter ist alleinerziehender Vater, der seine zwei Kinder morgens aufweckt und ihnen Frühstück macht. Er verlässt das Haus gemeinsam mit ihnen und setzt sie auf dem Weg zur Arbeit in der Schule ab.	glückliche Kinder	Peter hat die Verantwortung für seine beiden Kinder. Die Schule der beiden liegt auf seinem Arbeitsweg.