User Story Mapping E-Book

Jeff Patton

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch

Seitenzahl: 430

Veröffentlichungsjahr: 2015

Beschreibung

"User Story Mapping" ist in den USA längst ein Bestseller. Die von Jeff Patton entwickelte Methode knüpft an bewährte Ansätze aus der Agilen Entwicklung an und erweitert sie. Die Idee: Die Produktentwicklung wird detailliert am Arbeitsfluss der Nutzer ausgerichtet und in Story Maps kontinuierlich dokumentiert und illustriert. Dadurch entsteht im gesamten Team - bei Entwicklern, Designern und beim Auftraggeber - ein deutlich verbessertes gemeinsames Verständnis vom Gesamtprozess und vom zu entwickelnden Produkt. Gleichzeitig wird die Gefahr reduziert, sich in unwichtigen Details zu verzetteln oder gar ein Gesamtprodukt zu entwickeln, das dem Nutzer nicht hilft.

Leseprobe

User Story Mapping

JeffPatton

PeterEconomy

PetraHildebrandt

User Story Mapping

Inhaltsverzeichnis

WidmungVorwortVorwort von Martin FowlerVorwort von Alan CooperVorwort von Marty CaganÜber dieses BuchWieso ich?Wenn du Schwierigkeiten mit Stories hast, ist dieses Buch für genau DichWer sollte dieses Buch lesen?Ein paar Konventionen in diesem BuchDie Überschriften in den einzelnen Kapiteln weisen euch den Weg durch das Thema.Wie dieses Buch aufgebaut istStory Mapping aus 3.000 Metern HöheUser Stories verinnerlichenBessere BacklogsBessere BuildsHier geht's losStille PostGemeinsames Verständnis ist erschreckend einfach zu erreichenVergesst perfekte DokumentationGute Dokumente sind wie UrlaubsfotosDokumentiert, um euch zu erinnernÜber das Richtige redenJetzt und späterEs geht nicht um SoftwareOkay, es geht nicht nur um MenschenProduziert wenigerA wie AnforderungskatalogDas ist alles1. Das große GanzeDas Wort mit »A«Stories erzählen, nicht Geschichten schreibenDie ganze Geschichte erzählenGary und die Tragödie des flachen BacklogsTalk and DocUmreißt eure IdeeBeschreibt eure Kunden und UserErzähl die Stories deiner UserDetails und Möglichkeiten erforschen2. Planen, (um) weniger zu produzierenMapping hilft großen Gruppen, gemeinsames Verständnis herzustellen.Mapping hilft euch, die Löcher in eurer Geschichte zu entdeckenEs ist immer zu viel (zu tun)Definiert das Minimum für ein Minimum Viable Product ReleaseDefiniert eine Release RoadmapPriorisiert Outcomes, nicht FeaturesEs ist Magie – wirklich.Die Sache mit dem MVPDas neue MVP ist gar kein Produkt!3. Planen, (um) schneller zu lernenDiskutiert die ChancenValidiert das ProblemBenutzt Prototypen, um etwas zu lernenWas User WollenLernt aus euren BuildsIteriert bis zum MVPWie man es falsch machtValidiertes LernenMinimiert eure Experimente. Wirklich.Zusammenfassung4. Planen, (um) rechtzeitig fertig zu werdenRedet mit dem TeamDie Kunst des gekonnten SchätzensPlant, Stück für Stück zu produzierenMacht nicht aus jedem Slice ein ReleaseDas andere Geheminis gekonnter SchätzungenManagt euer BudgetWas würde da Vinci tun?Iterativ UND inkrementellStrategien: Eröffnungs-, Mittel- und EndspielMarkiert eure Entwicklungsstrategie in einer Map.Es geht um das Risiko.Wie geht es weiter?5. Ihr wisst schon, wie es geht1. Schreibt eure Story auf – einen Schritt nach dem anderenTasks: das, was wir tunMeine Tasks sind nicht Eure Tasks.Ich bin nur ein bisschen detailverliebter2. Organisiert eure StoryFehlende Details ergänzen3. Entdeckt alternative StoriesBleibt im Fluss4. Komprimiert die Map und erzeugt einen Backbone5. Gruppiert Tasks, die euch helfen, einen bestimmten Outcome zu erzielenFertig! Ihr habt alle wichtigen Konzepte gelernt!Do Try This at Home (oder bei der Arbeit)Die Map dreht sich ums Jetzt, nicht ums SpäterProbiert es wirklich ausMit Software ist es schwierigerDie Map ist nur der Anfang6. Die wahre Geschichte der StoriesKents verstörend einfache IdeeEinfach ist nicht leichtRon Jeffries und die 3 Cs1. Karte (Card)2. Konversation (Conversation)3. Bestätigung (Confirmation)Worte und BilderDas war's schon.7. Bessere Stories erzählenConnextras Tolles TemplateTemplate-Zombies und der SchneepflugCheckliste: Worüber ihr euch wirklich unterhalten solltetMacht UrlaubsfotosDas ist eine Menge Zeug8. Nicht alles steht auf der KarteUnterschiedliche Leute, unterschiedliche KonversationenWir brauchen eine größere KarteikarteStrahler und KühltruhenDafür ist das Werkzeug nicht gedachtGemeinsames Verständnis herstellenErinnernTracking9. Die Karteikarte ist nur der AnfangHabt eine klare Vorstellung davon, was ihr konstruiertEntwickelt eine mündliche Tradition des GeschichtenerzählensInspiziert das Ergebnis eurer ArbeitEs geht nicht um EuchEntwickelt, um zu lernen.Es ist nicht immer SoftwarePlant, zu lernen, und lernt, zu planen10. Wir backen uns eine StoryEin Rezept kreierenDen großen Kuchen aufteilen11. Steine brechenAuf die Größe kommt es immer anStories sind wie SteineEpen sind große Steine, die manchmal benutzt werden, um Menschen damit zu schlagenThemen organisieren Story-GruppenVergesst diese Begriffe und konzentriert euch darauf, Stories zu erzählenBeginnt mit Chancen (Opportunities)Entdeckt eine Minimum Viable SolutionVertieft euch in die Details jeder einzelnen Story im Delivery-ProzessRedet weiter, während ihr produziertEvaluiert jedes StückEvaluiert mit Usern und KundenEvaluiert mit Business-StakeholdernEvaluiert auch nach dem Release weiter12. SteinebrecherWertvoll – benutzbar – realisierbarEin Discovery-Team benötigt für den Erfolg viele andere PersonenDie drei AmigosProdukt-Owner als ProduzentenEs ist kompliziert13. Beginnt mit ChancenFührt Konversationen über ChancenTiefer graben, wegwerfen oder darüber nachdenkenChance sollte kein Euphemismus seinStory Mapping und Chancen (Opportunities)Seid wählerisch14. Mit Discovery gemeinsames Verständnis aufbauenBei Discovery geht es nicht um das Schreiben von SoftwareVier essenzielle Schritte der Discovery1. Umreißt die Idee (Framing)2. Versteht eure Kunden und UserSkizziert einfache PersonasLegt Organisationsprofile an – OrgzonasMappt, wie die User heute arbeiten3. Stellt euch eure Lösung vorMappt eure LösungWorte und BilderValidiert VollständigkeitValidiert technische BedenkenSpielt »Was-ist«Feiert noch nicht4. Minimieren und PlanenEs ist immer zu vielDas Geheimnis der PriorisierungDiscovery-Aktivitäten, Diskussionen und ArtefakteDiscovery dient der Herstellung von gemeinsamem Verständnis.15. User-Discovery für validiertes LernenWir liegen meistens falschDie schlechte alte ZeitEinfühlen, Fokussieren, Ideen Sammeln, Prototypen Bauen, TestenWie man etwas Gutes versautKurze Zyklen validierten LernensWie Lean Startup Thinking das Produktdesign verändertBeginnt mit RatenBenennt eure riskanten AnnahmenDesignt und erstellt einen kleinen TestMesst, indem ihr euren Test mit Kunden und Usern machtÜberdenkt eure Lösung und eure AnnahmenStories und Story Maps?16. Verfeinern, Definieren, ProduzierenKarteikarten, Konversationen, mehr Karten, noch mehr Konversationen ...Schneiden und PolierenDer Story-WorkshopSprint- oder Iterationsplanung?Menschenmengen kollaborieren nichtAufteilen und AusdünnenBenutzt eure Story Map während der DeliveryBenutzt eine Map, um Fortschritte zu visualisierenBenutzt einfache Story Maps in Story-Workshops17. Stories sind genau genommen wie AsteroidenZerbrochene Steine wieder zusammenfügenÜbertreibt es nicht mit dem MappingZerbrecht euch nicht den Kopf über Kleinkram18. Lernt aus jedem BuildReview im TeamReview mit anderen aus eurem UnternehmenGenugLernt von UsernLernt aus euren ReleasesOutcomes nach ZeitplanBenutzt eine Map, um zu evaluieren, ob ihr bereit für den Release seidDas Ende. Oder?DanksagungLiteraturStichwortverzeichnisKolophonCopyright

Widmung

Für Stacy, Grace und Zoe, meine größten Unterstützerinnen, die all meinen Mühen einen Sinn geben.

Und im Angedenken an Luke Barrett, einen geschätzten Kollegen und Mentor. Er hat mein Leben verändert, so wie das ungezählter anderer.

Vorwort

Vorwort von Martin Fowler

Zu den positiven Auswirkungen des Aufstiegs der agilen Softwareentwicklung gehört die Verbreitung des Konzepts, eine große Menge Anforderungen in kleinere Stücke aufzuteilen. Diese Stücke – Stories – erlauben viel bessere Einblicke in den Fortschritt eines Entwicklungsprojektes. Wenn ein Produkt Story für Story entsteht und jede Implementation einer Story vollständig in das Softwareprodukt integriert ist, kann jeder sehen, wie das Produkt wächst. Dadurch, dass sie Stories verwenden, die aus Usersicht Sinn ergeben, können Entwickler ihr Projekt steuern, indem sie festlegen, welche Stories sie als Nächstes bearbeiten werden. Die bessere Sichtbarkeit fördert eine stärkere Mitwirkung von Userseite – Sie müssen nicht mehr ein Jahr oder länger darauf warten, dass Sie sehen können, was das Entwicklerteam so getrieben hat.

Die Zerstückelung hat aber auch negative Konsequenzen. Dazu gehört, dass man schnell den Überblick darüber verlieren kann, was die Software als Ganzes tun soll. Man kann ein Durcheinander an Stücken herausbekommen, die nicht in ein zusammenhängendes Ganzes passen. Oder man baut ein System, das den Usern nicht wirklich etwas nutzt, weil einem zwischen all den Details der Sinn für das, was im Kern benötigt wird, abhanden gekommen ist.

Story Mapping ist eine Methode, mit der der Gesamtzusammenhang hergestellt werden kann, den ein bloßer Haufen von Stories oft vermissen lässt.

Und das war's auch schon – die Beschreibung dieses Buches in einem Satz. Dieser Satz trägt in sich ein großes Versprechen. Der Blick auf das große Ganze hilft dabei, mit Usern effektiv zu kommunizieren, er hilft allen Beteiligten, zu vermeiden, unnütze Features zu produzieren, und er dient als Orientierungshilfe für eine in sich stimmige User Experience. Wenn ich mit meinen Kollegen bei ThoughtWorks darüber spreche, wie sie ihre Stories entwickeln, nennen sie Story Mapping regelmäßig als Schlüsselmethode. Häufig haben sie die Methode in Workshops mit Jeff gelernt, denn er hat die Methode entwickelt und kann sie am besten kommunizieren. Dieses Buch gibt mehr Menschen die Möglichkeit, die Methode direkt an der Quelle zu erlernen.

Aber dieses Buch ist nicht nur etwas für Leute, die einen Titel wie »Business-Analyst« auf der Visitenkarte oder ihrem Online-Profil stehen haben. Eine der größten Enttäuschungen für mich war in diesem Jahrzehnt, in dem agile Methoden immer mehr Anwendung fanden, dass viele Programmierer Stories als eine Kommunikations-Einbahnstraße vom Analysten zu ihnen ansehen. Von Anfang an waren Stories als Zündfunken für Konversationen gedacht. Wenn man sich tatsächlich effektive Softwarelösungen für bestimmte Tätigkeiten ausdenken will, muss man diejenigen, die die Software schreiben, als lebenswichtige Ideengeber für die Einsatzmöglichkeiten betrachten, denn es sind die Programmierer, die am besten wissen, was Software leisten kann. Programmierer müssen verstehen, was ihre User zu erreichen versuchen, und sollten kollaborativ Stories entwickeln, die diese Bedürfnisse der User abbilden. Ein Programmierer, der Story Mapping beherrscht, ist besser in der Lage, den Kontext des Users zu erkennen, und kann dabei helfen, die Software zu umreißen – und somit seine Arbeit besser zu machen.

Als Kent Beck (auf den der Gedanke der »Story« zurückgeht) seine Ideen zur Softwareentwicklung erarbeitete, bezeichnete er Kommunikation als Schlüsselwert für effektive Teams. Stories sind die Bausteine der Kommunikation zwischen den Entwicklern und denen, die ihre Arbeit benutzen werden. Story Maps organisieren und strukturieren diese Bausteine und verbessern damit den Kommunikationsprozess – der den wohl wichtigsten Part der Softwareentwicklung darstellt.

Vorwort von Alan Cooper

In Mary Shelleys berühmtem Science-Fiction-Roman Frankenstein erschafft der wahnsinnige Dr. Frankenstein eine Kreatur aus verschiedenen Stücken toter Menschen und erweckt diese Kreatur mit der damals neuartigen Technologie der Elektrizität zum Leben. Natürlich wissen wir, dass das eigentlich nicht möglich ist. Man kann kein Leben erschaffen, indem man zufällige Körperteile zusammennäht.

Und doch ist es das, was Softwareentwickler immer wieder versuchen: Sie erweitern eine Software um gute Features, eins nach dem anderen, und dann wundern sie sich, wieso so wenige User ihr Produkt gut finden. Der Kern des Problems liegt darin, dass Entwickler ihre Konstruktionsmethode als Design-Tool benutzen, die beiden aber nicht untereinander austauschbar sind.

Es ist absolut sinnvoll, dass Programmierer die Software Feature für Feature produzieren. Das ist eine hervorragende Strategie, die sich jahrelang bewährt hat. Was sich allerdings auch über die Jahre gezeigt hat, ist, dass der Ein-Feature-nach-dem-anderen-Ansatz – setzt man ihn als Designmethode für das Verhalten und den Umfang eines digitalen Produkts ein – zu einem Frankenstein'schen Monster(-Programm) führt.

Wenn sie auch eng verwandt sind, so unterscheiden sich die Praxis des Softwaredesigns und die der Erstellung ebendieser Software doch deutlich voneinander und werden üblicherweise von verschiedenen Personen mit unterschiedlichen Skills absolviert. Zahllose Stunden damit zuzubringen, User zu beobachten und Verhaltensmuster zu mappen, wie das die Interaktionsdesigner tun, würde die meisten Programmierer in den Wahnsinn treiben. Umgekehrt wäre stundenlanges Brüten über Algorithmen eine viel zu einsiedlerische Tätigkeit für die meisten Designer.

Aber wenn diese beiden unterschiedlichen Ansätze – Design und Entwicklung – zusammenarbeiten, kommt eine elektrische Spannung auf, die das Potenzial besitzt, ein lebendes, atmendes Produkt zu erschaffen. Teamarbeit haucht dem Monster Leben ein und bringt die Leute dazu, es zu lieben.

Zwar ist die Idee der Zusammenarbeit weder neu noch sonderlich aufschlussreich, aber es ist dennoch sehr schwer, sie tatsächlich effektiv umzusetzen. Die Arbeitsweise der Entwickler – ihr Tempo, ihre Sprache und ihr Rhythmus – unterscheidet sich sehr von der der Interaktionsdesigner.

Die Fachleute beider Gebiete sind stark, kompetent und innerlich diszipliniert, aber sie haben beide die gleiche Schwäche: Es ist wirklich schwer, ein Designproblem in Programmierersprache auszudrücken, und es ist ebenso schwer, ein Entwicklungsproblem in der Sprache der Designer zu formulieren. Die beiden Schwesterdisziplinen haben keine gemeinsame Sprache. Und genau dort, auf der Kreuzung zwischen den beiden Disziplinen, finden wir Jeff Patton.

Jeffs Methode des Story Mapping ist für Entwickler gut verständlich, und sie ist ebenso gut verständlich für die Designer. Story Mapping ist der Rosetta-Stein des digitalen Zeitalters.

Trotz gegenteiliger Behauptungen ist die agile Entwicklung kein sonderlich gut geeignetes Designwerkzeug. Es handelt sich um eine Art, über Entwicklung nachzudenken, die designfreundlich ist – was eine gute Sache ist –, aber für sich genommen, führt sie nicht zu einem Produkt, das die Nutzer toll finden. Auf der anderen Seite kann man oft erleben, dass gute, wohldokumentierte Designs in die Hände von Entwicklern gelegt werden, die dann – agil oder nicht – die inneren Werte dieses Designs in der Umsetzung vollständig plätten.

Pattons Story-Mapping-Ansatz ist ein Brückenschlag über diesen Abgrund. Beim Interaktionsdesign geht es darum, die Wahrheit des Users zu finden und als Erzählung abzubilden. In der Softwareentwicklung geht es darum, diese Erzählung in kleine, funktionale Stücke zu zerlegen und diese wiederum zu implementieren und zu integrieren. Es passiert ganz schnell, dass in diesem komplexen Prozess der Wesenskern der Erzählung flöten geht. Ja, die Funktionen wurden implementiert, aber der Patient stirbt auf dem OP-Tisch.

Indem es die User Stories als Landkarte auslegt, behält das Design seine narrative Struktur, kann aber dennoch für eine effektive Implementation dekonstruiert werden. Die Geschichte des Designers, die eine formalisierte Fassung der User Story ist, bleibt durch die gesamte Entwicklung hindurch intakt.

Die klassische Welt der Konzerne hat bewiesen, dass es nahezu unmöglich ist, mit Teams von zwei- oder dreihundert Leuten Produkte herzustellen, die jemand wirklich richtig gut findet. Die Startup-Community wiederum hat bewiesen, dass ein Team aus vier oder fünf Personen sehr wohl kleine Produkte machen kann, die die Leute mögen. Aber selbst solche Produkte werden irgendwann groß und verlieren diesen inneren Funken. Die Herausforderung, der wir uns stellen müssen, ist, große Software zu erschaffen, die die Leute lieben. Große Software bedient große Gruppen von Nutzern, die komplexe, kommerziell relevante Aufgaben damit verrichten. Es ist unglaublich schwer, solche Software so zu gestalten, dass ihre Benutzung Spaß macht und leicht zu erlernen ist.

Die einzige Methode, auf die wir große Software produzieren können, die kein Frankenstein'sches Monster ist, ist, indem wir lernen, das Softwaredesign und die Entwicklung miteinander zu vereinen. Und niemand weiß das besser als Jeff Patton.

Vorwort von Marty Cagan

Ich hatte das große Glück, mit vielen der besten Technologieteams der Welt arbeiten zu dürfen. Mit Menschen, die die Produkte erschaffen haben, die wir jeden Tag benutzen und gern haben. Teams, die im Wortsinn die Welt verändert haben.

Man hat mich auch hinzugezogen, um Firmen zu helfen, bei denen es nicht so gut lief. Startups, die Bodenhaftung bekommen mussten, ehe ihnen das Geld ausging. Größere Firmen, die versuchten, ihre frühen Innovationen zu replizieren. Teams, die es nicht schafften, etwas Wertvolles zum Unternehmen beizutragen. Führungskräfte, die darüber frustriert waren, wie lange es dauerte, bis aus einer Idee Realität wurde. Techniker, die über ihre Produkt-Owner verärgert waren.

Ich habe dabei gelernt, dass es einen wesentlichen Unterschied dazwischen gibt, wie die besten Firmen ihre Technologie-Produkte erschaffen, und wie der Rest es macht. Und damit meine ich nicht kleine Unterschiede. Ich meine alles, angefangen davon, wie sich Führungskräfte verhalten, über das Empowerment von Teams und die Art und Weise, wie Teams zusammenarbeiten, bis hin zur Unternehmenskultur und der Art und Weise, auf die Produktentwicklung, Design und Technik gemeinsam daran arbeiten, effektive Lösungen für ihre Kunden zu erschaffen.

Dieses Buch trägt den Titel User Story Mapping, aber ihr werdet schon bald merken, dass es um sehr viel mehr geht als nur diese einfache, aber wirkungsvolle Technik. Dieses Buch reicht bis in den Kern der Frage hinein, wie Teams zusammenarbeiten, kommunizieren und schlussendlich gute Dinge finden, die es sich lohnt zu produzieren.

Viele von euch hatten noch nie die Gelegenheit, aus der Nähe mitzuerleben, wie ein starkes Produktteam arbeitet. Alles, was ihr möglicherweise kennt, ist das, was eure jetzige oder vorige Firma tut. Deswegen möchte ich versuchen, hier einen kleinen Eindruck davon zu vermitteln, wie stark sich die besten Teams vom Rest unterscheiden.

Mit einer dankbaren Verneigung vor Ben Horowitz’ Good Product Manager, Bad Product Manager habt ihr hier einen flüchtigen Einblick in einige der entscheidenden Unterschiede zwischen starken Produkt-Teams und schwachen Teams:

Gute Teams haben eine überzeugende Vision ihres Produktes, die sie mit der Leidenschaft eines Missionars verfolgen. Schlechte Teams sind Söldner.

Gute Teams beziehen ihre Inspiration und Produktideen aus Scorecard-KPIs, aus der Beobachtung sich abmühender Kunden, aus der Analyse der Daten, die Kunden bei der Nutzung des Produktes generieren, und aus der gewohnheitsmäßigen Anwendung neuester Technik bei der Problemlösung. Schlechte Teams holen bei Kunden und Sales-Abteilungen Anforderungen ein.

Gute Teams wissen, wer ihre Key Stakeholder sind, sie kennen die Begrenzungen, innerhalb deren diese Stakeholder operieren, und sie sind darauf ausgerichtet, Lösungen zu erschaffen, die nicht bloß für die Kunden und Nutzer funktionieren, sondern auch innerhalb der Beschränkungen des jeweiligen Business. Schlechte Teams holen bei Stakeholdern Anforderungen ein.

Gute Teams sind in den zahlreichen Techniken ausgebildet, mit denen man schnell Produktideen austesten kann, um zu bestimmen, welche es sich wirklich zu entwickeln lohnt. Schlechte Teams halten Meetings ab, um priorisierte Roadmaps zu erzeugen.

Gute Teams brainstormen liebend gern mit klugen Köpfen aus dem gesamten Unternehmen. Schlechte Teams sind beleidigt, wenn jemand von außerhalb ihres Teams es wagt, vorzuschlagen, dass sie irgendetwas tun sollten.

In guten Teams arbeiten Produktentwicklung, Design und Technik Seite an Seite, und sie begrüßen das Geben und Nehmen zwischen Funktionalität, User Experience und der Technik, die diese ermöglicht. Schlechte Teams hocken in ihren jeweiligen Funktionsbereichen und erwarten, dass die anderen ihre Dienste in Form von Dokumenten und angesetzten Meetings anfordern.

Gute Teams testen konstant neue Ideen aus, um Innovation zu ermöglichen, aber auf eine Weise, die den Unternehmensgewinn und die Marke schützt. Schlechte Teams warten immer noch auf die Erlaubnis, einen Test durchzuführen.

Gute Teams bestehen darauf, dass sie über die nötigen Fähigkeiten verfügen, um erfolgreiche Produkte zu machen, wie zum Beispiel ein starkes Interaktionsdesign. Schlechte Teams wissen nicht mal, was Interaktionsdesigner sind.

Gute Teams sorgen dafür, dass ihre Techniker Zeit haben, die Discovery-Prototypen täglich zu testen, damit sie ihre Einsichten dazu beitragen können, wie das Produkt besser werden kann. Schlechte Teams führen den Technikern die Prototypen während der Sprint-Planung vor, damit sie eine Einschätzung abgeben können.

Gute Teams setzen sich jede Woche direkt mit Endnutzern und Kunden auseinander, um diese besser zu verstehen und die Reaktionen der Kunden auf ihre neuesten ideen zu erleben. Schlechte Teams denken, sie seien der Kunde.

Gute Teams wissen, dass viele ihrer Lieblingsideen am Ende nicht für den Kunden funktionieren werden, und dass selbst die, die es schaffen könnten, mehrere Iterationen brauchen werden, um an den Punkt zu gelangen, an dem sie das gewünschte Ergebnis liefern. Schlechte Teams machen nur das, was auf der Roadmap eingezeichnet ist, und sind zufrieden damit, Termine einzuhalten und die Qualität zu sichern.

Gute Teams begreifen, wie wichtig Geschwindigkeit ist, und dass eine schnelle Iteration der Schlüssel zur Innovation ist. Sie wissen, dass die Geschwindigkeit aus dem Einsatz der richtigen Techniken resultiert, nicht aus Zwangsarbeit. Schlechte Teams beklagen sich, sie seien so langsam, weil ihre Kollegen nicht hart genug arbeiteten.

Gute Teams gehen Verpflichtungen mit hoher Integrität ein, nachdem sie eine Anfrage evaluiert und sichergestellt haben, dass sie eine lebensfähige Lösung anbieten können, die tatsächlich für den Kunden und sein Business funktioniert. Schlechte Teams beklagen sich, ihr Unternehmen sei verkaufsorientiert.

Gute Teams instrumentieren ihre Arbeit, damit sie sofort herausfinden können, wie ihr Produkt benutzt wird, und auf diesen Daten basierende Anpassungen vornehmen können. Schlechte Teams betrachten Analysetools und Reporting als »nice-to-have«.

Gute Teams integrieren und releasen fortlaufend, denn sie wissen, dass ein gleichbleibender Strom kleinerer Releases für eine erheblich stabilere Lösung für ihren Kunden sorgt. Schlechte Teams testen manuell am Ende einer schmerzlichen Integrationsphase und releasen dann alles auf einmal.

Gute Teams machen sich einen Kopf über ihre Referenzkunden. Schlechte Teams machen sich einen Kopf über ihre Mitbewerber.

Gute Teams feiern, wenn sie signifikante Auswirkungen auf die KPIs ihres Business erzielen. Schlechte Teams feiern, wenn sie endlich irgendwas abliefern.

Mir ist klar, dass ihr euch vielleicht fragt, was das alles mit Story Maps zu tun hat. Ich glaube, ihr wärt überrascht. Und genau deswegen bin ich ein Fan von Story Maps.

Ich habe nur wenige agile Experten getroffen, die ich für qualifiziert halte, einem Produktteam dabei zu helfen, sich so sehr zu verbessern, dass es das leisten kann, was seine Firma braucht und verdient. Jeff Patton ist einer davon. Ich habe erlebt, wie er mitten in der Produkt-Discovery mit Teams in den Schützengraben stieg und die Ärmel hochkrempelte. Ich stelle ihn gern Firmen vor, denn er ist effektiv. Teams mögen ihn, weil er Ahnung hat, aber ein bescheidener Typ ist.

Die Tage, in denen Produktmanager Anforderungen zusammenstellten und dokumentierten, in denen Designer sich abmühen mussten, um auch nur einen Hauch Lippenstift auf den Look auftragen zu können, und in denen sich die Techies im Keller verschanzten und Code tippten, sind bei den besten Teams lange vorbei. Und es ist an der Zeit, dass sie auch in eurem Team vorbei sind.

Über dieses Buch

Live in it, swim in it, laugh in it, love in it / Removes embarrassing stains from contour sheets, that’s right / And it entertains visiting relatives, it turns a sandwich into a banquet.

—Tom Waits, »Step Right Up«

Dieses Buch sollte eigentlich nur ganz kurz werden, eine Broschüre quasi.

Ich begann damit, über eine simple Verfahrensweise zu schreiben, die ich Story Mapping nannte. Ich erstelle – wie eine Menge anderer Leute auch – einfache Maps, die es erleichtern, mit anderen zusammenzuarbeiten und nachzuempfinden, wie es sich anfühlt, ein Produkt zu benutzen.

Story Mapping sorgt dafür, dass wir uns auf die Benutzer (User) und ihre Erfahrungen (User Experience) konzentrieren. Das Ergebnis ist eine bessere Konversation und schlussendlich ein besseres Produkt.

Das Erstellen einer Map ist ganz einfach. Zusammen mit den anderen Beteiligten erzähle ich die Geschichte (Story) eines Produkts und schreibe jeden wichtigen Schritt, den ein User absolviert, auf Klebezettel, die ich von links nach rechts anordne. Dann schauen wir uns diese Schritte noch einmal komplett an, sprechen über die Details jedes einzelnen Schrittes und notieren diese auf weiteren Klebezetteln, die wir vertikal unter dem jeweiligen Schritt anbringen. Damit erhalten wir eine einfache, rasterähnliche Struktur, die die Story von links nach rechts erzählt, und die damit verbundenen Details von oben nach unten auflistet. Das geht ganz fix und macht Spaß. Mithilfe dieser Details verfügen wir dann auch über ein besseres Backlog der Stories bei unseren agilen Entwicklungsprojekten.

Wie schwierig konnte es wohl sein, ein Buch darüber zu schreiben?

Nun, es stellte sich heraus, dass auch ganz einfache Dinge ausgesprochen kompliziert sein können. Und zu beschreiben, warum man eine Story Map anlegen sollte, was dabei vorgeht und auf wie viele verschiedene Weisen man sie benutzen kann, hat eine ganze Menge Seiten gefressen. Da war doch etwas mehr an dieser simplen Verfahrensweise dran, als ich gedacht hatte.