User Story Mapping

Stellen Sie sich vor, Sie versuchen, ein komplexes Möbelstück ohne die visuelle Bedienungsanleitung zusammenzubauen - nur eine lange Liste von Schritten. Frustrierend, oder? Genau so fühlen sich viele Teams, wenn sie von einem flachen Produkt-Backlog aus arbeiten. Sie haben Listen mit Funktionen und Anforderungen, aber sie haben die gesamte Customer Journey aus den Augen verloren.

Das ist wo Zuordnung von Benutzergeschichten kommt rein. Es hilft uns, den Wald zu sehen, bevor wir uns in den Bäumen verirren.

Die Macht des narrativen Flusses bei der Produktentdeckung

Das User Story Mapping verändert die Art und Weise, wie Teams an die Produktentdeckung herangehen. Anstatt direkt auf die Funktionen einzugehen, hilft es Ihnen, die gesamte Reise zu visualisieren, die ein Kunde mit Ihrem Produkt von Anfang bis Ende durchläuft. Dieser Fokus liegt auf Kundenorientierung stellt sicher, dass Sie Funktionen erstellen, die wirklich wichtig sind.

Wie Jeff Patton, der Pionierarbeit beim User Story Mapping geleistet hat, erklärt, sind traditionelle flache Backlogs so, als würde man versuchen, ein Buch zu verstehen, indem man eine Liste von Sätzen in zufälliger Reihenfolge liest. Sicher, der gesamte Inhalt ist da, aber die Geschichte — die Reise des Nutzers — geht verloren.

„Das User Story Mapping ist ein moderiertes, kuratiertes Gespräch, das alle mit auf die Reise nimmt. Es ist eine Gelegenheit für den Produktmanager, seine Erkenntnisse (der Tag für Tag tief in diesem Zeug steckt) zu analysieren und sie in die Köpfe des Teams zu übertragen, das im Begriff ist, sie umzusetzen. „- Nicholas Muldoon, Mitbegründer und CEO von Easy Agile

Erstellen Sie Ihre erste User Story Map

Sehen wir uns die Erstellung einer User Story Map für einen Streaming-Dienst wie Netflix oder Apple TV an. Wir werden sehen, wie ihre Teams das Nutzererlebnis beim Ansehen eines Films abbilden könnten.

Schritt 1 — Fangen Sie mit dem Gesamtbild an

‍

Identifizieren Sie zunächst die Hauptaktivitäten, die Ihre Nutzer durchmachen — was Jeff Patton das „Rückgrat“ oder den „Erzählfluss“ Ihrer Storymap nennt. Stellen Sie sich diese als Kapitelüberschriften in der Story Ihres Benutzers vor.

Für unser Beispiel für einen Streaming-Dienst könnte das Backbone so aussehen:

• Wählen Sie einen Film
• Film kaufen
• Film anschauen
• Film rezensieren/empfehlen

‍

🎯 Teamübung: Stellen Sie Ihr Team zusammen und fragen Sie: „Was sind die wichtigsten Schritte, die unsere Benutzer unternehmen, um ihr Ziel zu erreichen?“ Schreiben Sie jeden Schritt auf eine Karte oder eine Haftnotiz und ordnen Sie sie in chronologischer Reihenfolge von links nach rechts an.

Schritt 2 — Benutzeraufgaben hinzufügen

Jetzt kommen die vielen Details. Fügen Sie unter jeder Hauptaktivität die spezifischen Aufgaben hinzu, die Benutzer erledigen müssen. Diese werden zu Ihren Benutzergeschichten. Der Schlüssel liegt darin, sich weiterhin auf den Nutzernutzen und nicht auf die technische Umsetzung zu konzentrieren.

Im obigen Beispiel könnten dies Ihre User Stories für die Aktivität „Film auswählen“ sein:

• Freitextsuche
• Nach Genre durchsuchen
• Nach Neuzugang durchsuchen
• Nach den beliebtesten durchsuchen
• Sortiere nach den beliebtesten nach Genre
• Nach Neuzugang nach Genre durchsuchen

💡 Profi-Tipp: Schreiben Sie diese Aufgaben aus der Sicht des Benutzers. Anstatt „Suchfunktion implementieren“ zu schreiben, schreiben Sie „Nach bestimmten Filmen suchen“.

‍

Schritt 3 — Master-Backlog-Priorisierung

Hier glänzt das User Story Mapping im Vergleich zu flachen Backlogs wirklich. Sie organisieren Ihre Storys sowohl horizontal (in der Reihenfolge) als auch vertikal (nach Priorität). Dieser Ansatz hilft sowohl bei der Priorisierung von Funktionen als auch bei der Sprint-Planung.

Horizontal: Ordne Geschichten von links nach rechts in der Reihenfolge an, in der Benutzer sie natürlich aufführen würden.

Vertikal: Ordnen Sie die Geschichten von oben nach unten in der Reihenfolge ihrer Priorität an, und zwar nach dem Wert, den sie für den Nutzer haben. Sie können den Wert anhand von Gesprächen mit Nutzern, Analysen von Nutzungsmustern oder einer anderen Form von Erkenntnissen, die für Ihr Produkt geeignet sind, ermitteln.

Stell es dir vor, als würdest du ein Haus bauen. Das Fundament (Must-Haves) kommt zuerst, dann die Wände (sollte man haben) und schließlich die dekorativen Details (Nice-to-Haves).

Vorrangiger Rahmen:

HOCH (Muss sein)

• Kernfunktionen, die für die grundlegende Benutzererfahrung unerlässlich sind
• Kritische Nutzerbedürfnisse wurden aus der Forschung identifiziert
• Beispiel: Einfache Suche, Filmwiedergabe, Zahlungsabwicklung

MEDIUM (hätte sein sollen)

• Wichtige Funktionen, die das Benutzererlebnis verbessern
• Bestätigte Benutzerwünsche anhand von Feedback
• Beispiel: Genrefilterung, Empfehlungen, Bewertungsanzeige

NIEDRIG (Schön zu haben)

• Zusätzliche Funktionen für mehr Vergnügen
• Mögliche zukünftige Verbesserungen
• Beispiel: Teilen in sozialen Netzwerken, Erweiterte Empfehlungen, mehrere Beobachtungslisten

‍

Schritt 4 — Identifizieren Sie Ihre Veröffentlichungen

Zeichnen Sie nach dem Layout Ihrer Karte horizontale Linien, um Ihre Karte in Abschnitte zu unterteilen. Jedes Segment sollte ein vollständiges, wertvolles Nutzererlebnis bieten.

Moderation von User Story Mapping-Sitzungen

Um eine effektive User Story Mapping-Sitzung durchzuführen, müssen Sie mehr als nur die oben genannten Schritte ausführen. Ganz gleich, ob Ihr Team am gleichen Standort oder über mehrere Zeitzonen verteilt ist, wie Sie diese Sitzungen produktiv und ansprechend gestalten können:

Checkliste vor der Sitzung

• Laden Sie die richtigen Personen ein (Product Owner, Entwickler, Designer, Fachexperten)

• Bereiten Sie Erkenntnisse und Daten aus der Kundenforschung vor

• Richten Sie einen physischen oder digitalen Raum für die Zusammenarbeit ein

• Definieren Sie klare Sitzungsziele

• Planen Sie ausreichend Zeit ein (in der Regel 2-4 Stunden für die erste Kartierung)

Checkliste während der Sitzung

• Beginnen Sie mit dem Kundenkontext (teilen Sie Forschungsergebnisse, Personas)

• Konzentrieren Sie sich auf die Benutzerperspektive

• Dokumentieren Sie Fragen und Annahmen

• Machen Sie Fotos/Screenshots von laufenden Arbeiten

• Erfassen Sie Aktionspunkte und Entscheidungen

User Story Mapping für Teams am selben Standort

Stellen Sie sicher, dass der physische Raum für die perfekte User Story-Mapping-Sitzung gut ausgestattet ist.

• Große Wandfläche oder Whiteboard
• Viele Haftnotizen in verschiedenen Farben
• Marker für alle
• Raum für Teambewegung und Diskussion

User Story Mapping für Remote-Teams

Viele Teams müssen oft dirigieren User Story Mapping-Sitzungen aus der Ferne. Die Prinzipien bleiben zwar dieselben, die Ausführung erfordert jedoch einige zusätzliche Überlegungen:

1. Digitaler Arbeitsplatz:
   • Wählen Sie Tools für die Zusammenarbeit wie Easy Agile TeamRhythm
   • Vorlage vorher einrichten
   • Stellen Sie sicher, dass jeder Zugriff hat und mit den Tools vertraut ist
2. Engagement-Techniken:
   • Nutzen Sie kleinere Pausenräume für ausführliche Diskussionen
   • Nutzen Sie digitale Wahlen zur Priorisierung
   • Verwenden Sie zeitgesteuerte Aktivitäten, um die Energie aufrechtzuerhalten
   • Planen Sie kürzere Sitzungen mit klaren Pausen ein
   • Nehmen Sie Sitzungen für Teammitglieder in verschiedenen Zeitzonen auf

So funktioniert Remote User Story Mapping für Sie

Während der Pandemie wandte sich Lyft an Easy Agile TeamRhythm Story-Mapping von Benutzern aus der Ferne um ihre Teams zu verbinden und konzentriert zu halten, während sie von zu Hause aus arbeiten. Dieses Tool erleichterte es ihren verteilten Teams, zusammenzuarbeiten, Kundenreisen zu visualisieren und Prioritäten im Auge zu behalten — auch wenn alle voneinander getrennt waren.

Das Ergebnis? Eine Steigerung der Effizienz um 20% und eine reibungslosere, besser abgestimmte Teamarbeit. Es ist ein gutes Beispiel dafür, wie das richtige Tool dafür sorgen kann, dass sich die Arbeit im Home-Office viel weniger fernab anfühlt.

Bereit es auszuprobieren? Lassen Sie uns den Erfolg Ihres Teams mit folgenden Daten abbilden Einfacher agiler Teamrhythmus!

Häufige Fallstricke, die es zu vermeiden gilt

1. „Wir verlieren das große Ganze“

Lösung: Halten Sie Ihr Rückgrat jederzeit sichtbar. Treten Sie regelmäßig einen Schritt zurück und gehen Sie die gesamte Benutzerreise durch.

2. „Technische Diskussionen bringen uns aus der Patsche“

Lösung: Schaffen Sie einen „Parkplatz“ für technische Diskussionen. Konzentrieren Sie sich zunächst auf die Erfahrung des Benutzers und befassen Sie sich dann in separaten Sitzungen mit den Einzelheiten der Implementierung.

3. „Teilnehmer aus der Ferne engagieren sich nicht“

Lösung: Verwenden Sie Round-Robin-Techniken, um sicherzustellen, dass jeder seinen Beitrag leistet. Schaffen Sie explizite Gelegenheiten für Beiträge von Teammitgliedern an verschiedenen Standorten.

4. „Unsere Landkarte ist veraltet“

Lösung: Planen Sie regelmäßige Überprüfungssitzungen ein. Machen Sie die Aktualisierung der Karte zu einem Teil Ihrer Sprint-Zeremonien.

Halten Sie Ihre Storymap am Leben

Ihre User Story Map sollte keine einmalige Übung sein, die weggepackt wird. Sie sollte sich weiterentwickeln, wenn sich Ihr Verständnis von Benutzern vertieft. Halten Sie es lebendig und relevant, indem Sie:

1. Es sichtbar machen

• Präsentieren Sie es gut sichtbar in Ihrem Teambereich
• Halten Sie es in Ihren digitalen Tools zugänglich
• Verweisen Sie in Planungssitzungen darauf

2. Regelmäßige Aktualisierung

• Fügen Sie neue Erkenntnisse aus Kundenfeedback hinzu
• Passen Sie die Prioritäten auf der Grundlage der Erkenntnisse an
• Erledigte Artikel markieren
• Beachten Sie Änderungen der Benutzerbedürfnisse oder des Benutzerverhaltens

3. Verwenden Sie es zur Ausrichtung

• Referenz bei der Sprint-Planung
• Mit Stakeholdern teilen
• Wird für das Onboarding neuer Teammitglieder verwendet

Erfolgsmessung

Achten Sie abschließend auf diese Indikatoren, um festzustellen, ob Ihr Story-Mapping effektiv ist. Besondere Requisiten für dich und das Team, wenn du sie alle auf den Punkt bringst.

✓ Die Teammitglieder beziehen sich bei Diskussionen natürlich auf die Karte

✓ Kundenfeedback entspricht Ihrer Priorisierung

✓ Releases bieten kohärente Benutzererlebnisse

✓ Weniger unüberschaubare Funktionen und überlastete Funktionen

✓ Verbesserte Teamausrichtung auf Prioritäten

✓ Bessere Sprint-Planungssitzungen

Denken Sie daran, dass es beim User Story Mapping nicht darum geht, ein perfektes Dokument zu erstellen — es geht darum, bessere Gespräche über die Bedürfnisse der Nutzer zu führen und sicherzustellen, dass wir die richtigen Dinge in der richtigen Reihenfolge erstellen.

‍

Sie möchten tiefer in die Entwicklung kundenorientierter Produkte eintauchen? Laden Sie unser kostenloses E-Book „Understanding Customer Value in Agile“ herunter um zu lernen:

• Wie Sie der „Build-Falle“ entkommen und sich auf echte Kundenergebnisse konzentrieren
• Praktische Techniken, um Ihre Kunden tief zu verstehen
• Frameworks für die Erfassung und Umsetzung von Kundeninformationen
• Schrittweise Anleitung zur Erstellung aussagekräftiger Personas und Reisekarten
• Ein konkreter 30-60-90-Tage-Plan, um die Art und Weise zu verändern, wie Ihr Team den Kundennutzen versteht und erbringt

Laden Sie Ihr kostenloses Exemplar herunter hier und beginnen Sie Ihre Reise zu einer wirklich kundenorientierten agilen Entwicklung.

‍

Was ist User Story Mapping? Und noch wichtiger: WARUM sollten Sie eine Story-Mapping-Sitzung mit Ihrem Team durchführen wollen?

Lassen Sie uns zunächst über die Ursprünge von User Story Mapping sprechen.

Es ist heute eine gängige Praxis in der agilen Softwareentwicklung, aber das war nicht immer so.

Wenn Sie Erfahrung mit einem Scrum- oder Kanban-Backlog haben, sind Sie wahrscheinlich auf den gefürchteten flachen Backlog gestoßen.

Warum Story Mapping

In seiner einfachsten Form ist ein flacher Produkt-Backlog eine lange Liste mit Dingen, die zu erledigen sind, die Ihren Benutzern/Kunden letztendlich einen gewissen Mehrwert bieten. Zumindest hoffen wir das.

Viele von uns haben dazu beigetragen, dass diese Rückstände immer länger werden, und sie werden unweigerlich überwältigend.

Unabhängig davon, ob das Team die Arbeit nacheinander aus dem Backlog herauszieht oder sie in Sprints gruppiert, bringt die Priorisierung der Arbeit in einem flachen Backlog ihre Herausforderungen mit sich.

Das flache Backlog ist eine zweidimensionale Ansicht. Es ist wie eine Einkaufsliste, die keinen Kontext für die Arbeit bietet.

Treten Sie ein, die User Story Map! Das Konzept einer User Story Map entstand aus dem Wunsch heraus, den flachen Backlog abzubauen und einen ganzheitlicheren, kundenorientierteren Überblick über unsere Arbeit zu schaffen.

Eine User Story Map ist eine Visualisierung der Reise, die ein Kunde mit einem Produkt unternimmt, und beinhaltet die Aktivitäten und Aufgaben, die er normalerweise erledigen würde.

Normalerweise wird zu Beginn eines Projekts eine User Story Mapping Session durchgeführt, die ausschließlich dem Ziel dient, ein gemeinsames Verständnis des Teams darüber zu schaffen, wer Ihre Kunden sind und wie Sie Ihre Zeit darauf konzentrieren sollten, an Geschichten zu arbeiten, die für sie den größten Mehrwert bieten.

Sie können dies auf einem Whiteboard mit Haftnotizen tun, oder Sie können es in Jira mit unserer App tun. Einfacher agiler Teamrhythmus.

So erstellen Sie eine User Story Map

Um eine Visualisierung der Reise zu erstellen, die ein Kunde mit einem Produkt unternimmt, identifizieren Sie zunächst jede Phase und listen Sie dann die Aktivitäten und Aufgaben auf, die der Kunde normalerweise für jede Phase ausführen würde.

Als Nächstes beginnen Sie, jedes Arbeitselement im Backlog dem entsprechenden Touchpoint in der Customer Journey zuzuordnen.

An diesem Punkt in einer User Story Mapping-Sitzung sollte eine Matrix entstehen, die eine Liste von Aufgaben oder Geschichten enthält, zu deren Erfüllung sich das Team verpflichtet hat. Sie ist nach den Schritten der Customer Journey geordnet.

Von dort aus ist die Karte in die Zeitblöcke unterteilt, die das Team zur Planung seiner Arbeit verwendet. Zum Beispiel könnte sich das Team in Sprint 1 auf 5 User Stories festlegen, die an 3 Epen angehängt sind.

Dies hilft dabei, ein Verständnis dafür zu entwickeln, wie Fortschritte bei größeren Arbeiten erzielt werden können.

Warum User Story Mapping besser ist als ein flaches Backlog

Wenn die Arbeit im Backlog auf diese Weise mit der Kundenreise verknüpft wird, werden wichtige Fragen beantwortet wie:

• WARUM bauen wir das?
• Für WEN bauen wir das?
• WELCHEN Wert wird es ihnen bieten?
• WANN erwarten wir, dass wir das liefern werden?

Beim User Story Mapping wird der zweidimensionale Backlog quasi in eine dreidimensionale Ansicht umgewandelt, da wir so sagen können: „Okay, ich arbeite gerade daran, diese User Story zu erstellen, und ich kann mir vorstellen, welchen Teil der Customer Journey sich das direkt auswirken wird UND wir wissen, wann sie bereitgestellt wird.“

Indem eine Storymap den Nutzer in den Mittelpunkt stellt, stellt sie außerdem sicher, dass das Backlog Arbeiten enthält, die dem Kunden einen echten Mehrwert bieten, indem sie ihm helfen, seine Ziele zu erreichen.

So führen Sie eine User Story Mapping-Sitzung durch

Nachdem Sie nun den Wert einer User Story Map besser verstanden haben, schauen wir uns an, wie Sie eine User Story Map erstellen. Zunächst müssen Sie eine Story-Mapping-Sitzung mit Ihrem Team einrichten.

Aber was auch immer Sie tun, machen Sie keine offene Einladung daraus. Das ist wirklich wichtig, denn wenn Sie nicht die richtigen Leute im Raum haben, wird es nicht effektiv sein.

Personen, die Sie einladen könnten, sind:

Der Product Owner für das Team

• ein technischer Leiter
• ein User Experience Designer
• ein Marketingleiter
• ein Datenanalyst und
• jemand vom Kundensupport

Es ist auch wichtig, einige Grundregeln für die Sitzung festzulegen.

Es sollte eine Person geben, die die Sitzung moderiert. Es empfiehlt sich, einen Produktmanager aus einem anderen Team mit der Durchführung der Sitzung zu beauftragen.

Je nach Umfang der Story-Mapping-Sitzung möchten Sie vielleicht einen ganzen Tag Zeit nehmen oder die Sitzung auf mehrere Tage verteilen.

Der Umfang hängt davon ab, wie groß Ihr Team ist und wie viele User Stories Sie Ihrer Map hinzufügen müssen.

Außer dem Moderator sollten keine Telefone oder Laptops draußen sein.

Außerdem sollte jeder im Raum mit den besprochenen User Stories vertraut sein.

Nachdem Sie nun die Vorteile einer User Story Map kennen und wissen, was Sie bei der Einrichtung der Mapping-Sitzung mit Ihrem Team beachten sollten, sollten Sie darüber nachdenken, wen Sie zur Teilnahme einladen und die Sitzung moderieren können.

Backlogs sind so voller Potenzial, oder? Ideen und Möglichkeiten, Ihr Produkt größer und besser als je zuvor zu machen.

Aber wenn Sie mehr als ein paar Artikel auf Ihrer Liste haben, sind auch die Rückstände überwältigend.

Ohne eine klare Struktur oder Priorisierung weiß Ihr Team nicht, woran es zuerst arbeiten soll.

Sie arbeiten vielleicht an dem, wonach sie sich fühlen, was am einfachsten oder interessantesten ist, oder tun überhaupt nichts.

Sie müssen herausfinden, woran Sie zuerst arbeiten sollten. Nicht nur das, Sie müssen auch sicherstellen, dass das, was Sie tun, den Kunden einen Mehrwert bietet, für jede Version Sinn macht und in das Gesamtbild der Ziele Ihres Unternehmens passt.

Hier kommt das User Story Mapping ins Spiel.

Was ist User Story Mapping?

User Story Mapping ist nützlich Möglichkeit, Ihre User Stories zu organisieren und zu priorisieren damit du kannst plane deine Arbeit und gestalte deine Veröffentlichungen.

Es hilft dir Visualisieren Sie die Reise des Kunden durch Ihr Produkt von Anfang bis Ende, einschließlich aller Aufgaben, die sie normalerweise unterwegs erledigen würden.

Was ist eine User Story Mapping-Sitzung?

Das User Story Mapping erfolgt in der Regel in Sitzungen über 1-2 Tage wo Sie wichtige Personen im selben Raum zusammenbringen.

Während dieser Sitzungen teilt Ihr Produktmanager (und manchmal auch andere Interessengruppen) dem Team ihre Kundeneinblicke mit, das auch seine Ideen für das Produkt teilt.

Gemeinsam brainstormen Sie User Stories, entpacken die einzelnen Schritte Ihrer Customer Journey, listen alle aktuellen Probleme auf und fügen diese auf einer User Story Map zusammen. In Ihrer User Story Mapping-Sitzung sind sich alle einig, was passieren muss.

Was ist eine User Story Map?

EIN Die User Story Map ist das Artefakt oder die visuelle Tafel Sie produzieren als Ergebnis einer User Story Mapping-Sitzung.

Deine Teams werden sich bei jedem Sprint auf diese Map beziehen, um sicherzustellen, dass sie den Zeitplan einhalten, Abhängigkeiten koordinieren und das Gesamtbild im Auge behalten.

Was ist eine User Story?

Um zu verstehen, was eine User Story Map ist, ist es wichtig, einen Schritt zurückzutreten und eine der wichtigsten Komponenten zu definieren: die User Story.

Eine User Story ist ein Ziel oder Ergebnis, das der Nutzer oder Kunde erreichen möchte.. Normalerweise schreibst du User Stories wie diese:

“Als [Personentyp], ich möchte [Aktion] damit [profitieren].“

Eine User Story sollte die am kleinsten Arbeitseinheit, die dem Kunden einen Mehrwert bieten kann.

Sie könnten eine User Story auch als eine Aufgabe betrachten, die aus der Sicht des Benutzers oder Kunden geschrieben wurde. User Stories werden normalerweise zu Ihrem Backlog hinzugefügt. Von dort aus können Sie sie anordnen und priorisieren und sie auf einer User-Story-Map darstellen, sodass sie für einen Release oder Sprint geplant sind.

Lesen Sie mehr über User Stories in unserem Blog: Wie schreibt man gute User Stories in der agilen Softwareentwicklung.

Wie sieht eine User Story Map aus?

Das User Story Mapping erfolgt traditionell auf einem physischen Story-Mapping-Board:

Unternehmen führen ihr Story-Mapping jedoch zunehmend digital durch. Wenn Sie Easy Agile User Story Maps verwenden, gefällt Ihnen vielleicht mehr wie folgt:

Unabhängig davon, ob Sie Ihr User Story Mapping physisch oder digital durchführen, Sie werden feststellen, dass beide Ansätze einige Gemeinsamkeiten haben:

• Ein Rückgrat (die Reihe am oberen Rand der Haftnotizen), das oft aus Epen besteht
• Karten oder Haftnotizen mit Benutzerberichten unter jedem Element im Backbone
• Diese Geschichten sind vertikal angeordnet, von den wichtigsten (für den Kunden) oben bis zu den unwichtigsten unten
• Horizontale Schnittlinien oder Swimlanes definieren, wo deine Releases oder Sprints beginnen und enden.

(Psst: mehr dazu in unserem Blog, Anatomie einer agilen User Story Map.)

Was beinhaltet eine User Story Mapping-Sitzung?

In einer User-Story-Mapping-Sitzung werden alle Bestandteile Ihrer Story-Map besprochen und geplant:

1. Ihr Team wird sich zusammensetzen und über das Grundgerüst entscheiden — die großen Schritte, die Ihre Benutzerreise ausmachen.
2. Als Nächstes brainstormen sie User Stories — all die kleinen Schritte, die die User Journey ausmachen, und alle Probleme (Bugs oder Ideen) — und fügen sie dem Backlog hinzu.
3. Sie werden diese Geschichten unter dem Backbone-Objekt organisieren, mit dem sie in Verbindung gebracht werden.
4. Als Nächstes besprechen und schätzen sie den Arbeitsaufwand, der mit jeder User Story verbunden ist, und weisen ihnen Storypoints zu.
5. Danach kann dein Team Schnittlinien hinzufügen, um festzulegen, was es wann liefern wird — entweder pro Sprint oder Release. An diesem Punkt könnten Sie einige Geschichten durcheinander mischen, wenn es für den Benutzer sinnvoll ist, sie in derselben Version zu veröffentlichen.
6. Wenn alle mit dem Plan zufrieden sind, ist die Storymap (vorerst) fertig und es ist Zeit für dein Team, den ersten Sprint zu starten.
   

Das scheint eine Menge Aufwand zu sein. Also, was ist der Sinn?

Was ist der Sinn von User Story Mapping?

Das User Story Mapping kommt sowohl Ihren Kunden als auch Ihrem Team zugute.

Kunden erhalten schneller einen höheren Mehrwert

hilft dir verstehen, was Ihre Kunden wollen. Da der Fokus auf der Customer Journey liegt und darauf, welche Aufgaben sie erledigen müssen, um Ihr Produkt nutzen zu können, hilft es Ihnen, Aufgaben zu priorisieren, die dazu beitragen, die Lücken für Kunden zu schließen und ihnen einen Mehrwert zu bieten.

Teams priorisieren und arbeiten besser zusammen

Eine dreidimensionale Ansicht hilft bei der Priorisierung, da Ihr Team sehen kann, welche User Stories innerhalb einer Version gruppiert werden sollten, um den Benutzern ein neues Erlebnis zu bieten. Zum Beispiel ist das Hinzufügen der Möglichkeit, Ihr Profil anzupassen, gar nicht so aussagekräftig, es sei denn, Sie haben einen Community-Aspekt, bei dem Benutzer andere Profile ansehen und/oder miteinander interagieren können. Das User Story Mapping hilft dir dabei, alle Teile zusammenzufügen — und sicherzustellen, dass du sie innerhalb des Sprints oder Releases realistisch umsetzen kannst.

Außerdem können Sie Ihre Arbeit effektiver planen und als Team mit Ihrer User Story Map zusammenarbeiten. Das liegt daran, dass Sie das Gesamtbild und die gesamte Customer Journey sehen können, bevor Sie mit der Arbeit beginnen.

Weitere Einblicke finden Sie in unserem Blog unter warum User Story Mapping.

Was ist die Alternative zum User Story Mapping?

Wenn Sie bis jetzt noch kein User Story Mapping durchgeführt haben, haben Sie wahrscheinlich eine andere Methode verwendet, um die Kundenanforderungen zu verstehen und Ihre Arbeit zu planen/zu priorisieren.

Der gängigste Ansatz ist als „flacher Backlog“ bekannt. Im Wesentlichen handelt es sich dabei um eine Aufgabenliste, die von der höchsten zur niedrigsten Priorität sortiert ist und möglicherweise durch Schnittlinien für Sprints oder Versionsveröffentlichungen unterbrochen wird. Der flache Backlog ist einfach (es ist im Grunde eine To-do-Liste), aber wenn Sie ein komplexes Produkt haben, viele Teams, die daran arbeiten, Abhängigkeiten und einen riesigen, sich ständig ändernden Backlog... benötigen Sie etwas Robusteres, damit Sie Ihre Ziele, Kundenorientierung und Prioritäten nicht aus den Augen verlieren.

Apropos Alternativen, schauen Sie sich diese kleine Geschichte von einem unserer Kunden an...

Was User Story Mapping für Teams leisten kann

„Unsere Teams waren auf der Suche nach einer Alternative zur Standard-Jira-Backlog-/Board-Ansicht, die sich nicht für die Organisation und Pflege riesiger Backlogs mit vielen Epics eignet.

Die Easy Agile User Story Maps App ermöglicht es unseren Teams, ihre Arbeit besser zu organisieren. Die Benutzeroberfläche ist logisch, und die Produktverantwortlichen (die in der Regel keine Techniker sind) mögen das Layout der Karten in Spalten unter ihren jeweiligen Epen.

Diese vertikale Sichtweise scheint eine bessere Kommunikation bei der Planung von Besprechungen zu fördern und bietet eine hervorragende Visualisierung dessen, was als Nächstes kommt.“

- Chris Heritage, Das Atlassian-Team @NextEra Energy

Wie du an diesem Beispiel sehen kannst, beginnen viele Teams mit flachen Backlogs oder Board-Views, stellen aber fest, dass sie dem entwachsen, wenn ihr Backlog größer wird.

Wie User Story Mapping dein flaches Backlog aufwerten kann

Was User Story Mapping vom flachen Backlog unterscheidet, ist, dass es ein ganz anderes Element hat. Es ist nicht flach, sondern dreidimensionaler.

Du hast die Liste der Aktivitäten/Aufgaben, aber Sie werden zunächst danach sortiert, wie sie sich auf die Kundenreise auswirken. Erst dann werden sie priorisiert und bis zum Zeitpunkt ihrer Veröffentlichung aufgeteilt.

Das User Story Mapping ist etwas komplexer einzurichten als ein flaches Backlog, aber es macht die Arbeit aussagekräftiger, kundenorientierter und wirkungsvoller. Mit einer User Story Map können Sie das Gesamtbild sehen und gemeinsam daran arbeiten.

Wir sprechen mehr darüber in unserem Blog, Der Unterschied zwischen einem flachen Produkt-Backlog und einer User Story Map.

Probiere User Story Mapping in Jira aus

Möchten Sie wissen, wie Sie am besten verstehen, was User Story Mapping ist?

Fahrradfahren kann man nicht lernen, indem man darüber liest. Und ohne es zu tun, kannst du *wirklich* nicht lernen, was User Story Mapping ist und die Vorteile aus erster Hand zu erleben.

Also, probiere es aus!

Wenn dein Team Jira für Projektmanagement und Workflows verwendet, kannst du dir ein Add-on holen, das dir hilft, aus dem flachen Backlog eine dreidimensionale User Story Map zu machen.

Easy Agile User Story Maps for Jira erstellt die X-Achse, sodass Sie Ihr Customer-Journey-Backbone hinzufügen und Ihre Storys so organisieren können, dass sie in diese Journey passen. Auf diese Weise erhält Ihr Team einen Gesamtüberblick über das, woran es gerade arbeitet, und es kann Aufgaben priorisieren, um Ihren Kunden früher den größtmöglichen Nutzen zu bieten.

Und das Beste daran: Du kannst dein gesamtes User Story-Mapping in Jira durchführen, sodass sie digital, kollaborativ und für dein Team ständig verfügbar sind — auch wenn sie remote oder verteilt arbeiten. Und da es zu deinem bestehenden Backlog passt, kannst du mit vorgefüllten User Stories sofort loslegen. Mit anderen Worten, Sie können damit rechnen, eine ganze Menge Zeit zu sparen.

Du kannst beginnen Sie noch heute mit Easy Agile User Story Maps for Jira mit einer KOSTENLOSEN 30-Tage-Testversion oder Schauen Sie sich die Demo hier an.

Versuche es jetzt

Hoffentlich finden Sie es genauso nützlich wie unsere Kunden...

Wir haben festgestellt, dass Easy Agile User Story Maps das Team in einem Raum zusammenbringt. Infolgedessen stellen wir fest, dass wir mehr als Gruppe kartografieren, was zu einem gemeinsamen Verständnis führt. Seitdem wir das Add-on verwenden, können wir die Planung beschleunigen und umfangreiche Story-Mapping-Übungen effizienter durchführen.

- Michael Doolittle, Produktdirektor @Priceline

Seitdem wir Easy Agile User Story Maps verwenden, haben wir unsere Kommunikation und Teamausrichtung verbessert, was uns zu schnelleren Ergebnissen verholfen hat.

- Casey Flynn, Analyst für Vertriebsprognosen @adidas

Easy Agile User Story Maps hat uns geholfen, unseren Arbeitsaufwand und unsere Ziele zu visualisieren und unsere Besprechungen zu beschleunigen. Wir lieben die Einfachheit!

- Rafael Zydek, Atlassian Jira und Confluence Expert Administrator @ING Tech Poland

Mit Easy Agile User Story Maps finden wir es viel einfacher, Jira zu verwenden und zu navigieren. Zu unseren Lieblingsfunktionen gehören die Möglichkeit, Storys per Drag & Drop über die Epics zu ziehen, die Möglichkeit, sich die Arbeit mit FixVersion und Sprint Swim Lanes anzusehen sowie der Excel-Export. Wir verwenden die Story Maps-Funktionalität schon seit geraumer Zeit und ich empfehle sie auch anderen Projektteams.

- Sathish K. Mohanraj, Lean-Agile Coach @Equifax

Erfahren Sie mehr über User Story Mapping

Sie möchten mehr über User Story Mapping erfahren? Schauen Sie sich unsere an Ultimativer Leitfaden zum User Story Mapping - es hat alles (und wir meinen alles) das könntest du vielleicht wissen wollen.

Wir freuen uns immer, Ihre Fragen zu beantworten. Schick uns einfach einen Tweet @EasyAgile oder kontaktiere uns wenn Sie sich nicht sicher sind, was User Story Mapping ist, wie das geht oder wie es Ihrem Team helfen könnte.

Geschichtenerzählen ist eine hervorragende Möglichkeit, alles zu beschreiben, weil Geschichten detaillierte Bilder heraufbeschwören. Sobald Sie eine visuelle Assoziation hergestellt haben, werden kognitive Prozesse aktiv, um die Geschichte in der User Journey Map zu einer Realität werden zu lassen, die leicht nachzuvollziehen ist.

Genau darum geht es bei der Customer Journey Map (CJM) — episches Storytelling, das eine umfassende Planung beinhaltet, um den Designprozess zu erfassen und ein einzigartiges Kundenerlebnis zu bieten.

Die Erstellung einer Customer Journey Map (auch User Journey Map genannt) beinhaltet die Planung eines Projekts aus der Sicht des Benutzers und die Verwendung von Personas, Epen, Funktionen, User Stories und Aufgaben. An diesem Visualisierungsprozess sind auch mehrere Stakeholder als Nutzerpersönlichkeiten beteiligt, die auf dem Weg zur perfekten Planung sind.

Am Ende des Projekts sollte Ihr CJM dazu beitragen, Ihre Geschäftsziele zu erreichen und die Kundenerwartungen zu übertreffen. Dabei sollten genügend Kontaktpunkte vorhanden sein, um die Zufriedenheit zu steigern. Der Vorgang ist ein bisschen so, als würdest du Aladdins Lampe reiben, um deine tiefsten Wünsche zum Ausdruck zu bringen.

Was ist die User Journey Map?

Im Gegensatz zum flachen Backlog Karte der Kundenreise lässt die Vision für Ihr Projekt in Echtzeit lebendig werden. Sie können kreatives Storytelling nutzen, um durch visuelle Darstellungen ein magisches Kundenerlebnis zu generieren.

Die Mitglieder des Projektteams erreichen dies, indem sie eine Empathiekarte entwickeln, die aus Kundensicht zu einem fast perfekten Plan führt. Beim User Journey Mapping wird der emotionale Zustand des Kunden erfasst, was bei der Identifizierung von Berührungs- und Schmerzpunkten hilft. Die Teams nutzen diese Punkte dann, um das Kundenerlebnis zu verbessern.

Anstatt die Lampe eines Genies nach Ergebnissen zu reiben, können Sie mithilfe einer praktischen Software einen Serviceplan entwickeln, in dem Design Thinking eine gemeinsame Vision der Stakeholder widerspiegelt.

Der Ausgangspunkt besteht darin, Kundeninteraktionen mit der mobilen App oder anderen E-Commerce-Projektentwicklungsgeschichten zu antizipieren. Aus diesem Grund ist die Nutzerforschung ein weiteres wichtiges Element bei der Entwicklung der Vorlage für eine Customer Journey Map.

Diese Vorlage für eine Customer Journey Map sollte auch wertvolle Informationen aus der Empathy Map und der Experience Map enthalten. Ein tiefes Verständnis der KPIs und Kennzahlen, die beim Storytelling zum Einsatz kommen, hilft dabei, die Benutzerfreundlichkeit des Produkts zu verbessern, indem Kundeninteraktionen mit dem Produkt gewürdigt werden.

Kundeninteraktionen generieren Feedback, das dazu führt, dass die Bedürfnisse des Kunden verstanden werden. Weitere Kontaktpunkte können dann hinzugefügt oder geändert werden, um auf den Gesamtergebnissen des Projekts aufzubauen.

Im Wesentlichen verwenden Sie hierarchisches Storytelling auf einer magischen Vorlage für eine Customer Journey Map, um reale Erwartungen zu erfüllen, die auf das Kundenerlebnis abgestimmt sind.

Die Hierarchie der Customer Journey Mapping

Zu Beginn der Reise zur Schaffung des idealen Kundenerlebnisses sollten die Teammitglieder das Projekt anhand des aktuellen Status des Benutzers visualisieren. Sobald Sie den Kern der aktuellen Kundenperspektive erfasst haben, können Sie besser verstehen, was geändert und verbessert werden muss.

Ein einfaches Beispiel kann eine Reise-App sein, die Dienste wie Reisebürodienste, Flugbuchungen und Unterkünfte in einem geografischen Gebiet (derzeitiger Bundesstaat) umfasst. Der Kunde möchte eine zukünftige App für den Bundesstaat entwickeln, die touristische Aktivitäten enthält, um das Kundenerlebnis zu verbessern. Der grundlegende Prozess wird dann so aussehen:

Für App-Kunden wer wollen Sie ein Mehrwerterlebnis mit unsere Reise-App welche ist ein hilfreiche Ressource Das gibt Tipps zu lokalen touristischen Aktivitäten.

Ihre User Journey Map-Hierarchie umfasst vier Bausteine, um den Bedürfnissen der Kunden gerecht zu werden:

1. User Personas oder Buyer Personas verstehen
2. Entwicklung von Themen und Epen zur Behandlung von Touchpoints
3. Verwendung von Schritten oder Funktionen zur Unterstützung von Epen und des Erzählflusses
4. Die Geschichten auf der Customer Journey Map

1. Nutzer-Personas oder Buyer-Personas verstehen

Die User Journey Map beginnt mit der Definition der Benutzerpersonas oder Käuferpersonas als wichtige Akteure bei der Projektentwicklung. Diese Kundenpersönlichkeiten stehen an der Spitze der Hierarchie, die den Ausgangspunkt der Customer Journey Map darstellt.

Eine detaillierte visuelle Reflexion der Benutzerpersönlichkeit ist entscheidend, um Ihr Endprodukt richtig zu machen. Um dies zu erreichen, müssen Sie die Story-Mapping-Reise aus der Kundenperspektive durchgehen. Dies hilft, die negativen Folgen einer unzureichenden Planung zu vermeiden, die zu suboptimalen Ergebnissen und unzufriedenen Teams und Kunden führt.

Um die Nutzerpersönlichkeiten zu verstehen, müssen Sie anhand von Anwendungsfällen und Feedback die verschiedenen potenziellen Touchpoints auf der Customer Journey und die Schmerzpunkte der Kunden identifizieren. Sie müssen aus Sicht der Buyer Persona so viele potenzielle Szenarien wie möglich antizipieren.

Obwohl das „Wer“, „Was“ und „Warum“ entscheidend für die Definition der User Story sind, beginnt alles mit der Visualisierung der Nutzerpersönlichkeiten und dem Nachdenken über Kundenverhalten, Demografie, Bedürfnisse und Ziele.

Sobald Sie definiert haben, wer Ihre Kundenpersönlichkeiten sind, können Sie anschließend Themen und Epen erstellen, um die Kundenerwartungen zu erfüllen. Die Epen sind die Helden oder Heldinnen dieser Methode zur Visualisierung von Geschichten.

2. Entwickeln Sie Themen und Epen, um Kontaktpunkte anzusprechen

Die Customer Journey Map positioniert Epen ganz oben im Storyboard, da sie für die Erstellung eines großartigen Projekts unerlässlich sind.

Die Teamleiter müssen sich mit dem Kunden und den relevanten Stakeholdern beraten, um ein übergeordnetes Projektthema zu entwickeln, das in Epen umgesetzt wird. Epen durchziehen dieses Thema von links nach rechts. Diese Epen zeigen umfangreiche Arbeiten, die in kleinere Elemente unterteilt sind, die den Wert einer kontinuierlichen Lieferung erfüllen können.

Epen sind auch strategische Richtlinien, die mit dem aktuellen Stand eines Problems beginnen und die Situation in einen wünschenswerten zukünftigen Zustand bringen. Dieser epische Zustand der Zukunft basiert auf Taktiken oder Funktionen und Aufgaben, die die Teammitglieder verwenden, um die Projektanforderungen zu klären und den magischen zukünftigen Zustand des Projekterfolgs zu erreichen.

Bevor die Teammitglieder vorankommen können, müssen sie die richtigen Epen finden. Epics decken drei grundlegende Grundlagen ab: Benutzerpersönlichkeit, Produkt- und Designanforderungen, die sich visuell auf der User Journey Map widerspiegeln.

Die Epen sollten mehrere grundlegende Anforderungen erfüllen:

• Folgen Sie der Umsetzung, indem Sie die allgemeinen Geschäftsziele anhand detaillierter Käuferpersönlichkeiten und demografischer Daten abgleichen
• Umreißen Sie die Bedürfnisse der Benutzerpersönlichkeit im Großen und Ganzen
• Erfüllen Sie spezifische Kundenbedürfnisse, indem Sie Berührungs- und Schmerzpunkte ansprechen
• Schließen Sie bestimmte Funktionen, Merkmale und Vorteile ein
• Produzieren Sie ein zukünftiges staatliches Idealprojekt

Nachdem Sie Ihre Heldenepien so entworfen haben, dass sie die Hauptziele des Projekts abdecken, können Sie damit beginnen, diese in Schritte zu unterteilen, die sich in den gesamten Erzählfluss der User Story integrieren.

3. Verwenden Sie Epen, um den Erzählfluss hervorzuheben

Sobald Sie Ihre Epen klar definiert haben, ist es an der Zeit, engere Schritte oder Merkmale zu generieren.

Während sich Ihre Epen von links nach rechts bewegen, müssen Sie jeden der notwendigen Schritte definieren, um Ihre Geschäftsziele zu erreichen. Dieser anpassbare Prozess verwendet Epics, um die Nutzererfahrung über die gesamte Projektdauer hinweg darzustellen und so die Projektergebnisse widerzuspiegeln.

Die Vorlage für eine Customer Journey Map bildet auch die Grundlage für die ideale User Story beim Übergang von Epics zu Features. Die Features stammen aus den Epen, weshalb die Epen in dieser Geschichte die Helden sind. Sie „retten“ Kunden durch hervorragende Planung und hervorragende Ergebnisse.

Auf der grundlegendsten Ebene sollten die Funktionen die folgenden Elemente enthalten:

• Leistungen, die einen Mehrwert bieten und die Fertigstellung von Epics unterstützen
• Generieren Sie Geschäftswert, indem Sie KPIs, Kennzahlen, Kundengewinnung und Kundenbindung berücksichtigen
• Demonstrieren Sie eine ausreichende Definition, damit die Teammitglieder die Zeitschätzungen einhalten und Aufgaben innerhalb von ein bis drei Sprints erledigen können
• Teammitglieder müssen in der Lage sein, die Ergebnisse ihrer Funktionen zu testen
• Legen Sie Testkriterien für jede Funktion fest, um akzeptable Qualitätsstandards festzulegen, die den Kundenerwartungen entsprechen, bevor Sie mit dem nächsten Schritt fortfahren.

Kurz gesagt, die Benutzerakzeptanzkriterien (UAC) in der User Journey Map sollten eine kurze Beschreibung des Artikelwerts, eine Erläuterung der Funktionsvorteile und die Punkte enthalten, die die Teammitglieder erreichen müssen, um die Qualität der Funktionen zu erreichen.

Erst wenn Sie diese Details auf den Punkt gebracht haben, können Sie die User Stories aus Kundensicht erzählen. Ebenso können Sie sich erst, wenn Sie diese drei grundlegenden Bausteine der Customer Journey Map abgeschlossen haben, auf Nutzerberichte und Geschäftsziele konzentrieren, zu denen auch Kundenzufriedenheit und Kundenbindung gehören.

4. Beginnen Sie mit dem Storytelling anhand der User Journey Map

Nach dem dritten Schritt in der Hierarchie der User Journey Map wird der eigentliche Anwenderberichte beginnen. Dies ist der letzte Schritt im Design Thinking, der sich auf die Visualisierung von Epen in überschaubare Geschichten und Aufgaben bezieht.

Um die Buyer Persona zu formulieren, müssen die Teammitglieder das „Wer“, „Was“ und „Warum“ des Kundenerlebnisses verstehen. Das Verständnis und die Definition der Kundenpersönlichkeiten bilden die Grundlage für die Erstellung von User Storys und ermöglichen die Bereitstellung eines möglichst akzeptablen Produkts.

Um die beste Story zu entwickeln, müssen Benutzerberichte erstellt werden, die das Kundenerlebnis hervorheben, und Anwendungsfälle, die die Systemleistung im Detail hervorheben.

In der Phase der Story-Erstellung nehmen die Teammitglieder die Perspektive des Kunden ein, um Anfragen zu definieren. Teammitglieder können erwägen, soziale Medien zu nutzen, um das Verhalten und die Erfahrungen der Kunden zu verstehen und sie als Input für Geschichten zu verwenden. User Stories können auch Enabler-Aufgaben beinhalten, um die Fertigstellung von Funktionen zu verbessern.

Teammitglieder schreiben in der Regel ihre User Stories, um diese in kurzen Sprints abzuschließen. Beim Abschluss eines Sprints müssen Aufgaben bis zur Veröffentlichung abgeschlossen werden, bevor ein Epic abgeschlossen und zum nächsten übergegangen wird, es sei denn, paralleles Arbeiten ist möglich.

Letztlich muss die User Journey Map die Geschichte des Kunden darüber erzählen, wie seine Bedürfnisse durch die Erstellung oder Änderung eines Produkts, eines Prozesses, einer Dienstleistung oder einer Systemfunktion erfüllt werden. Neue Entwicklungen müssen nach der Formel „als...“, „Ich will...“, „damit...“ umgesetzt werden

Als neues Agile-Teammitglied, ich will um meine Rollen und die anderer Teammitglieder zu verstehen damit Ich bin mir über meine Aufgaben und die Verantwortlichkeiten anderer Teammitglieder im Klaren.

Nach der Generierung von User Stories können die Teammitglieder Aufgaben in noch kleinere Teile unterteilen, um die Arbeitsergebnisse zu erleichtern und potenzielle Abwanderungen zu reduzieren, die sich negativ auf die Kundenbindung auswirken.

Im weiteren Verlauf der User Journey Map sollten die Storys die zu erledigenden Aktivitäten klar umreißen und diese stets mit den Zielen der Buyer Persona verknüpfen. Die kleineren, detaillierten Aufgaben beziehen sich dann auf das Nutzerverhalten. Die Ergebnisse sind mit jedem Schritt des Prozesses verknüpft, um zu ermitteln, welche Leistungen die Kundenanforderungen innerhalb eines festgelegten Zeitrahmens erfüllen.

Während der Customer Journey Map können die Geschichten weiter aufgeteilt werden, um für mehr Klarheit zu sorgen.

Fazit: Die Customer Journey Map

Während des Customer-Journey-Mapping-Prozesses sollten Sie die wichtigsten Aspekte der Nutzerreise in der Story-Map-Visualisierung festhalten.

Sie müssen die User Story Map ganzheitlich entwickeln und sie iterativ durch Additionen und Subtraktionen unterbrechen. Dieser iterative User-Story-Mapping-Prozess trägt dazu bei, die Fluktuation zu minimieren, während Sie Ihre Story im Laufe der Zeit aktualisieren.

Sobald das Projekt abgeschlossen ist, müssen Sie das Produkt an potenziellen Kunden testen, Kundenfeedback einholen und die User Journey Map verbessern.

Die Vorteile einer sorgfältigen Planung des Kundenerlebnisses mithilfe eines visuellen Formats sind exponentiell.

Erzählen Sie Ihre Projektgeschichte mit Easy Agile User Story Maps for Jira

Die Kundenreise sollte das ideale Nutzererlebnis hervorheben. Um dies zu erreichen, sollte die User Story Map das Projekt der Nutzerpersönlichkeiten einbeziehen. So entstehen Geschichten mit wertvollen Touchpoints als Wegweiser.

Sobald die visuelle Darstellung abgeschlossen ist, sollte sie den Serviceplan für den Prozess der Customer Journey Mapping anhand des aktuellen und zukünftigen Status des Projekts validieren.

Während des gesamten Projekts sollte Ihr Team eine einzigartige Benutzererfahrung schaffen, die das ultimative Kundenerlebnis bietet und die Kundenerwartungen übertrifft.

Testen Sie Easy Agile Teamrhythmus und Personas heute, um die Geschichten Ihrer Kunden mit Magie zum Leben zu erwecken.

Das bemerkenswerte Zitat von Alistair Cockburn, Mitautor des Agiles Manifest, lautet: „Eine Benutzergeschichte ist für einen Anwendungsfall wie eine Gazelle für einen Pavillon.“ Dies wirft ein Licht auf die immensen Unterschiede zwischen Anwendungsfällen und User Stories für agile Teams. Sie mögen im Namen ähnlich klingen, sind aber sehr unterschiedlich und werden oft in völlig unterschiedlichen Branchen verwendet.

Sowohl Use Cases als auch User Stories helfen Teams zwar dabei, die Arbeit zu planen und zu ermitteln, was für die Erledigung der Arbeit erforderlich ist, aber das Format, in dem sie verwendet werden, ist ganz anders. User Stories sind einfache, kurze Beschreibungen aus Kundensicht. Sie sind der Beginn eines größeren Prozesses, der die Aktionen eines Kunden beschreibt, wenn er Ihr Produkt verwendet oder mit ihm interagiert. Anwendungsfälle enthalten viel mehr Kontext. Die Erstellung detaillierter Anwendungsfälle ist ein viel detaillierterer Prozess, der Teams helfen soll, zu verstehen, wie ein Benutzer oder Kunde mit einem System interagiert. Im Folgenden werden wir uns eingehender mit diesen beiden Prozessen befassen.

Wenn Sie in der agilen Softwareentwicklung tätig sind, sind Sie wahrscheinlich besser mit der Verwendung von User Stories vertraut. In diesem Beitrag werden wir uns eingehender mit den Unterschieden zwischen Anwendungsfällen und User Stories befassen, einschließlich der Gründe, warum die heutigen Entwicklungsteams zu User Stories übergegangen sind und warum es immer noch triftige Gründe für die Verwendung von Anwendungsfällen im Entwicklungsprozess gibt.

Was ist der Unterschied zwischen Use Cases und User Stories?

Use Cases vs. User Stories: Was ist der Unterschied und wie entscheiden Sie, was für Ihr Team und Ihren Entwicklungsprozess am besten ist?

Anwendungsfall vs. User Story: Vergangenheit und Gegenwart

Anwendungsfälle waren viele Jahre lang der Standard und wurden häufig in der Geschäftsanalyse, Systemanalyse, Softwareanforderungen und iterativen Entwicklung verwendet. Mit dem Aufkommen der Agilität begannen Softwareprojekte, User Stories anstelle von Anwendungsfällen zu bevorzugen, da sie ein verbessertes inkrementelles Denken und eine bessere Agilität ermöglichten.

Was ist ein Anwendungsfall?

Ein Anwendungsfall ist eine Beschreibung aller Arten, wie ein Benutzer möglicherweise mit einem System, einem Gerät oder einem Gerät interagieren möchte. Sie beschreiben, wie das Systemdesign auf Anfragen des Endbenutzers, der allgemein als Akteur bezeichnet wird, reagiert. Bei diesen Akteuren kann es sich um Menschen oder andere Systeme handeln.

Nehmen wir zum Beispiel eine Online-Shopping-Website und einen Lieferservice für Lebensmittel. Ein Kunde, der eine Bestellung aufgibt oder überprüft, ob ein Restaurant geöffnet ist, sind zwei verschiedene Anwendungsfälle. Oder, was die weniger technische Seite angeht, ziehen Sie einen Toaster in Betracht. Nehmen wir an, jemand (der Schauspieler) möchte seinen Bagel nur auf einer Seite geröstet haben. Die Wahl der Toastereinstellung „Bagel“ ist ein Anwendungsfall.

Anwendungsfälle helfen Teams dabei, die verschiedenen funktionalen Anforderungen zu strukturieren und den Umfang des Projekts festzulegen — was bedeutet, dass sie voller Details sind.

Zu diesen Angaben gehören:

• Das Ziel des Anwendungsfalls
• Ob der Schauspieler ein Mensch oder ein anderes System ist
• Vorbedingungen oder der Zustand, in dem sich das System befinden muss, damit der Anwendungsfall eintritt
• Die reguläre Reihe von Schritten, die das System ausführen wird
• Alternative Wege, die das System einschlagen könnte
• Nachbedingungen — Aktionen, die das System am Ende des Anwendungsfalls ergreift, oder in den verschiedenen Zuständen, in denen sich das System nach Abschluss des Anwendungsfalls befinden könnte

Stellen Sie die Einstellung „Bagel“ auf einem Toaster ein.

• Titel/Ziel des Anwendungsfalls: Bagel-Einstellung
• Schauspieler/Nutzer: Das ist jemand, der seinen Bagel gerne nur auf einer Seite geröstet mag.
• Vorbedingungen: Es muss eine „Bagel“ -Funktion/Taste geben.
• Reguläre Schritte/Standardpfad: Der Schauspieler schneidet seinen Bagel in zwei Hälften und legt jede Hälfte in den Toaster. Sie drücken den Hebel nach unten, um den Bagel zu rösten. Dann drücken sie den Knopf mit dem Titel „BAGEL“ und warten darauf, dass ihr Bagel so geröstet wird, wie sie es möchten.
• Alternative Wege: Der Schauspieler vergisst möglicherweise, die Einstellung „Bagel“ zu aktivieren, was zu einer schlechten Benutzererfahrung führt.
• Postbedingungen: Der Toaster kehrt in seinen normalen Zustand zurück (Bageleinstellung nicht eingestellt).

Was ist eine User Story?

Eine User Story ist das Wer, Was und Warum eines Ziels oder Ergebnisses, das der Nutzer oder Kunde erreichen möchte. Es ist das kleinste Stück Arbeit, das dem Kunden einen Mehrwert zurückgeben kann. Es ist aus der Sicht des Endbenutzers geschrieben, oft auf einer Karteikarte.

Hier ist ein Beispiel dafür, wie eine User Story typischerweise geschrieben wird: „Als [Personatyp] möchte ich [handeln], damit [davon] [profitiert].“

Eine User Story ist so konzipiert, dass sie so einfach wie möglich ist, sodass sowohl das Team als auch die Stakeholder nicht viel Fachjargon dekodieren müssen. Das heißt aber nicht, dass der Prozess zur Erstellung einer User Story einfach ist. Viele Informationen werden in einem einzigen Satz zusammengefasst. Und bevor das Team eine User Story schreibt, muss das Team zunächst ihre identifizieren und erstellen Benutzerpersönlichkeit und stellen Sie alle Produktanforderungen zusammen

Nick Muldoon, Mitbegründer von Easy Agile beschreibt User Story Mapping als „ein moderiertes, kuratiertes Gespräch, das alle mit auf die Reise nimmt“.

Ein Projekt oder Produkt, das in einer agilen Umgebung entwickelt wurde, beinhaltet viele User Stories, die jeweils zu den Produkt-Backlog. Dort können sie auf einer User Story Map entsprechend dem geplanten Release oder Sprint angeordnet und priorisiert werden.

Anwendungsfälle vs. User Stories: Die Argumente für Anwendungsfälle

Anwendungsfälle sind in der agilen Entwicklung zwar weitaus seltener, bieten jedoch einige Vorteile, die es zu berücksichtigen gilt. Schließlich bedeutet der wahre Geist der Agilität, dass Sie Ihre Annahmen hinterfragen und neue Methoden ausprobieren.

1. Anwendungsfälle bieten eine Zusammenfassung und ein Planungsgerüst

Anwendungsfälle bieten allen Beteiligten, wie Managern, Führungskräften, Produktverantwortlichen, Entwicklern oder Interessenvertretern, eine Zusammenfassung dessen, was das System bieten wird. Welchen Beitrag wird das System für die Benutzer und das gesamte Unternehmen leisten? Sie bieten ein Planungsgerüst, das Teams dabei hilft, Prioritäten zu setzen, den Zeitplan abzuschätzen und Maßnahmen auszuführen.

2. Anwendungsfälle bieten Kontext für jede Anforderung

Der Anwendungsfall bietet genügend Details und Kontext, um sicherzustellen, dass alle auf derselben Seite sind. Es ist eine Vereinbarung zwischen den Teammitgliedern darüber, was das System tun wird und was nicht.

3. Anwendungsfälle geben einen Ausblick darauf, was die Arbeit verlangsamen könnte

Der Abschnitt mit alternativen Pfaden in den Anwendungsfällen bietet einen erweiterten Überblick darüber, was schief gehen könnte. Kleine Engpässe können eine Menge Zeit und Geld kosten. Je früher Sie diese Probleme erkennen und beheben können, desto besser.

4. Anwendungsfälle geben Antworten auf bestimmte Probleme und Szenarien

Anwendungsfälle beantworten die spezifischen Fragen, die Entwickler oder Programmierer unterwegs haben könnten. Der Anwendungsfallprozess stellt sicher, dass alle Fragen zu Problemen oder möglichen Szenarien zu Beginn beantwortet werden, bevor diese Fragen die Arbeit behindern oder den Fortschritt eines Teams verlangsamen.

5. Anwendungsfälle bieten ein Modell, um alle Aspekte vollständig zu durchdenken

Das Anwendungsfallmodell stellt sicher, dass Entwickler alle Aspekte der Entwicklung vollständig durchdacht haben. Anwendungsfälle befassen sich detailliert mit den Benutzeranforderungen, Systemzielen, möglichen Problemen und verschiedenen Geschäftsvarianten.

Anwendungsfälle im Vergleich zu Anwenderberichten: Fazit

Also, Anwendungsfälle im Vergleich zu User Stories? Wie entscheiden Sie, was für Ihr Team besser ist? Wenn Sie viel Erfahrung mit agilen Projekten und der Arbeit in agilen Teams haben, kennen Sie den unbestreitbaren Wert von User Stories. Sie vermitteln, was der Benutzer oder Kunde erreichen möchte, sodass die Teams stets die Bedürfnisse des Benutzers berücksichtigen.

Obwohl Anwendungsfälle etwas veraltet sind, können sie den dringend benötigten Kontext zur Verwendung eines Systems liefern. Sie beschreiben, wie ein Benutzer mit einem System interagiert, und beantworten viele Fragen im Voraus, um die Verwaltung komplizierter Prozesse zu erleichtern. Außerdem wäre es nicht sehr agil, eine Lösung zu ignorieren, nur weil Sie sie noch nie ausprobiert haben. 😉

Verwenden von Easy Agile TeamRhythm

Wir entwickeln mit Leidenschaft Tools, die agilen Teams helfen, besser zusammenzuarbeiten. Einfacher agiler Teamrhythmus wurde entwickelt, um Produktbesitzern und Entwicklungsteams dabei zu helfen, Kunden schnell und häufig einen Mehrwert zu bieten. Mithilfe von User Story Mapping, Backlog-Refinement, Sprint-Planung und Team-Retrospektiven können Sie Ihre Arbeit direkt von der User Story Map aus planen und verwalten und dann als Team zusammenkommen, um umsetzbare Erkenntnisse auszutauschen, die Ihnen helfen, jedes Mal besser zusammenzuarbeiten.

TeamRhythm lässt sich nahtlos in Ihre agilen Boards in Jira integrieren, sowohl für Scrum- als auch für Kanban-Methoden. Probieren Sie es selbst in unserer Sandbox-Demonstration aus; keine Anmeldung oder Installation erforderlich.

Egal, ob du deine erste User Story Mapping-Session planst oder schon ein paar hinter dir hast, es kann ein wenig überwältigend sein 🤯

• Was ist der Prozess?
• Wen brauche ich, um mich zu engagieren?
• Warum beschäftigen wir uns überhaupt damit, wenn wir einen sehr guten Backlog haben? (Okay... es könnte etwas dysfunktional sein, aber du weißt schon...)
• Warum gibt es ÜBERALL Haftnotizen?

Die meisten Produktmanager und Agile-Teams könnten von einem tieferen Verständnis des User Story Mappings profitieren, damit sie mehr erstellen können kundenzentrierte Sichtweise von der Arbeit, die erledigt werden muss.

Außerdem haben sich in den letzten 15 Jahren (seit User Story Maps dank Jeff Patton zu einem Ding wurden) einige der Prozesse und Begriffe weiterentwickelt, und es gibt neue Tools und Apps, die Ihnen das Leben um ein Vielfaches erleichtern können.

Wir haben diesen ultimativen Leitfaden mit allen Informationen zusammengestellt, die Sie benötigen, um sich über die neuesten Definitionen, Techniken und Tools für das User Story-Mapping auf dem Laufenden zu halten. Fangen wir mit ein paar Grundlagen an 👇

Was ist User Story Mapping?

Hier ist eine supereinfache Definition für das User Story Mapping:

Das User Story Mapping ist eine Visualisierung der Reise, die ein Kunde mit einem Produkt von Anfang bis Ende unternimmt. Es umfasst alle Aufgaben, die sie normalerweise im Rahmen dieser Reise erledigen würden.

Um das zu erweitern, nimmt das User Story Mapping all Ihre User Stories (über alle Ihre Personatypen hinweg) und ordnet sie in der Reihenfolge den Epen zu, die dem Kunden den größten Mehrwert bieten. Von dort aus werden die Geschichten priorisiert und den Releases zugeordnet.

„Das User Story Mapping ist ein moderiertes, kuratiertes Gespräch, das alle mit auf die Reise nimmt. Es ist eine Gelegenheit für den Produktmanager, seine Erkenntnisse (der Tag für Tag tief in diesem Zeug steckt) zu analysieren und sie in den Köpfen des Teams zu verankern, das im Begriff ist, sie umzusetzen.“

Nicholas Muldoon, Mitbegründer @Easy Agile

Was ist kein User Story Mapping?

User Story Mapping hat zwar einige Gemeinsamkeiten mit anderen Methoden, ist aber nicht dasselbe wie Journey Mapping oder Event Storming.

User Story Mapping im Vergleich zu Journey Mapping

Journey Mapping ist ein UX-Tool, mit dem Teams die Reise visualisieren können, die ein Kunde unternehmen muss, um ein Ziel zu erreichen. Journey Maps konzentrieren sich auf die Reise einer einzelnen Persona oder eines einzelnen Kunden, basierend auf dem spezifischen Szenario und den Erwartungen der Persona. Dies ist nützlich, um das Team aufeinander abzustimmen, es auf das Nutzererlebnis zu konzentrieren und Entscheidungen zu treffen. Im Gegensatz zum User Story Mapping konzentriert es sich auf das Nutzererlebnis und die Vision für das Produkt.

User Story Mapping im Vergleich zu Event Storming

Beim Event Storming wird ein Workshop abgehalten, an dem wichtige Unternehmensvertreter teilnehmen. Die Teilnehmer notieren Geschäftsereignisse (Dinge, die passieren), Befehle (Dinge, die die Ereignisse auslösen) und Reaktionen (Dinge, die in der Folge passieren) auf Haftnotizen. Diese Notizen sind sequentiell angeordnet, um die Geschäftsprozesse abzubilden. Im Gegensatz zum User Story Mapping, bei dem der Schwerpunkt auf der Verfeinerung des Backlogs liegt, um dem Nutzer ein funktionierendes Produkt zu liefern, ist Event Storming eher übergeordnet und erfolgt zu Beginn des Produktplanungsprozesses.

User Story Mapping für agile Teams

User Story Maps können für alle agilen Teams nützlich sein, unabhängig davon, ob sie voll SAFe oder Kanban sind, aber vor allem, wenn sie an einem komplexen Produkt arbeiten.

Das User Story Mapping ist eine nützliche Technik für agile Softwareentwicklungsteams, da es Ihrem Team helfen kann, funktionierende Software bereitzustellen und auf Veränderungen zu reagieren.

Das passt genau zum Agilen Manifest.

Und vergessen wir nicht das Agile-Prinzip Nummer eins:

„Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.“

Beim User Story Mapping steht der Nutzer im Mittelpunkt. So wird sichergestellt, dass das Backlog Geschichten enthält, die dem Kunden einen echten Mehrwert bieten, indem sie ihm helfen, seine Ziele zu erreichen. Darüber hinaus ermöglicht das Story-Mapping Ihrem Team, seine Arbeit so zu planen und zu ordnen, dass sie den Kunden zuerst den höchsten Mehrwert bietet.

Da es bei Agile außerdem darum geht, Veränderungen anzunehmen und entsprechend einem konkreten Plan darauf zu reagieren, ermöglichen Storymaps eine effizientere Anpassung. Es ist viel einfacher, Haftnotizen auszutauschen, als umfangreiche Anforderungsdokumente zu überarbeiten. Diese Flexibilität stellt sicher, dass Ihr Team Prioritäten schnell anpassen und Pläne ändern kann, wenn neue Informationen oder Änderungen hinzukommen, wobei die Ausrichtung an den Agile-Prinzipien gewahrt bleibt.

Die Anatomie einer User Story Map

Nutzergeschichten, Epen, Backbone und Story-Mapping — oh mein Gott! Um die Schritte und Prozesse beim User Story Mapping weiter aufzuschlüsseln, definieren wir einige der einzelnen Bestandteile.

Geschichten von Nutzern

Eine User Story ist ein Ziel, aus der Sicht des Benutzers oder Kunden. Es ist ein Ergebnis, das sie wollen. Es ist auch die kleinste Arbeitseinheit in einem agilen Framework mit dem Ziel, zu formulieren, wie eine Arbeit dem Kunden einen Mehrwert bringt.

User Stories folgen normalerweise der Struktur:

Als [Personentyp], Ich möchte [Aktion] damit [profitieren].

Zum Beispiel:

Tipp: Es ist eine gute Idee, sich während der User Story Mapping-Sitzung auf nur einen Nutzer/eine Persona zu konzentrieren. Wenn es Ihre erste Sitzung ist, wählen Sie Ihren idealen Kundentyp aus und schreiben Sie unsere User Stories, die für sie einen Mehrwert bieten. Sie können in Zukunft jederzeit zu Ihren anderen Benutzern zurückkehren.

Lesen ➡️ Wie man gute User Stories in der agilen Softwareentwicklung schreibt.

Epen

Geschichten können mit Epen in Verbindung gebracht werden.

Epen haben unterschiedliche Bedeutungen, je nachdem, mit wem Sie sprechen. In diesem Artikel definieren wir Epen jedoch als größere, übergreifende Geschichten oder Etappen der Reise, die Nutzergeschichten enthalten. Ein Epos allein ist nicht klein genug, um zu einem Arbeitselement oder einer Entwicklungsaufgabe zu werden, aber die Geschichten, die es enthält, sind es wahrscheinlich.

Zum Beispiel könnte das epische „Sign up“ die folgenden Nutzerberichte enthalten:

• Als Kunde möchte ich die Datenschutzbestimmungen lesen, bevor ich mich für mein Konto anmelde, damit ich entscheiden kann, ob ich dem Unternehmen meine Daten anvertraue
• Als Kunde möchte ich auf der Anmeldeseite eine Liste mit Funktionen und Vorteilen sehen, um mich daran zu erinnern, wofür ich mich anmelde
• Als Kunde möchte ich mich mit meinem Facebook-Login für ein Konto anmelden, damit ich mir meinen Benutzernamen oder mein Passwort nicht merken muss
• Als Kunde möchte ich mich mit meiner E-Mail-Adresse für ein Konto registrieren, damit ich den Zugriff auf meine Daten kontrollieren kann
• Und in diesem Beispiel könnte das nächste Epos „Mein Profil einrichten und anpassen“ lauten.

Das Rückgrat

Das Backbone ist die oberste Zeile Ihrer User Story Map. Es beschreibt die wesentlichen Funktionen, über die das System verfügen muss.

Ihr Backbone sollte die Kundenreise oder den Prozess von Anfang bis Ende abbilden, einschließlich aller wichtigen Aktivitäten, die der Kunde während der Nutzung Ihres Produkts durchführen wird. Je nachdem, wie Sie Ihr Backbone und Ihre Storymap verwenden, kann es sich um epische Elemente handeln.

Das Rückgrat ist entscheidend, weil es Ihrem Team das „Warum“ hinter der Reise gibt, auch wenn es sich nur auf einen einzelnen Schritt konzentriert. Es beseitigt Unklarheiten darüber, was zu diesem Schritt führen könnte und was darauf folgen könnte, was einen wichtigen Kontext für eine reibungslose Kundenreise bietet.

Mehr zu: Die Anatomie einer User Story Map

Warum User Story Mapping durchführen?

Der Zweck des User Story Mappings besteht darin, sicherzustellen, dass Sie das Problem des Kunden verstehen und dann eine Lösung für dieses Problem finden.

Du wirst die Antwort kennen auf:

• Warum bauen wir das?
• Für wen bauen wir das?
• Welchen Wert wird es ihnen bieten?
• Wann erwarten wir, dass wir das liefern werden?

Dies hilft Ihnen dabei, Ihre Teams aufeinander abzustimmen, den Rückstand zu bereinigen und schneller ein Produkt zu liefern, das Ihre Kunden wollen und benötigen.

John Walpole erklärt der Wert von User Stories wunderschön:

„[Es gibt] eine Technik und ein Tool, auf die ich immer wieder zurückgegriffen habe, wenn ich das Gefühl hatte, dass ein Projekt vom Team vielleicht nicht vollständig verstanden wird oder ich mir Sorgen mache, dass wir am Ende Software ausliefern, die die Kunden nicht begeistert. Das ist meine bevorzugte Technik. Ich glaube, es wird Ihnen helfen, Software zu liefern, die Ihre Kunden begeistern wird.“

Ohne User Story Mapping ist die Wahrscheinlichkeit, dass Ihr Team komplizierte, nicht kundenorientierte Lösungen für ein Problem findet, viel größer.

Das User Story Mapping hilft sicherzustellen, dass sich das Team darüber im Klaren ist, welches Problem der Kunde hat und wie Sie als Team versuchen werden, dieses Problem zu lösen.

So können Sie sich darauf konzentrieren, zuerst die wirkungsvollsten und wertvollsten Teile zu liefern, sodass Sie auf der Grundlage von Feedback iterieren können.

Lesen ➡️ Warum User Story Mapping

Vorteile von User Story Mapping

„User Story Mapping ist die beste Technik, auf die ich gestoßen bin, um innerhalb eines agilen Teams ein gemeinsames Verständnis zu erlangen. Alex Hennecke von Atlassian sprach davon, dass man den Wald sehen kann — und nicht nur die Bäume, direkt vor sich.“

Nicholas Muldoon, Mitbegründer @Easy Agile

User-Story-Maps sind leistungsstarke Tools in der Produktentwicklung, insbesondere wenn es darum geht, riskante Annahmen zu identifizieren und zu verwalten.

Risiko visualisieren

User-Story-Maps bieten einen visuellen Rahmen, der potenzielle Risiken hervorhebt. Durch die Erstellung von Nutzerberichten mit Haftnotizen oder digitalen Alternativen lassen sich leicht Bereiche identifizieren, in denen die Annahmen möglicherweise nicht mit den tatsächlichen Nutzerdaten oder der technischen Machbarkeit übereinstimmen. Diese Visualisierung hilft Teams dabei, Elemente zu identifizieren, die den Zeitplan oder das Budget eines Projekts aus der Bahn werfen könnten.

Priorisierung und Ressourcenzuweisung

Sobald riskante Annahmen identifiziert sind, können Teams mithilfe von User-Story-Maps ihre Prioritäten effektiv neu organisieren. Riskante Elemente können einer niedrigeren Priorität zugewiesen werden, wodurch sichergestellt wird, dass Ressourcen für Ideen bereitgestellt werden, die einen hohen Nutzen bei minimalem Risiko bieten. Diese Strategie stellt sicher, dass die Projekte auf dem richtigen Weg bleiben und sich auf das konzentrieren, was realistisch erreichbar ist.

Förderung schlanker Alternativen

Storymaps ermutigen Teams, zuerst Lean-Alternativen zu erkunden. Durch das Testen einfacherer Ideen mit ähnlichen Wertversprechen können Teams Konzepte ohne nennenswerte Investitionen validieren. Dieser Ansatz ermöglicht Lernen und Iterationen, wodurch die Wahrscheinlichkeit kostspieliger Fehler im späteren Entwicklungsprozess verringert wird.

Förderung der kollaborativen Problemlösung

Das Erstellen und Aktualisieren einer User-Story-Map ist von Natur aus kollaborativ. Es lädt verschiedene Teammitglieder ein, Erkenntnisse einzubringen, was zu umfassenderen Strategien zur Risikoidentifizierung und -bewältigung führt. Durch die Bündelung von Wissen sind Teams besser in der Lage, Annahmen zu berücksichtigen, die andernfalls unbemerkt bleiben könnten.

Wenn Sie diese Verfahren in Ihren Produktentwicklungszyklus integrieren, können Sie Risiken frühzeitig minimieren und einen reibungsloseren Weg von der Idee bis zur Markteinführung sicherstellen.

Das User Story Mapping bietet noch so viele andere Vorteile, wie zum Beispiel:

• Besser planen — Wenn Sie die Nutzerreise im Überblick haben, können Teams das Gesamtbild Ihres Produkts leichter erkennen und alle Risiken, Abhängigkeiten und Blockaden im Voraus erkennen
• Höheres Einfühlungsvermögen — Es zwingt Ihr Team, das Produkt aus der Perspektive Ihrer Nutzer zu betrachten
• Schneller Mehrwert — Den Nutzern häufig neuen Mehrwert zu bieten, ist einfacher, wenn Sie die Storys nach Wert ordnen und sie Iterationen oder Releases zuordnen können
• Realistische Anforderungen — Indem die Nutzerberichte aufgeschlüsselt und visuell abgebildet werden, ist es einfacher, die Arbeit abzuschätzen und zu sehen, wie alle Teile zusammenpassen
• Bessere funktionsübergreifende Zusammenarbeit — Nachdem alle anstehenden Arbeiten geplant sind, können Marketing-, Vertriebs- und andere Teams sehen, wann Sie voraussichtlich neue Funktionen und Updates veröffentlichen werden, sodass sie ihre Marketingkommunikation und Verkaufsgespräche anpassen können (ohne Sie um tägliche Updates zu bitten)

Das User Story Mapping hilft Ihrem Team, das Gesamtbild, das Warum und die gesamte Kundenreise zu verstehen, bevor es sich mit dem Was und Wie befasst.

Lesen ➡️ Verstehen Sie mit agilen User Story Maps, was Ihre Kunden wollen.

‍

Der flache Backlog im Vergleich zum User Story Mapping

Bevor wir das User Story Mapping hatten, hatten wir einen flachen Backlog. Tatsächlich verwenden viele agile Teams immer noch das Flat-Backlog (kein Urteil, ob Sie das sind!). Lassen Sie uns also darüber sprechen, wie das aussieht und wie User Story Mapping diese Praxis verbessert hat.

Lesen ➡️ DEEP: Die 4 Merkmale eines guten Produkt-Backlogs

Was ist ein flacher Backlog?

Im Grunde ist es eine To-Do-Liste. Sie enthält alle Punkte, die Ihr Team erledigen muss, damit es Ihren Kunden einen Mehrwert bieten kann, und zwar von den wertvollsten bis hin zu den für den Kunden am wenigsten wertvollen. Der Backlog kann in aktuelle und zukünftige Sprints aufgeteilt werden, um zu zeigen, welche Ergebnisse voraussichtlich wann geliefert werden.

Aber ich mag unseren Backlog!

Eine einfache Aufgabenliste kann in Ordnung sein, wenn Ihr Produkt einfach ist, Ihr Team klein ist und Ihre To-Do-Liste sehr kurz ist. Die meisten Produkte sind jedoch komplex und mehrere Teams arbeiten daran. Und meistens ist der Backlog riesig (und wächst und verändert sich ständig).

Flache Rückstände sind in großem Maßstab komplex

Wenn Sie Hunderte von Problemen (oder mehr) haben, macht es ein flaches Backlog unmöglich, das Gesamtbild und den umgebenden Kontext zu sehen — was Ihr Team benötigt, um das Backlog zu verfeinern, Abhängigkeiten zu finden und die Arbeit in Releases zu priorisieren. Es kann auch ziemlich überwältigend werden!

• Zu den spezifischen Herausforderungen bei der Nutzung des flachen Backlogs gehören:
• Die Anordnung der User Stories in der Reihenfolge, in der Sie sie erstellen, hilft Ihnen nicht dabei, anderen zu erklären, was das System tut
• Es bietet keinen Kontext oder ein „Gesamtbild“ rund um die Arbeit eines Teams
• Bei einem neuen System hilft Ihnen der flache Backlog nur schlecht dabei, festzustellen, ob Sie alle Geschichten identifiziert haben
• Bei einem flachen Backlog ist die Release-Planung schwierig — wie priorisiert man, was zuerst erstellt werden soll, wenn man eine endlose Liste hat?
• Es ist praktisch unmöglich, das „Rückgrat“ Ihres Produkts zu entdecken

User Story Maps wurden entwickelt, um diese Herausforderungen zu bewältigen und das Backlog neu zu strukturieren, um Kontext hinzuzufügen, die Priorisierung zu erleichtern und den Fokus auf die Bedürfnisse der Kunden zu legen. Es führt die X-Achse ein, wobei sich das Backbone oben befindet, um die Customer Journey zu veranschaulichen, und die User Stories unten.

Wenn Sie von einem flachen Backlog zu mehreren Achsen übergehen, können Ihr Team (und der Rest Ihres Unternehmens) verstehen, welchen Wert wir dem Kunden bieten wollen und wann.

Lesen ➡️ Der Unterschied zwischen einem flachen Produkt-Backlog und einer User Story Map.

Wann wird das User Story Mapping durchgeführt?

Also, wann führt man eigentlich eine User Story Mapping-Sitzung durch?

In der Regel erstellt ein Team zu Beginn eines Projekts oder Produkts gemeinsam eine Storymap. Es kann sich um ein völlig neues Produkt handeln, oder der Produktmanager möchte möglicherweise eine neue Idee oder Funktion als Teil eines bestehenden Produkts verfolgen.

Dazu müssen Sie Fachexperten und Teammitglieder zusammenbringen, um eine Sitzung abzuhalten, in der Sie sich Ihre Personas und die übergreifende Customer Journey ansehen und dann überlegen, wie Sie den Kunden den größtmöglichen Mehrwert bieten können. Anschließend schreiben Sie User Stories für jeden Ihrer Persona-Typen und jeden Schritt der Customer Journey, basierend auf deren Bedürfnissen.

Wie bereits erwähnt, ist es am besten, sich pro Story-Mapping-Sitzung auf einen Personatyp zu konzentrieren, um Verwirrung zu vermeiden. Beginnen Sie also zuerst mit der Persona, die am besten zu Ihrem Produkt passt oder wahrscheinlich den größten Teil Ihrer Zielgruppe ausmacht.

Insgesamt kann der Prozess mehrere Tage oder sogar mehrere Wochen dauern, abhängig von der Komplexität Ihres Produkts (und damit der Anzahl der Schritte in der Customer Journey) und der Anzahl der Personas.

Das Beste aus User Story Mapping herausholen

Wer sollte am User Story Mapping teilnehmen?

Einige Leute, die du vielleicht zu deiner User Story Mapping Party-Session einladen könntest, sind unter anderem deine:

• Fachexperten (ob Product Owner, Produktmanager, Mitglied des Kundenserviceteams oder eine andere Person, die mit dem Kunden interagiert)
• Geschäftsinhaber
• Entwickler
• Tester
• Vermarkter
• UX-Designerin
• Facilitator oder Scrum Master (es ist nützlich, wenn Sie einen anderen Produktmanager beauftragen können, die Sitzung zu moderieren)

Tipp: Versuchen Sie, Ihre Teilnehmerzahl unter 10 zu halten. Verschiedene Perspektiven sind nützlich, aber mehr als das, und es kann schwierig werden, alle zu verwalten und Beiträge von allen einzuholen. Alle Anwesenden sollten in der Lage sein, Einblicke in die Personen/das Produkt/das Unternehmen einzubringen oder abzuschätzen, wie lange die Erledigung der Aufgaben dauern wird.

Abbildung der User Stories

Sobald das Rückgrat aufgebaut ist (und dein Team sich auf die Reihenfolge geeinigt hat), kannst du es mit Fleisch und Tat umsetzen. Unter jedem Element im Backbone findest du die Nutzerberichte (Schritte, Prozesse und Details), die diese Aktivität unterstützen. Dazu gehören Brainstorming und kreatives Denken.

Ermutigen Sie Ihr Team, sich die verschiedenen Optionen vorzustellen, die dem Benutzer zur Verfügung stehen, wie er die einzelnen Schritte im Backbone erleben möchte und welche Maßnahmen er ergreifen könnte. Es kann nicht schaden, zusammen mit Ihrer User-Story-Map eine Prototyping-Sitzung in Papierform durchzuführen, um Ideen im Laufe der Zeit zu simulieren. Oder vielleicht kommt dieser Schritt später, je nach Szenario und Reifegrad Ihres Teams.

Sequenzierung

Anschließend können Sie Ihre User Stories in eine Reihenfolge bringen, um dem Kunden so schnell und konsistent wie möglich den größtmöglichen Mehrwert zu bieten. Platzieren Sie also die wichtigsten Nutzerberichte oben und die unwichtigsten unten.

Linien oder Schwimmbahnen abschneiden

Ihr Team wird sich zusammensetzen und den Arbeitsaufwand für jede User Story besprechen und einschätzen. Danach können Sie Schnittlinien hinzufügen (normalerweise Sprint- oder Versionslinien), um festzulegen, was Ihr Team wann liefern wird. An diesem Punkt könnten Sie einige Geschichten durcheinander mischen, wenn es für den Benutzer sinnvoll ist, sie in derselben Version zu veröffentlichen.

Lesen ➡️ Anatomie einer agilen User Story Map.

Tipps für ein erfolgreiches User Story Mapping

Beziehen Sie die richtigen Leute ein

Es kann schwierig sein, Ihr Team und Ihre Stakeholder zusammenzubringen. Sie sind beschäftigt und haben wahrscheinlich einen Teller voller Verpflichtungen. Aber es lohnt sich immer, alle dazu zu bringen, sich Zeit zu nehmen und von der Tastatur wegzugehen. Das Mapping von User Storys ist wichtig — und Sie benötigen den Input aller Beteiligten, damit Sie:

• Brainstormen Sie Geschichten, priorisieren Sie sie und schätzen Sie sie ein.
• Bringen Sie Ihr Team dazu, sich für deren Umsetzung zu engagieren

Mach Schluss

„Normalerweise habe ich diese Dinge ausgeführt, um zu versuchen, am ersten Tag so viel wie möglich von der Planung, den Personas und dem Backbone zu erledigen. Zu diesem Zeitpunkt sind die meisten Menschen ausgelastet, weil die kognitive Belastung hoch ist. Dann kann das Team weggehen und darauf schlafen. Sobald sie Zeit hatten, darüber nachzudenken, kommen sie mit anderen Ideen für Benutzergeschichten und Gedanken darüber zurück, wie sie die Arbeit machen würden, bevor sie mit der Sequenzierung beginnen.“

Nicholas Muldoon, Mitbegründer @Easy Agile

Sie müssen nicht Ihre gesamte User Story Mapping-Sitzung auf einmal durchführen. Je nach Größe, Komplexität und Phase Ihres Produkts können Sie es möglicherweise auch nicht an einem Tag unterbringen.

Teilen Sie Ihre Sitzung stattdessen in Abschnitte von 2-3 Stunden auf und führen Sie sie über mehrere Tage durch. Sie können die erste Sitzung am Nachmittag und die nächste Sitzung am nächsten Morgen durchführen. Dies hat einige Vorteile:

• Das bedeutet, dass Sie Ihre Stakeholder und Teams nicht über einen längeren Zeitraum zusammenbringen müssen
• Möglicherweise ist es viel einfacher, Ihre Kalender zu koordinieren, wenn Sie Ihre Sitzungen aufteilen.
• Es gibt deinem Team Zeit, über die ursprüngliche Storymap nachzudenken (sie werden sich wahrscheinlich am zweiten Tag eine Million neuer Dinge einfallen lassen, die sie hinzufügen können)
• Dein Team kann nach Abschluss der Sitzung zu Mittag essen und bei Essen und Getränken eine Nachbesprechung machen 🍻🍔🍕

Ein einziger Moderator

Sie möchten zwar, dass Ihr gesamtes Team und Ihre Stakeholder an Ihrer User Story-Mapping-Sitzung teilnehmen, aber Sie möchten nicht, dass jeder die Diskussion vorantreibt (zu viele Köche in der Küche = keine gute Idee). Wählen Sie stattdessen eine Person aus, die die Sitzung moderiert. Manchmal funktioniert es sogar besser, wenn Sie einen Produktmanager aus einem anderen Team auswählen können, der die Dinge leitet.

Keine Telefone/Laptops

Bei persönlichen User-Story-Mapping-Sitzungen darf nur der von Ihnen angegebene Moderator sein Gerät verwenden. Um Ablenkungen zu vermeiden, bitten Sie die Teilnehmer, ihre Telefone und Laptops in einem Stapel an der Tür abzulegen. Auf diese Weise kann Ihr Team bei allen Diskussionen voll anwesend sein.

Beginnen Sie mit Daten und Beweisen

Bevor Sie sich mit dem Mapping von User Story befassen, bringen Sie relevante Daten und Belege mit. All das ist ein großartiger Kontext für das, was kommen wird. Und natürlich können Sie kein User Story Mapping erstellen, wenn Sie nicht genau wissen, wer Ihre Benutzer sind — und was ihre Ziele, Probleme und Bedürfnisse sind.

Erstellen Sie also Ihre Personas, bevor Sie Ihre Customer Journeys aufbauen. Auf diese Weise werden Sie verstehen, wie Ihre Nutzer mit dem Produkt interagieren werden, und Sie werden in der Lage sein, Nutzerberichte zu schreiben, die die Realität genauer widerspiegeln.

Ansätze zur Zuordnung von User Storys

Beispiel für das Mapping von User Storys

Schauen wir uns ein Beispiel für das User Story Mapping an, um Ihnen zu helfen, den Prozess für Ihr eigenes Produkt zu visualisieren.

• Identifizieren Sie das Produkt/das Ergebnis

In diesem Beispiel ist unser Produkt ein kostenloses Online-Lernspiel für Kinder. Das Ergebnis ist, dass der Benutzer das Spiel findet und spielt.

• Führen Sie Aktivitäten auf hoher Ebene auf (in chronologischer Reihenfolge):
• Navigiere zur Spiele-Website
• Loggen Sie sich in Ihr Konto ein (oder registrieren Sie sich, wenn Sie es zum ersten Mal verwenden)
• Suche nach Spiel
• Spiel wählen
• Spiel spielen
• Mit einem Freund oder in sozialen Netzwerken teilen
• Listen Sie Benutzerberichte unter jeder Aktivität auf

Die Suche nach einem Spiel könnte beispielsweise die folgenden Optionen beinhalten:

• Freitextsuche — Als Elternteil möchte ich nach einem bestimmten Schlüsselwort suchen, damit ich schnell zu einem Spiel navigieren kann
• Nach Kategorie durchsuchen: Altersgruppe - Als Elternteil möchte ich ein altersgerechtes Spiel finden, das meine Kinder leicht erlernen können
• Nach Kategorie durchsuchen: Art der Bildung - Als Elternteil möchte ich ein Spiel finden, das meinem Kind hilft, sein Wissen und seine Fähigkeiten in einem bestimmten Bereich zu verbessern
• Nach Kategorie durchsuchen: Spieltyp - Als Elternteil möchte ich ein neues Spiel finden, das einem ähnelt, das meinem Kind bereits gefällt
• Sortiere nach den am besten bewerteten Spielen — Als Elternteil möchte ich ein Spiel finden, das mein Kind wahrscheinlich eine Weile beschäftigt, damit ich etwas Arbeit erledigen kann
• Sortiere nach neuesten/ältesten Spielen - Als Eltern möchte ich meinem Kind helfen, ein Spiel zu finden, das es noch nicht gespielt hat, um ihm ein neues Erlebnis zu bieten
• Sortiere nach den beliebtesten Spielen — Als Elternteil möchte ich meinem Kind helfen, die beliebtesten Spiele zu finden und zu spielen
• Ordnen Sie Geschichten von den für Benutzer am wertvollsten zu den am wenigsten wertvollen

Der Wert wird anhand von Analysen zu Nutzungsmustern, Kundeninterviews und anderen Erkenntnissen ermittelt.

Dein Team überprüft möglicherweise die Feedback-Formulare, um herauszufinden, welche Funktionen von Eltern am häufigsten nachgefragt werden, und priorisiert diese zuerst. Auf diese Weise bieten sie in kürzerer Zeit mehr Wert.

Ordnen Sie die Arbeit so an, dass Sie wissen, was und wann geliefert werden muss

Ihr Team schätzt den Arbeitsaufwand für jede User Story ein und entscheidet, welche Storys Sie für kommende Sprints oder Releases fertigstellen können. Sie können Geschichten gruppieren, die für die Erstellung eines MVP benötigt werden, oder Geschichten, die veröffentlicht werden müssen, zusammen — zum Beispiel könnten alle Funktionen zum Durchsuchen nach Kategorien gleichzeitig veröffentlicht werden.

Teilen Sie es auf Releases oder Sprints auf

Das Team legt deine Schnittlinien fest (für den Sprint oder die Version), sodass sie unterscheiden können, was sie ihrer Meinung nach in diesem Sprint oder dieser Version liefern können. Dies hängt von ihren Kapazitäten ab und davon, was sie den Benutzern bieten müssen, um ein Minimum Viable Product (MVP) zu erreichen.

Eine User Story Mapping... Story

Während seiner Zeit bei Twitter moderierte unser Mitbegründer, Nicholas Muldoon, eine Sitzung für ein anderes Team, dessen Ziel es war, herauszufinden, wie ein Problem mit der App behoben werden sollte. Dieses Beispiel (in Nicks Worten) zeigt eine weitere interessante Anwendung von User Story Mapping, einschließlich der Arten von Problemen, die Sie möglicherweise lösen könnten, und wie Sie sich auf eine bestimmte Persona oder einen Unterbereich Ihrer Zielgruppe konzentrieren können.

Schritt 1: Kick Off

Wir haben damit angefangen, alle ins Zimmer zu holen. Zu den Teilnehmern gehörten mehrere Fachexperten — nicht nur das unmittelbare Team, das an dem Projekt arbeitete. Dazu gehörten jemand aus dem Team für die Benutzerauthentifizierung und ein UX-Designer, der in der Vergangenheit an der Zurücksetzung von Passwörtern gearbeitet hatte.

Der Produktmanager eröffnete die Sitzung mit einer Erläuterung der Situation: „Ein ganzer Teil der Benutzer hat Probleme, in die App zu gelangen, weil sie sich nicht an ihr Passwort erinnern können. Um sie jedoch dazu zu bringen, den langwierigen Prozess zum Zurücksetzen des Passworts zu durchlaufen, wollen wir ihnen zunächst einen Mehrwert bieten, um zu zeigen, dass es sich lohnt. Wie?“

Schritt 2: Identifizierung der Person

Um die nächsten Schritte herauszufinden und das User Story Mapping durchzuführen, mussten wir die Zielgruppe eingrenzen, damit wir sie als Framing-Referenz oder Persona verwenden konnten. Schließlich hatten wir es mit einem riesigen Publikum von 30 Millionen Menschen zu tun, nicht mit einer einzigen Persona.

Also haben wir gefragt: Auf wen zielen wir nicht ab? Dann konnten wir alle Pro-Nutzer und Regierungsnutzer ausschließen, wodurch sich die Zuschauerzahl auf 28 Millionen reduziert hat.

Als nächstes fragten wir: Was ist der einfachste Ort, um das zu experimentieren und zu testen? Zu der Zeit gab es eine Funktion, auf die wir unter IOS nicht zugreifen konnten, also haben wir uns für Android entschieden. Außerdem hatten wir gute Beziehungen zum US-amerikanischen Mobilfunkanbieter AT&T. Deshalb haben wir uns unsere Zielgruppe von Android-Nutzern auf AT&T in den USA angesehen, was uns eine viel vernünftigere Zuschauerzahl von 3 Millionen Menschen bescherte.

Wir haben diese Persona verwendet, um mit dieser speziellen Funktion zu experimentieren, ohne die verschiedenen Anwendungsfälle zu berühren.

Schritt 3: Die großen Schritte

Nachdem wir die Persona skizziert hatten, auf die wir uns konzentrieren würden, konnten wir darüber sprechen, was in oder was draußen ist. Also haben wir über die großen Schritte gesprochen, wie zum Beispiel:

• Sie sind auf dem Android-Startbildschirm
• Sie öffnen die App
• Sie sehen alle Funktionen
• Sie versuchen eine Aktion (Twittern, Liken oder Retweeten)
• Sie führen einen Passwort-Reset durch
• Diese kundenorientierten Epen bilden das Rückgrat der User Story Map.

Außerdem haben wir in dieser Sitzung auch technische Epen für Dinge aufgenommen, die wir von anderen Teams bei Twitter brauchten. Dieses Team hatte zum Beispiel nicht die Kontrolle über die gesamte Authentifizierung, also fügten sie ein technisches Epos hinzu, um ein Gespräch mit einem anderen Team zu führen, um diesen Teil in ihren Backlog aufzunehmen, sodass sie alles hatten, was sie für das Experiment brauchten.

Schritt 4: Die Geschichten

Während wir die Epen ausgearbeitet haben, haben wir die User Stories unter jedem von ihnen ausgearbeitet.

Schritt 5: Linien abschneiden

Normalerweise führte Ihr Team an dieser Stelle Schätzungen durch und schnitt Grenzen ab, aber das war nicht nötig, da das Timing weniger relevant war. Wir mussten alle wichtigen Geschichten einbeziehen, um das Experiment erfolgreich durchführen zu können.

Wir haben unser User Story Mapping physisch auf einem Whiteboard durchgeführt, also haben wir Band verwendet, um zu trennen, was in Sprint eins, zwei und drei hinein- und herauskommt. Wir hatten das Backlog auf der rechten Seite, das aus allem bestand, was wir besprochen hatten und das wir diesmal nicht aufnehmen konnten, auf das wir aber später zurückkommen wollten. Vielleicht passten einige Punkte nicht zu dieser Persona, oder wir würden für IOS darauf zurückkommen.

In anderen Szenarien würden wir die Geschichten danach ordnen, was unserer Meinung nach den meisten Wert bieten würde, schätzen mit Storypoints, und planen Sie dann die Kapazität für eine Woche oder vierzehn Tage Arbeit auf der Grundlage der historischen Geschwindigkeit. Dann würden wir die Geschichten in Sprints und Versionen unterteilen. Bei der Sequenzierung könnte es darum gehen, etwas mit niedrigerem Kundennutzen nach oben zu bringen, weil Sie es anpassen können. Möglicherweise müssen Sie auch eine größere oder riskantere Geschichte aufschlüsseln und sie in zwei Benutzergeschichten aufteilen.

Während des gesamten Prozesses hatte jeder die Möglichkeit, seine Meinung zu äußern (es gibt nichts Frustrierenderes, als nicht gehört oder gehört zu werden), und wir haben sie in den Vorstand aufgenommen. Eine meiner Aufgaben als Moderator bestand darin, alle im Raum zu betreuen — von der ruhigsten Person bis zur kontaktfreudigsten Person.

Wenn jemand still war, würde ich ihn in die Diskussion einbeziehen und ihn direkt nach seinen Gedanken fragen. Es ist wichtig, verschiedene Teilnehmer einzubeziehen, um eine ganzheitliche Vision oder ein ganzheitliches Verständnis zu erhalten. Denn am Ende des Tages besteht der Zweck des User Story Mappings darin, das Team auf den gleichen Stand zu bringen. Wenn sich das Team auf den Weg macht und sich nicht auf die Vision eingelassen hat, werden sie bald feststellen, dass jeder ein anderes Verständnis davon hat, was passieren soll. Es geht weniger um den Prozess als vielmehr um die Ausrichtung des Teams.

Ergebnisse 🏆

Als Ergebnis dieses User Story-Mapping-Prozesses schlug das Projekt eine neue Richtung ein, bei der die App die Gerätekennzeichnung zusammen mit dem Benutzernamen verwendet, um herauszufinden, wer der Benutzer war, bevor er sich anmeldet. Dies würde es ihnen ermöglichen, direkt in die Timeline zu gelangen und daraus einen Mehrwert zu ziehen.

Wenn sie jedoch Aktionen ausführen wollten (wie Twittern, RT oder einen Tweet mit „Gefällt mir“ markieren), mussten sie ein Passwort eingeben (und wären hoffentlich engagiert genug, um den Vorgang abzuschließen). Insgesamt war es eine sehr erfolgreiche User Story Mapping Session!

Physisches versus digitales User Story-Mapping

Nun, da Sie die Schritte beim User Story Mapping kennen, wie implementieren Sie sie tatsächlich?

Traditionell erfolgt das User Story Mapping physisch. Sie bringen Ihr Team in einen Raum, schreiben das Backbone und die Nutzergeschichten auf Haftnotizen, ordnen sie an einer Wand an und verwenden eine Schnur, um die Schnittlinien oder Swimlanes darzustellen.

Es könnte ein bisschen so aussehen:

Dieser Prozess bringt jedoch einige Herausforderungen mit sich:

• Du musst ein Zimmer für einen Tag finden und buchen (oder länger, wenn du eine komplexe Produkt- und Nutzerreise planen musst)
• Wir alle wissen, dass Haftnotizen dazu neigen, ihre Klebrigkeit zu verlieren und von der Wand zu fallen (auch wenn Sie Ihre Peeling-Technik absolut perfektionieren)
• Selbst wenn Sie externe Teammitglieder per Videokonferenz einbeziehen, ist es für sie schwierig, Post-its zu lesen — und natürlich ist es für sie viel schwieriger, Beiträge zu leisten
• Ein Teammitglied muss immer noch alle Daten in Jira eingeben, wenn deine User Story Mapping-Sitzung abgeschlossen ist (er sieht aus wie im folgenden Screenshot, der deiner physischen Story-Map nicht allzu sehr ähnelt).

„Als ich bei Twitter gearbeitet habe, haben sie versucht, über Videokonferenzen eine physische Benutzerstory abzubilden, um Teammitglieder an verschiedenen Orten einzubeziehen. Es war eine Herausforderung. Es würde viel „Hey Nick, was steht da?“ geben. und ich müsste es vorlesen oder im Chat abtippen.“

Nicholas Muldoon, Mitbegründer @Easy Agile

Aus diesem Grund ist es oft besser, ein Tool oder eine App zu verwenden, um Ihr User Story Mapping digital durchzuführen.

Es gibt zwar eine Reihe von Apps und Softwareoptionen für das User Story Mapping, aber der effizienteste Ansatz besteht darin, ein User Mapping Tool zu verwenden, das direkt in Jira integriert ist.

Auf diese Weise musst du deine Arbeit nicht in Jira übertragen — dein Team kann direkt mit der Arbeit an seinen wichtigsten Storys beginnen, sobald du deine Mapping-Sitzung abgeschlossen hast.

Lesen ➡️ User Story Mapping für Remote-Teams

Jira + Einfacher agiler TeamRhythm

Jira alleine erlaubt es dir nicht, User Story Mapping durchzuführen. Es repliziert die physische Sitzung nicht mit Haftnotizen und einer X-Achse. Das Beste, was es tun kann, ist ein flacher Rückstand — und hoffentlich weißt du inzwischen, dass das für die meisten Teams nicht gut genug ist.

Zum Glück kannst du mit Easy Agile TeamRhythm, einem Add-on für Jira, eine digitale und kollaborative Story-Mapping-Sitzung direkt in Jira durchführen.

So funktioniert das:

Funktionen zur Zuordnung von User Storys zu Jira hinzufügen

Hinzufügen Einfacher agiler Teamrhythmus zu deinem Jira-Konto. Du kannst mit einer kostenlosen 30-Tage-Testversion beginnen.

Wenn du TeamRhythm von einem agilen Board aus öffnest, das bereits verwendet wird, wird es automatisch mit den Daten deines Boards gefüllt. Aktuelle Probleme werden dem Backlog-Panel im rechten Bereich hinzugefügt. Aber keine Sorge — du kannst diese Daten ganz einfach bearbeiten. Und wenn es ein neues agiles Board ist, kannst du dein Backbone, deine Storys und Swimlanes ganz einfach von Grund auf neu hinzufügen.

Richte dein Rückgrat ein

Am oberen Rand des Spielbretts erstellst du eine horizontale Reihe von Epen (falls du deinem Board bereits Epen zugeordnet hast, wird diese automatisch ausgefüllt). Jedes Epos steht für eine Aktivität, bei der die Nutzer das Produkt durchqueren. Dies wird oft als das „Rückgrat“ der Storymap bezeichnet.

Diese Epen können per Drag-and-Drop verschoben werden und die Reihenfolge der Epen wird mithilfe des Jira-Rankings im Backlog wiedergegeben.

Mit Easy Agile ist es ganz einfach, neue Epen direkt in der Story-Map zu erstellen. Klicken Sie einfach oben rechts auf dem Bildschirm auf die Schaltfläche „Epic erstellen“. Füge den Namen und die Beschreibung hinzu und klicke dann auf „Erstellen“. Scrolle auf deiner Story-Map ganz nach rechts, um dein neues Epos zu finden.

Machen Sie sich keine Sorgen, dass alles sofort perfekt wird. Sie haben die Möglichkeit, sie später online zu bearbeiten.

Füge das Fleisch hinzu (oder Geschichten!)

Unter jedem Epos auf dem Backbone findest du alle verknüpften User Stories, die nach Rang sortiert sind. Um eine neue Story hinzuzufügen, fahre mit der Maus über den Bereich, in dem du deine Story erstellen möchtest, und klicke auf „Neu“. Gib den Namen deiner Story ein und wähle deinen Problemtyp aus dem Drop-down-Menü aus (z. B. Aufgabe, Story oder Bug). Du kannst auch auf das Backlog-Panel zugreifen, um bestehende Geschichten oder Probleme hinzuzufügen — klicke einfach auf „Bestehend“, suche nach deinem Problem und füge es hinzu.

Sie können Probleme auch aus dem Backlog-Panel hineinziehen.

Und genau wie bei Epen können Sie Ihre Geschichten direkt bearbeiten, indem Sie auf den Namen der Ausgabe klicken.

Bestelle deine Epen und Geschichten

Ordne jetzt deine Epen und Geschichten. Ihre Epen sollten die Reise Ihres Kunden von Anfang bis Ende widerspiegeln. Und Ihre Geschichten sollten nach dem Wert geordnet sein, den sie den Kunden bieten.

In Easy Agile-Apps können Sie Ihre Geschichten und Epen durch Klicken und Ziehen neu anordnen. Und wenn Sie ein Epos verschieben, werden auch die zugehörigen Geschichten darunter verschoben.

Arbeit schätzen

Zeigen Sie mit der Maus auf das Schätzfeld (die graue Zahl am unteren Rand jedes Story-Elements). Klicken Sie hier, um es hinzuzufügen oder zu bearbeiten Storypoints.

Lesen ➡️ Agile Schätzungstechniken

Swimlanes hinzufügen und anordnen (Version/Sprint)

Jetzt ist es an der Zeit zu entscheiden, welche Probleme Ihr Team wann angehen wird, indem Sie die Arbeit horizontal aufteilen. Klicken Sie oben rechts auf die Schaltfläche „Swimlanes“. Sie können wählen, ob Sie die Arbeit nach Sprints oder Versionen sortieren möchten (je nachdem, ob Sie Scrum oder Kanban* sind). Ihre Sprints oder Versionen werden in chronologischer Reihenfolge auf der Story-Map angezeigt. Unten auf der Story-Map befindet sich eine Schaltfläche „Sprint hinzufügen“, über die Ihr Team weitere Sprints und Versionen hinzufügen kann.

* Bei Kanban sequenzieren Sie Ihre Arbeit in der Regel in Versionen, da es keinen Sprint gibt. Dies kann Ihrem Team helfen, die lange Liste von Geschichten in die Bereiche „Jetzt“ und „Zukunft“ zu reduzieren.

Sie können Storys einfach per Drag-and-Drop verschieben und sie der entsprechenden Swimlane zuordnen.

Überprüfe die Teamgeschwindigkeit, um zu vermeiden, dass dein Team bei jedem Sprint oder jeder Version überfordert wird. Bewegen Sie den Mauszeiger über die Indikatoren „Nicht gestartet“, „In Bearbeitung“ und „Fertig“ ganz rechts in der Swimlane des Sprints oder der Version, um zu sehen, wie Ihr Storypoints verfolgen alle Geschichten und Probleme. Wenn du zu viele hast Storypoints, du kannst einige Storys in den nächsten Sprint oder die nächste Version verschieben.

Lesen ➡️ Agile Story Points: Messen Sie Ihren Aufwand wie ein Profi

Probiere verschiedene Ansichten aus

Sie können auf der Grundlage einer Textsuche suchen oder einen Schnellfilter erstellen (enthält z. B. „Als übergeordnetes Objekt“). Oder wenn Sie unser anderes Produkt, Easy Agile Personas, verwenden, haben wir ein Tutorial, wie Sie einen Schnellfilter nach Persona erstellen können. Auf diese Weise können Sie Ihre Story-Map verfeinern und sich auf das konzentrieren, was für Sie wirklich wichtig ist.

An die Arbeit!

Alle während der Story-Mapping-Sitzung vorgenommenen Änderungen werden automatisch in Jira übernommen, sodass dein Team die Story-Mapping-Sitzung verlassen und mit der Arbeit beginnen kann.

Erste Schritte mit Easy Agile TeamRhythm

Easy Agile TeamRhythm funktioniert sofort mit Ihrem vorhandenen Backlog (der Einstieg ist also superschnell und einfach). Aber es gibt dir diese zusätzliche Dimension, die dir hilft, dein Backlog zum Leben zu erwecken. Es ist ein Aliiiiive!

Willst du es selbst ausprobieren? Wir haben zwei Möglichkeiten:

Kostenlose Testversion von Easy Agile TeamRhythm

ODER spielen Sie mit unserer Demo herum (keine Installation oder Anmeldung erforderlich) :-)

TeamRhythm Highlights-Tour

Aber hör uns nicht einfach zu. Hier ist, was einige unserer Kunden zu sagen haben:

Die Jira-Software eignet sich hervorragend, um Aktivitäten und Backlogs zu verfolgen, aber ohne User Story Mapping kann es leicht passieren, dass Sie die Vision Ihres Produkts verlieren. Easy Agile User Story Mapping ermöglicht es den Teams, miteinander zu kommunizieren — nicht nur über Aktivitäten, sondern auch über die Vision des Produkts. Einige unserer Teams nutzen dieses Tool regelmäßig für Rückblicke, und es hilft ihnen, das Produkt zu ihrem Produkt zu machen.

- Paul Flye Sainte Marie, Agile- und Tools-Referent @Kering

Wir haben festgestellt, dass Easy Agile User Story Maps das Team in einem Raum zusammenbringt. Infolgedessen stellen wir fest, dass wir mehr als Gruppe kartografieren, was zu einem gemeinsamen Verständnis führt. Seitdem wir das Add-on verwenden, können wir die Planung beschleunigen und umfangreiche Story-Mapping-Übungen effizienter durchführen.

- Mike Doolittle, Produktdirektor @Priceline

Seitdem wir Easy Agile User Story Maps verwenden, haben wir unsere Kommunikation und Teamausrichtung verbessert, was uns zu schnelleren Ergebnissen verholfen hat.

- Casey Flynn, Analyst für Vertriebsprognosen @adidas

Easy Agile User Story Maps hat uns geholfen, unseren Arbeitsaufwand und unsere Ziele zu visualisieren und unsere Besprechungen zu beschleunigen. Wir lieben die Einfachheit!

- Rafal Zydek, Atlassian Jira und Confluence Expert Administrator @ING Tech Poland

Sehen Sie, worum es bei der ganzen Aufregung geht

Starten Sie Ihre kostenlose 30-Tage-Testversion

Einfacher agiler Teamrhythmus

Psst: Es ist die am schnellsten wachsende und am höchsten bewertete Story-Mapping-App für Jira! Du wirst es lieben.

6 Möglichkeiten, deine Storymap am Leben zu erhalten

Apropos Dinge zum Leben erwecken, wir haben noch ein paar letzte Tipps...

Ihre User Story Map ist so konzipiert, dass sie ein lebendiges, atmendes Ding ist, sodass Ihr Team Ihren Kunden kontinuierlich einen Mehrwert bieten kann. Sie werden diese Vorteile jedoch verpassen, wenn Ihr Team sie nicht kontinuierlich nutzt, darüber nachdenkt und sie verfeinert.

Hier sind 6 Möglichkeiten, wie du deinen Backlog am Leben erhalten kannst:

1. Verfolgung des Fortschritts

Während dein Team Releases veröffentlicht, kann es seinen Fortschritt anhand der User Story Map visuell verfolgen. Mit Easy Agile User Story Maps werden Aktualisierungen in Jira direkt in der User Story Map wiedergegeben, sodass Sie überprüfen können, wie viel Prozent der Arbeit abgeschlossen wurden. Auf diese Weise können Sie Probleme frühzeitig erkennen und die Arbeitsbelastung Ihres Teams (und zukünftiger Versionen/Sprints) bei Bedarf anpassen.

2. Pflege des Backlogs

Der Zweck der Backlog-Grooming besteht darin, einen gesunden, aktuellen Produkt-Backlog aufrechtzuerhalten, der für eine effiziente Sprint-Planung bereit ist. Wenige Tage vor Ihrem Sprint-Planungstreffen wird Ihr Produktmanager:

• Löschen Sie User Stories, die nicht mehr relevant sind
• Erstellen Sie neue User Stories, wenn die Bedürfnisse klarer werden
• Schätzungen zuordnen und korrigieren
• Teilen Sie zu große User-Stories auf
• Schreiben Sie Geschichten um, um sie klarer zu machen
• Stellen Sie sicher, dass die Geschichten nach Priorität sortiert sind
• Stellen Sie sicher, dass die Geschichten oben bereit sind, geliefert zu werden

Es ist viel einfacher, dies mit Easy Agile User Story Maps zu tun (statt mit einem flachen Backlog), da Ihr Produktmanager und Ihr Team alle kontextbezogenen Informationen sehen können. Sie können die Reihenfolge durch Klicken und Ziehen verschieben und Probleme mithilfe der Inline-Bearbeitung schnell aktualisieren.

3. Sprint-/Release-Planung

Die Sprint-Planung erfolgt zu Beginn jedes Sprints. Es soll Ihrem Team helfen, sich auf ein Ziel für den nächsten Sprint und die Reihe von Backlog-Elementen zu einigen, die ihnen helfen, dieses Ziel zu erreichen. Dazu gehört die Priorisierung der Backlog-Elemente (das sollte dank der Backlog-Grooming einfach sein) und sich darauf zu einigen, für welche Aufgaben dein Team während des Sprints Kapazität hat. Sprint-Planungssitzungen laufen in der Regel viel reibungsloser ab, wenn Sie sich auf Ihre User Story Map beziehen. Mit Easy Agile User Story Maps können Sie Ihre Story-Map unterwegs mit Backlog-Elementen aktualisieren. Alle Ihre Änderungen werden in Jira wiedergegeben, sodass Ihr Team sofort mit der Arbeit am Sprint beginnen kann.

4. Sprint-Bewertungen

Am Ende jedes Sprints führt Ihr Team einen Sprint-Review durch, um festzustellen, ob das Ziel erreicht wurde und ob Ihre Erhöhung zu einer funktionierenden, versandfähigen Produktversion geführt hat. Ihr Produktmanager wird sich die Punkte „Erledigt“ aus dem Backlog ansehen, und das Entwicklungsteam wird Ihnen die geleistete Arbeit demonstrieren.

Das Team spricht darüber, was gut gelaufen ist, welche Probleme es gibt und wie sie gelöst wurden oder gelöst werden könnten. Sie überprüfen den Zeitplan, das Budget und die potenziellen Funktionen für die nächste geplante Produktveröffentlichung, wodurch die Vorbereitungen für die nächste Sitzung zur Rückstandsbereinigung und Sprint-Planung in Gang gesetzt werden.

In Easy Agile User Story Maps können Sie Ihre Ansicht ganz einfach filtern, um „erledigte“ Probleme anzuzeigen, Sprint-Statistiken einzusehen und Story-Point-Schätzungen zu aktualisieren. Auf diese Weise können Sie direkt in Jira ein schnelles und kollaboratives Sprint-Review-Meeting abhalten.

5. Straßenkarten

Sie können Ihre Storymap verwenden, um Ihre Roadmap mit Stakeholdern zu kommunizieren und die Produktvision zu teilen. Nachdem Ihre bevorstehenden Releases und Sprints geplant sind, können Sie leicht erkennen, welche Teile der Kundenreise aktualisiert oder verbessert werden sollen und wann.

6. Rückblicke

Retrospektiven finden oft am Ende Ihres Sprints oder Releases statt. Oder Sie veranstalten sie nach einer Veranstaltung, einer Präsentation, jeden Monat oder jedes Quartal. Retros helfen Ihrem Team dabei, darüber nachzudenken, was gut gelaufen ist, was besser hätte laufen können und was es beim nächsten Mal anders machen würde. Ihre User Story Map kann Ihrem Team bei Rückblicken einen visuellen Bezugspunkt bieten und ihnen helfen, sich auf den Nutzer zu konzentrieren.

So erfahren Sie mehr über User Story Mapping

Wir sind fast am Ende, aber hören Sie hier nicht auf! Es gibt noch so viel mehr zu lernen, wenn du tiefer in das Thema User Story Mapping einsteigen willst.

Hier sind einige Ressourcen, die einen Blick wert sind:

Bücher zum Mapping von Nutzergeschichten

Jeff Patton hat DAS Buch über User Story Mapping geschrieben, genannt User Story Mapping: Entdecke die ganze Geschichte, baue das richtige Produkt. Jeff war der ursprüngliche User Story Mapper — zumindest wird ihm die Erfindung des Konzepts und der Praxis zugeschrieben.

Artikel zum Mapping von User-Storys

Hier sind einige Artikel, die wir in den letzten Jahren geschrieben haben:

Story Maps — Ein visuelles Tool für kundenorientierte Entwicklung (dieses hat ein großartiges Video)

Wie schreibt man gute User Stories in der agilen Softwareentwicklung

Der Unterschied zwischen einem flachen Produkt-Backlog und einer User Story Map

Anatomie einer agilen User Story Map

Das war's! Du hast den ultimativen Guide zum User Story Mapping fertiggestellt! 👏

Sie haben alle Tools und Informationen, die Sie benötigen, um...

• Führen Sie Ihre erste User Story Mapping-Sitzung durch
• Führen Sie das Story-Mapping effektiver (und selbstbewusster) durch
• Holen Sie mehr aus Ihrer Story-Map heraus
• Priorisieren Sie Ihre Arbeit, um Ihren Kunden so schnell und so oft wie möglich den größtmöglichen Nutzen zu bieten
• Arbeiten Sie kollaborativer
• Planen Sie Ihre Arbeit genau
• Verstehe das Warum hinter der Arbeit

Geh raus und Storymap! Und lass uns wissen, wie es dir geht.

Wenn Sie Fragen zu User Story Maps haben, würden wir uns freuen, von Ihnen zu hören. Sie können kontaktiere uns oder sende uns einen Tweet @EasyAgile. Wir werden diesen Leitfaden aktualisieren, sobald wir auf weitere Tipps, Techniken und häufig gestellte Fragen zum Thema User Story Mapping stoßen.

Im vergangenen Mai präsentierte John Walpole von Twitter auf der Facebook-Veranstaltung für technische Programmmanager im Silicon Valley Story Maps: Ein visuelles Tool für kundenorientierte Entwicklung. Und unser Produkt, Easy Agile User Story Maps for JIRA, erhielt einen Shoutout — danke John!

Schau dir jetzt John's Lightning Talk an:

John Walpole ist technischer Programmmanager bei Twitter in San Francisco. Bevor er zu Twitter kam, war er als Ingenieur, Produkt- und Programmmanager an den Xbox-, Azure- und Windows-Projekten bei Microsoft beteiligt.

In diesem Lightning Talk, der auf Facebook aufgezeichnet wurde, untersucht John Storymaps, um herauszufinden, worauf sich Ihr agiles Softwareentwicklungsteam konzentrieren sollte (um die Kundenbedürfnisse zu erfüllen). Storymaps stellen die Customer Journey während der Entwicklung in den Mittelpunkt und machen deutlich, was in einem Sprint eines Teams enthalten sein sollte. Weitere Informationen zum Story-Mapping finden Sie unter Verstehen Sie mit agilen User Story Maps, was Ihre Kunden wollen.

Es ist Zeit, Dinge zu erledigen und das Projekt den Programmierern zu übergeben. Aber bevor sie sich die Hände schmutzig machen, muss jemand planen der Scrum-Sprint oder die Scrum-Iteration. Das Sprint Planning-Meeting ist eine der Scrum-Zeremonien, und es ist die Eröffnungsveranstaltung des Sprints. 🎬

Lassen Sie sich von uns durch die Veranstaltung führen und erklären, wie Sie eine Veranstaltung erfolgreich vorbereiten und durchführen können. Außerdem erfährst du, wer an der Sprint-Planung teilnimmt und warum das Meeting so wichtig ist.

Was ist ein Sprint Planning-Meeting?

Sprint Planning ist ein Scrum-Meeting. Es leitet einen Sprint ein, findet also am ersten Tag eines neuen Sprints statt. Falls zutreffend, sollte es danach erfolgen der Sprint Review und die Sprint-Retrospektive aus der vorherigen Iteration.

Die Sprintplanung zielt darauf ab, die Ergebnisse für den bevorstehenden Sprint festzulegen und einen Plan für die Entwicklung der Arbeit zu definieren.

Das gesamte Scrum Team (der Product Owner, der Scrum Master, und das Entwicklungsteam) arbeitet bei der Sprint-Planung zusammen.

Können Sie sich ein erfolgreiches Projekt ohne Planung vorstellen? 🙅 Das können wir auch nicht, also starten wir keinen Scrum-Sprint, ohne ihn zu planen.

Um einen Scrum-Sprint zu planen, müssen Sie sich entscheiden:

• Die Dauer des Sprints — denk daran, dass ein Sprint eine Timebox ist
• Das Sprintziel, was ihr Zweck ist und darstellt die Produktzunahmeder Wert für den Kunden
• Die Arbeit, die das Entwicklungsteam während des Sprints erledigen kann, welche Arbeitsaufgaben das Team zuerst erledigen sollte, um das Sprintziel zu erreichen, und wie lange sie unter Berücksichtigung der Kapazität des Teams benötigen sollten

Darüber hinaus sollte die Sprint-Planung das Team motivieren und realistische Erwartungen setzen.

Am Ende des Sprint Planning-Meetings muss das Team die folgenden Ergebnisse erzielen:

• Ein gemeinsames Verständnis des Sprintziels. Dieses Ziel ist die Richtlinie für die Bewertung der Arbeit des Entwicklungsteams nach Abschluss des Sprints.
• Das Sprint Backlog. Dieses Artefakt steht für das Gespräch zwischen dem Entwicklungsteam und dem Product Owner über die zu erledigende Arbeit. Es ist das Ergebnis eines ausgewogenen Verhältnisses zwischen Kundennutzen und Entwicklungsaufwand.

Jetzt erfordert jedes Sprint Planning-Meeting einige Vorbereitungen. Lesen Sie weiter, wer es tun sollte und was es beinhaltet.

Wie bereitest du dich auf die Sprint-Planung vor?

Der Product Owner sollte die folgenden Schritte befolgen, um die Grundlage für eine erfolgreiche Sprint-Planung zu legen:

• Kombinieren Sie die Ergebnisse des vorherigen Sprint Reviews mit dem Feedback von Stakeholdern wie Management und Kunden und die Produktvision
• Aktualisieren und, falls erforderlich, verfeinern der Produkt-Backlog
• Kennen Sie den Kundennutzen, den das Entwicklungsteam schrittweise schaffen muss

Sobald alle Vorbereitungen abgeschlossen sind, ist es Zeit für das Sprint Planning-Meeting.

Wie sollte das Treffen ablaufen?

1. Der Product Owner gibt die Product Backlog-Elemente — und die entsprechenden Prioritäten — an, die sie als die besten Kandidaten für den nächsten Sprint betrachten. Artikel können sein Anwenderberichte, Aufgaben oder Bugs. Der Product Owner schlägt diese Artikel entsprechend dem Kundennutzen und der Produktvision vor.
2. Basierend auf Aufwandsschätzungen und dem Vorschlag des Product Owners das Entwicklungsteam wählt die Produkt-Backlog-Elemente aus, an denen während des aktuellen Sprints gearbeitet werden soll. Indem sie diese Elemente zu Sprint-Backlog-Elementen heraufstufen, einigen sich die Entwickler mit dem Product Owner auf das Sprint-Ziel.
3. Obwohl optional, könnte das Team die Abhängigkeiten zwischen den Elementen besprechen und darüber, wer an jedem einzelnen von ihnen arbeiten sollte.

Sehr wenige Schritte, oder? Einige praktische Maßnahmen sollten diese Schritte jedoch ergänzen. Im Folgenden erfahren Sie, um welche Maßnahmen es sich dabei handelt.

Wie führt man ein erfolgreiches Sprint-Planning-Meeting durch?

1. Begrenzen Sie die Dauer der Besprechung. ⏳ Die Sprint-Planung sollte nicht länger als 1-2 Stunden pro Sprintwoche dauern. Das bedeutet, dass das Meeting für einen zweiwöchigen Sprint nicht länger als 2-4 Stunden dauern sollte.

2. Lassen Sie den Scrum Master der Wächter der Zeit sein. Sie sind dafür verantwortlich, dass das Meeting innerhalb der definierten Zeitbox stattfindet.

3. Halten Sie das Meeting jedes Mal am selben Tag und zur gleichen Zeit ab. 📅 Teammitglieder können ziemlich beschäftigt sein und volle Agenden haben. Deshalb empfiehlt es sich, für jeden Teilnehmer einen Platz in der Agenda zu reservieren.

4. Definieren Sie wertvolle, klare Ergebnisse. 🎁 Diese, zusammen mit einem klaren Sprint-Backlog, erhöhen die Motivation des Entwicklungsteams. Die richtigen Ergebnisse zu erzielen ist pure Zufriedenheit, und ein klarer Arbeitsplan ist das Rezept, um dies zu erreichen.

5. Stellen Sie sicher, dass der Scrum Master diese Dinge garantiert. Erstens, dass das Gespräch zwischen dem Entwicklungsteam und dem Product Owner fruchtbar ist. Sie sollten sich alle auf das Sprintziel einigen. Zweitens, dass die Entwickler gute Entscheidungen treffen, wenn sie Artikel aus dem Produkt-Backlog in das Sprint-Backlog verschieben. Es ist eine gute Wahl, ein Element auszuwählen, das für die Dauer des Sprints, die Teamkapazität und die Arbeitslast machbar ist.

Es mag einfach erscheinen, aber das ist nicht alles, was Sie während der Sprint-Planung tun müssen. Es gibt eine Reihe von Dingen, die es zu vermeiden gilt.

Wenn wir dir einen Rat geben sollten...

Schätzen Sie den Aufwand anhand der Kapazität des Entwicklungsteams ab. Um zu entscheiden, wie viel Arbeit das Team in einem Sprint erledigen kann, sollten Sie die Kapazität des Teams berücksichtigen. (Und denken Sie daran, Schätzungen sind genau das — Schätzungen.) Entwickler berücksichtigen ihre bisherigen Erfahrungen, doch jeder Sprint ist einzigartig und kann sich im Laufe seines Verlaufs ändern. Die Berücksichtigung der Teamkapazität verbessert jedoch die Genauigkeit der Aufwandsschätzung. Darüber hinaus Storypoints könnte dem Team bei der Aufwandsschätzung helfen.

Bedenken Sie, dass sich die Fähigkeit des Entwicklungsteams zur Schätzung im Laufe der Zeit verbessern sollte. Daher sollte das Team weniger genaue Aufwandsschätzungen nach dem Sprint nicht kritisieren. Andernfalls wird das Team viel länger brauchen, um eine Schätzung vorzunehmen, oder beim nächsten Mal viel größere Schätzungen abzugeben.

Versuchen Sie nicht, während der Sprint-Planung alles zu planen. Lassen Sie die Idee, das vollständigste und perfekteste Sprint-Backlog aller Zeiten zu erstellen, vor der Tür. Schließlich dreht sich bei Scrum alles um Flexibilität und „Besser gemacht als perfekt“. Ein Sprint-Backlog, das vollständig genug ist, um Entwicklern den Einstieg zu erleichtern, ist also genau das, was es sein muss. Denken Sie daran, dass die Lösung komplexer Probleme einen Learn-by-Doing-Ansatz erfordert, der die Planung zu einer ebenso komplexen Aufgabe macht.

Ermitteln Sie eine realistische Erwartung für das Ergebnis des Sprints. Es ist keine gute Idee, unrealistische Erwartungen an den Zuwachs zu stellen, den das Entwicklungsteam im Laufe eines Sprints erzielen kann. Es könnte Entwickler frustrieren, dass sie nicht liefern konnten, was ihre Motivation und Leistung ernsthaft beeinträchtigen kann. Auf der anderen Seite sorgen realistische Erwartungen dafür, dass das Team Erfolg hat und ein Erfolgserlebnis hat. Außerdem erleichtern sie die Konversation zwischen den Entwicklern und dem Product Owner, sodass sie sich auf das Sprintziel einigen können.

Haben Sie einen gut verfeinerten Produkt-Backlog. Es muss detailliert genug sein, damit das Entwicklungsteam verstehen kann, worum es bei den Arbeitsaufgaben geht. Sie möchten keine wertvolle Zeit in der Sprint-Planung damit verschwenden, Arbeitselemente in maximal eines pro Tag aufzuteilen. Definieren und folgen Sie einem Verfeinerung des Backlogs verarbeiten und sicherstellen, dass Product Backlog-Artikel Ihren Anforderungen entsprechen Definition von bereit.

Schlage ein klares Sprintziel vor. 🎯 Der Product Owner muss sich über den erwarteten Kundennutzen für die Erhöhung im Klaren sein. Andernfalls wählt das Entwicklungsteam möglicherweise eine Reihe von Artikeln aus dem Produktbacklog aus, die keinen Bezug zueinander haben. Das Ergebnis könnten unerwartete Ergebnisse und ein geringes Erfolgserlebnis sein.

Klären Sie das Definition von erledigt mit dem Entwicklungsteam. Zu wissen, was geleistete Arbeit im aktuellen Sprint bedeutet, hilft den Entwicklern, die Erwartungen zu erfüllen. Das liegt daran, dass sie besser verstehen, was zu tun ist, um das Inkrement zu erzielen. Außerdem gibt eine klare Definition von „Fertig“ dem Entwicklungsteam mehr Selbstvertrauen bei der Einschätzung des Aufwands.

Starke Sprint-Planung macht Ihr Projekt stärker

Wenn du folgst das Scrum-Framework, Sprint Planning ist keine Wahl. Wenn Sie jedoch jemals versucht sind, ihn zu überspringen, setzen Sie ein Lesezeichen für diesen Artikel und lesen Sie das Folgende. 📑

Mit einem erfolgreichen Sprint-Planning-Meeting ist es einfacher, das Sprintziel, die zu erledigenden Aufgaben und die Sprintergebnisse zu verstehen. Wenn das Team nicht weiß, wohin es geht und wie es dorthin gelangen kann, wird es wirklich schwierig, die Kundenbedürfnisse zu erfüllen. Es ist genauso schwierig, Ihren Kunden wertvolle Zuwächse zu bieten, wenn Sie die Arbeit nicht nach Prioritäten organisieren.

Bei der Sprint-Planung geht es darum, Klarheit zu schaffen und die Arbeit zu organisieren, bevor es in der Iteration zu spät ist. Es geht auch darum, das gesamte Team in die Vorbereitung auf alle Anstrengungen einzubeziehen, die ein Sprint erfordert. Ein Hinweis: Denken Sie daran, dass ein Sprint-Plan in die Zeitbox eines Sprints passen muss, und berücksichtigen Sie die Teamkapazität.

Einfacher agiler Teamrhythmus ist perfekt für die Sprint-Planung. Es ist ein schnelles, unkompliziertes, visuelles und kollaboratives Tool, das Ihnen Folgendes ermöglicht:

• Ziehe Artikel direkt aus dem Produkt-Backlog auf die User Story Map
• Aufwandsschätzungen in User Stories registrieren
• Story-Point-Schätzungen bearbeiten
• Priorisieren Sie die User Stories in jedem Sprint, indem Sie sie innerhalb der jeweiligen Sprint-Swimlane anordnen
• Analysieren Sie die Sprint-Statistiken, um sicherzustellen, dass die geplante Arbeit die Kapazität des Teams nicht überschreitet und das Sprintziel realistisch ist
• Visualisieren Sie, was das Team wann liefern wird, indem Sie User Stories in Sprint-Swimlanes zusammenfassen

Lassen Sie uns wissen, wenn Sie Fragen haben zu Einfacher agiler Teamrhythmus. Wir empfehlen es für Ihr Scrum-Projekt sehr, und unsere Kunden empfehlen dasselbe.

Machen Sie sich bereit für das Remote User Story Mapping.

Egal, ob Sie User Story Mapping schon einmal (persönlich) gemacht haben oder ob Sie neu im Bereich User Story Mapping sind, es besteht eine sehr gute Chance, dass Sie 2020 zum ersten Mal remote User Story Mapping durchführen müssen.

Schon vor der Pandemie 4,7 Millionen Menschen in den USA arbeitete remote, und ein geschätzter 31% der Arbeitnehmer in den USA Im März 2020 angestellte Mitarbeiter arbeiteten im April 2020 von zu Hause aus.

Und nach dem Ende des Lockdowns werden wir wahrscheinlich dauerhafte Änderungen an unserer Arbeitsweise erleben. Umfragen zeigen das 80% der Mitarbeiter sind daran interessiert, zumindest zeitweise von zu Hause aus zu arbeiten. Darüber hinaus erkennen immer mehr Unternehmen, dass das Anbieten flexibler Optionen für die Telearbeit zu einer besseren Work-Life-Balance für die Mitarbeiter, niedrigeren Gemeinkosten, geringeren Umweltauswirkungen und einer verbesserten Produktivität führen kann.

... das ist alles, um das zu sagen Remote User Story Mapping wird bald zur Norm.

Was müssen Sie also wissen, bevor Sie Ihr erstes Online-User-Story-Mapping-Event durchführen? Lassen Sie uns 8 Dinge durchgehen, die Sie für ein erfolgreiches Remote User Story Mapping berücksichtigen sollten.

1. Machen Sie die Grundlagen richtig

Das Wichtigste zuerst: Du musst deine Basics sortiert haben. Stellen Sie sicher, dass Ihr Team es versteht was User Story Mapping ist, warum User Story Mapping wichtig ist, und wie man es macht.

Das hilft ihnen dabei, sie an Bord zu holen — was entscheidend ist, da sie zwei volle Tage für den Prozess aufwenden müssen.

Wenn jemand in Ihrem Team mit User Story Mapping noch nicht vertraut ist, senden Sie ihn an unsere Ultimativer Leitfaden zum User Story Mapping. Es hat alles, was sie wissen müssen 👌

2. Stellen Sie Ihre Agenda ein

Das User Story Mapping sollte eine geplante Veranstaltung sein. Sie sollten wissen, was und wann passiert, um sicherzustellen, dass Ihr Team den Zeitplan einhält und alle Schritte abschließt, die zur Erstellung einer fertigen Story-Map erforderlich sind. Hier ist eine ziemlich normale Agenda:

Deine Agenda zu kennen, ist besonders wichtig für das Story-Mapping aus der Ferne, weil es viel einfacher ist, vom Kurs abzukommen, wenn die Leute nicht physisch im Raum sind.

Sally geht vielleicht für ein langes Mittagessen in die Küche und verpasst den wichtigsten Teil. Oder Bob muss vielleicht seinen Zeitplan so koordinieren, dass sein Partner sich etwa eine Stunde lang um die Kinder kümmern kann, während er mit der Schätzung der Arbeit beschäftigt ist.

Wenn Sie die Agenda im Voraus festlegen, kann Ihr Team auch schon vor der Veranstaltung über die Sitzung und die Nutzerberichte nachdenken. Auf diese Weise fühlen sie sich besser vorbereitet und bereit, an Diskussionen teilzunehmen.

Übrigens, falls Sie nicht mit allen Punkten der obigen Agenda vertraut sind, sprechen wir mehr über die einzelnen Schritte und wie Sie das User Story Mapping durchführen können in unserem ultimativer Leitfaden für User Story Mapping.

3. Plane deine Sitzung

Wann werden Sie Ihre Live-Online-User-Story-Mapping-Sitzung abhalten? Die meisten Teams benötigen volle zwei Tage, um alle Schritte durchzuarbeiten. Sie müssen also zwei Tage (idealerweise hintereinander) finden, an denen alle verfügbar sind.

Wenn sich dein Team in mehreren Zeitzonen befindet, musst du auch überlegen, zu welchen Zeiten du den besten Crossover hast, damit die Teammitglieder nicht um 2 Uhr morgens arbeiten (es sei denn, sie möchten).

4. Entscheide dich für wen

Das Remote User Story Mapping könnte Sie vor ein kleines Rätsel stellen. Im Gegensatz zu persönlichen Veranstaltungen, bei denen Ihnen der Platz begrenzt ist, könnten Sie technisch gesehen unbegrenzt viele Personen an Ihrer virtuellen Sitzung teilnehmen lassen. Aber das möchten Sie definitiv nicht — zu viele Personen machen Sie ineffizient (und sie könnten ihre Zeit nutzen, um Ihrem Unternehmen auf andere Weise einen Mehrwert zu bieten).

Es ist eine gute Idee, Ihre Anzahl auf etwa 12 Personen zu begrenzen. Beziehen Sie Teammitglieder und Interessenvertreter aus mehreren Abteilungen sowie Ihren Produktmanager, UX-Designer und Entwickler ein.

Entscheiden Sie auch, wer die Sitzung leiten wird und wer für die Erstellung der Story-Map verantwortlich ist.

Die gute Nachricht ist, dass das Online-User Story Mapping es einfach macht, Sitzungen aufzuzeichnen — Sie erhalten eine digitale Aufzeichnung Ihrer Telefonkonferenzen und Ihr Story-Mapping-Board. So kann sich jeder, der neugierig ist, ganz einfach über die Highlights informieren, wenn Ihre Veranstaltung vorbei ist.

5. Stell ein paar Regeln auf

Aus der Ferne zu arbeiten und zusammenzuarbeiten kann sich ein bisschen wie im wilden Westen anfühlen — besonders in den ersten Wochen oder Monaten. Jeder findet immer noch heraus, wie man dieses Ding zum Laufen bringt — und wie man Dinge in einer neuen Umgebung effektiv erledigt.

Wir haben alles Ich habe an Telefonkonferenzen teilgenommen, bei denen jemand die richtige Etikette nicht kannte oder deren Audio/Video die anderen Teilnehmer ablenkte.

Vor diesem Hintergrund finden Sie hier einige Regeln, die Sie vielleicht vor Ihrer Remote-User-Story-Mapping-Sitzung teilen möchten, um sie etwas weniger chaotisch und viel produktiver zu gestalten:

• Komm nicht zu spät
• Setz deine Kamera ein
• Bewahren Sie Ihr Essen für eine bestimmte Pause auf
• Gehen Sie mit Ihrem Gerät nicht spazieren
• Schließ deine Tür, wenn du kannst
• Konzentrieren Sie sich auf die Aufgabe (kein Abrufen von E-Mails!)
• Eine Person spricht gleichzeitig
• Warten Sie, bis alle die Gelegenheit hatten, Beiträge zu leisten, bevor Sie fortfahren.
• Wenn du nicht sprichst oder nicht an der Konvertierung teilnimmst, schalte dich stumm (um Interferenzen oder Hintergrundgeräusche zu vermeiden, die die Aufmerksamkeit der Leute behindern könnten)

Seien Sie natürlich realistisch. Ihre Teammitglieder arbeiten wahrscheinlich unter nicht idealen Umständen von zu Hause aus, egal ob sie mit Familienmitgliedern unter Quarantäne gestellt werden, mit einem kranken Kind zu Hause festsitzen oder es mit einem schlecht erzogenen Haushund zu tun haben.

Es wird Lärm und Störungen geben - und trotz aller Bemühungen wird sich jemand verspäten. Solange die Teilnehmer ihr Bestes tun, um zur richtigen Zeit die Stummschalttaste zu drücken und andere zu berücksichtigen, sollte deine Sitzung reibungslos ablaufen.

6. Bereite deine Technik vor

Bisher konntest du vielleicht nur mit deinem Gehirn und einem Stift zu einer User Story Mapping-Sitzung erscheinen 🧠🖊️ Du brauchst dein Gehirn immer noch für das Remote User Story Mapping, aber du kannst den Stift wegwerfen.

Stattdessen müssen Sie sicherstellen, dass Sie und Ihr Team Zugriff auf die Technologie haben, die sie benötigen, um online teilzunehmen und zusammenzuarbeiten. Dinge wie:

• Zugriff auf Zoom, Google Hangouts oder Skype — Jeder sollte sein Konto startklar haben und etwas Erfahrung mit der Plattform mitbringen
• Slack oder Microsoft Teams — Richten Sie einen Echtzeit-Chat ein, wenn Sie nicht an einer Videokonferenzsitzung teilnehmen
• Kopfhörer und Mikrofon — Diese sollten gut funktionieren und im Voraus getestet werden
• Webcam — Eine Webcam ist zwar nicht unbedingt erforderlich, hilft Ihnen aber dabei, das Gefühl zu vermitteln, zusammen im Raum zu sein
• Internet — Bitten Sie Ihr Team, die Verbindung zu testen und sicherzustellen, dass sie zuverlässig ist. Idealerweise sollten Sie mindestens eine Backup-Option haben (z. B. ein lokales Café, das Haus eines Freundes oder mobiles Hotspotting)

Mit der richtigen Technologie können Sie den User Story Mapping-Prozess so anpassen, dass er für Ihr Remote-Team funktioniert.

7. Holen Sie sich eine Software zur Zuordnung von Benutzergeschichten

Eine physische User Story-Mapping-Sitzung beinhaltet in der Regel ein langes Blatt Papier oder Karton mit Hunderten von winzigen Haftnotizen für jede Geschichte und jedes Backbone-Objekt sowie eine Schnur, um Schnittlinien zu zeigen.

Die gute Nachricht ist, wenn Sie Story-Mapping aus der Ferne durchführen, müssen Sie nicht das nächstgelegene Schreibwarengeschäft ausräumen. 🎉 Sie müssen sich jedoch mit einigen digitalen Tools ausstatten, um das physische Story-Mapping-Board online zu replizieren.

Es gibt ein paar User Story Mapping-Tools auf dem Markt, aber wir sind daran interessiert Einfache Agile User Story Maps. Es lässt sich direkt in deinen bestehenden Jira-Workspace integrieren und ermöglicht dir:

• Bilden Sie Ihre Kundenreise visuell ab
• Weisen Sie Epen Geschichten zu
• Geschichten priorisieren und sequenzieren
• Ordne Geschichten in Sprint- und Versions-Swimlanes an
• Story-Point-Schätzungen hinzufügen

Es ist wie das physische User Story Mapping, wird aber digital in Jira durchgeführt. Das macht es perfekt für die Durchführung einer Remote-User-Story-Mapping-Sitzung.

Okay, wir sind vielleicht ein bisschen voreingenommen, aber diese Leute sind es nicht:

Möchten Sie es für Ihre bevorstehende Remote User Story Mapping-Sitzung ausprobieren? Melden Sie sich für unsere kostenlose 30-Tage-Testversion an um die Vorteile für Sie und Ihr Team zu sehen. Wir sind zuversichtlich, dass Sie lieben werden, was Sie finden!

Probiere es jetzt

8. Integrieren Sie Ihren Arbeitsablauf

Stellen Sie zu guter Letzt sicher, dass Ihre Remote-User Story Mapping-Sitzung in Ihren Workflow integriert ist

Gute Neuigkeiten! Wenn Sie ein digitales User-Story-Mapping-Tool (wie das von Easy Agile) verwenden, wird es für Sie viel einfacher sein, Ihre Storymap in Ihren Workflow zu integrieren. Sobald Ihre User Story Mapping-Sitzung abgeschlossen ist, sind Ihre User Stories bereits in Jira eingerichtet und in Sprints oder Versionen organisiert, sodass Ihr Team genau weiß, woran es als Nächstes arbeiten muss.

(Obwohl sie sich vielleicht ein oder zwei Tage Zeit nehmen wollen, um sich wieder zu entspannen... 😴)

Machen Sie sich bereit für den Erfolg!

Mit der richtigen Vorbereitung und den richtigen Tools können Sie sich auf eine relativ reibungslose Remote-User Story-Mapping-Sitzung vorbereiten. Und danach? Sie werden in der Lage sein, Ihre zukünftigen Story-Mapping-Events auf eine optimiertere, digitale Art und Weise durchzuführen, unabhängig davon, ob Sie von zu Hause aus arbeiten, mit einem verteilten Team zusammenarbeiten oder vom Büro aus arbeiten müssen.

Und angesichts der Art und Weise, wie sich die Arbeit im Jahr 2020 (und darüber hinaus) verändert, ist das eine sehr gute Fähigkeit, die man haben sollte.

Ein Produkt-Backlog repräsentiert alle Ziele und gewünschten Ergebnisse innerhalb der Entwicklung eines Produkts. Dies sind die spezifischen Aufgaben, die ein Team zu erledigen hofft, wenn es sich daran macht, ein Produkt zu entwerfen oder zu verbessern.

Was einen Produkt-Backlog so effektiv macht, ist sein agiler Charakter. Backlogs entwickeln sich ständig weiter, ändern sich und passen sich an die aktuellen Bedürfnisse von Stakeholdern und Kunden an. Um einen Backlog aktuell und in seiner effektivsten Form zu halten, muss er kontinuierlich verfeinert und angepasst werden. Dieser Prozess braucht Zeit, aber es gibt einfache, leistungsstarke Strategien, um einen qualitativ hochwertigen Backlog aufrechtzuerhalten.

Ein guter Produktbestand hat vier Merkmale. Es ist:

• Angemessen detailliert
• Geschätzt
• Aufstrebend
• Priorisiert

Wir werden all diese Eigenschaften im Detail behandeln, einschließlich der Frage, wie Sie sicherstellen können, dass Ihr Produkt-Backlog in Ordnung ist. Aber lassen Sie uns zunächst über den Produktrückstand und den Verfeinerungsprozess auf derselben Seite sprechen.

Transformieren Sie Ihr flaches Produkt-Backlog mit

Einfacher agiler Teamrhythmus

Jetzt testen

Was ist ein Produkt-Backlog?

Ein Produkt-Backlog ist eine priorisierte und geordnete Liste, die die Arbeit darstellt, die von einem Entwicklungsteam erledigt werden muss. Die Backlog-Elemente werden aus der Produkt-Roadmap abgeleitet und auf der Grundlage der Aufgaben organisiert, die am wichtigsten sind — diejenigen, die zu einem bestimmten Zeitpunkt die größte Wirkung haben werden.

Backlog-Einträge geben an, was erforderlich ist, um ein neues Produkt zu entwickeln oder ein bestehendes mit neuen Funktionen zu verbessern. Es ist die ganze Arbeit, die ein Team in Zukunft bewältigen wird, aber es ist auch ein flexibler, lebender Organismus, der sich weiterentwickelt, wenn ein Entwicklungsteam mehr über das Produkt und seine Stakeholder erfährt.

Das Produkteigentümer ist verantwortlich für die Reihenfolge und Priorisierung von Backlog-Elementen, wobei Artikel mit hoher Priorität ganz oben platziert werden. Sie sind auch für die Verfeinerung des Backlogs verantwortlich, wodurch sichergestellt wird, dass alle Backlog-Elemente organisiert sind, über die entsprechenden Details verfügen und für jede bevorstehende Sprint-Planung bereit sind.

Produkt-Backlogs im Vergleich zu Sprint-Backlogs

Sprint-Backlogs sind Produkt-Backlogs ziemlich ähnlich, aber sie dienen einem anderen, spezifischeren Zweck. Zu Beginn eines Gedränge, der Product Owner organisiert die Produkt-Backlog-Elemente, die vom Scrum-Team in diesem Sprint abgeschlossen werden sollen.

Das Scrum-Produkt-Backlog stellt eine kleine Teilmenge des gesamten Produkt-Backlogs dar. Das Produkt-Backlog ist die gesamte Flasche Wein, während das Sprint-Backlog das Glas Wein ist, das Sie als Nächstes in Angriff nehmen werden. In dieser Analogie ist der Scrum Master der Sommelier, der während des gesamten Sprints Anleitung, Kontext und Feedback bietet.

Am Ende des Sprints wird ein Sprint-Review mit den Stakeholdern durchgeführt, um besser zu verstehen, was als Nächstes angegangen werden muss. Backlog-Elemente, die noch nicht abgeschlossen wurden, können in das größere Produkt-Backlog zurückverschoben werden, um zu einem späteren Zeitpunkt oder im nächsten Sprint darauf zuzugreifen. In einem weiteren Meeting zur Sprint-Planung wird das Team darauf vorbereitet, den nächsten Stapel von Backlog-Elementen in Angriff zu nehmen.

Warum muss ein Backlog verfeinert werden?

Die Verfeinerung des Backlogs ist keine Luxusaufgabe, der nur dann vorbehalten ist, wenn Sie die Gelegenheit haben, aufzuräumen. Die Verfeinerung ist ein wichtiger Bestandteil des Produkt-Backlog-Managements, das sicherstellt, dass ein Backlog immer die neuesten und aktuellsten Informationen enthält.

Durch die Verfeinerung des Backlogs wird es für das Entwicklungsteam vorbereitet, was auf lange Sicht Zeit spart. Der Prozess hilft bei der Priorisierung von Elementen und stellt sicher, dass Ihr Backlog nichts enthält, was Sie nicht mehr benötigen.

Wie Sie wissen, dreht sich bei der agilen Methode alles um Flexibilität und die Fähigkeit, einen Plan weiterzuentwickeln, wenn neue Informationen oder Hindernisse auftauchen. Was Sie zu Beginn der Produktentwicklung für wichtig hielten, ist möglicherweise nicht mehr notwendig, oder Ihre Stakeholder haben Sie möglicherweise in eine völlig andere Richtung gelenkt.

Die Verfeinerung des Produktbestands umfasst:

• Hinzufügen von Details zu Backlog-Elementen mit hoher Priorität für ein besseres Verständnis.
• Verbesserung und Überprüfung der Schätzungen.
• Artikel entfernen, die für das Produkt nicht mehr relevant sind.
• Hinzufügen von Elementen auf der Grundlage des Feedbacks neuer Interessengruppen.
• Vornehmen von Anpassungen auf der Grundlage der neuesten Bugfixes.
• Priorisierung von Artikeln, die dem Kunden einen Mehrwert bieten.
• Reihenfolge der Backlog-Elemente, um im nächsten Sprint die größtmögliche Wirkung zu erzielen.

Die Verfeinerung des Backlogs braucht Zeit, aber es lohnt sich, ein gesundes, aktuelles Backlog zu haben, das immer für das Entwicklungsteam bereit ist.

DEEP: Die wichtigsten Eigenschaften eines guten Produkt-Backlogs

Roman Pichler, der Autor von Agiles Produktmanagement mit Scrum: Creating Products That Customers Love wurde von DEEP entwickelt, um die wichtigsten Eigenschaften eines guten Produkt-Backlogs zu beschreiben. Das Akronym DEEP hilft Produktverantwortlichen und Entwicklungsteams zu verstehen, wie sie kluge Entscheidungen treffen und gleichzeitig einen erfolgreichen Backlog aufrechterhalten können.

Das Konzept wird überall angewendet Verfeinerung des Produktbestands Prozess, der ein wichtiger Bestandteil des Backlog-Managements ist. Die Verfeinerung von Backlogs, früher Backlog-Grooming genannt, ist ein fortlaufender Prozess, der sicherstellt, dass ein Backlog in Topform ist. Wir stellen uns das gerne so vor, als würde man die Zweige einer Pflanze abschneiden.

Um einer Pflanze beim Wachsen zu helfen, müssen Sie sie beschneiden und trimmen. Der Verfeinerungsprozess fügt bei Bedarf Details hinzu und priorisiert Artikel auf der Grundlage der aktuellen Informationen, die der Product Owner von Teammitgliedern und Interessenvertretern hat.

DEEP steht für Dangemessen detailliert, Egeschätzt, Everschmelzen und Ppriorisiert.

Die Einhaltung dieser Richtlinien und Best Practices führt zu einem Qualitätsrückstand, der zu einer reibungslosen Produktentwicklung und einem erfolgreichen Endergebnis führen wird. Schauen wir uns jedes Attribut genauer an. 🔎

Angemessen detailliert

Details sind wichtig, vor allem, wenn eine User Story immer mehr an Priorität gewinnt. Je näher ein Backlog-Element seiner Fertigstellung kommt oder in ein Sprint-Backlog verschoben wird, desto mehr Details sind erforderlich. Bevorstehende Backlog-Elemente sollten angemessen detailliert sein, damit sie vom Entwicklungsteam besser verstanden werden können. Je näher ein Item der Fertigstellung kommt, desto mehr Details sollte es enthalten.

Auf der anderen Seite benötigen Elemente, die weiter unten auf der Prioritätenliste stehen, nicht annähernd so viele Details. Es ist eine schlechte Zeitnutzung, um Details zu Elementen mit niedrigerer Priorität hinzuzufügen, da man nie weiß, wie sich der Backlog entwickeln wird. Sie könnten viel Zeit damit verschwenden, Elemente mit niedriger Priorität detailliert zu beschreiben, wenn sie später im Prozess entfernt oder überarbeitet werden könnten.

Geschätzt

Eine gründliche Schätzung sollte sich auf Themen mit hoher Priorität konzentrieren, die bald in Angriff genommen werden. Wenn Sie Ihren Rückstand verfeinern und mehr Details zu den Punkten mit der höchsten Priorität hinzufügen, können Sie Ihre Einschätzung verbessern. Eine gute Option ist Verwenden von Story Points um die Details zu vergrößern. Sie können Ihnen helfen, die Realität eines Artikels aus Kundensicht genau und praktisch widerzuspiegeln.

📘 Lesen Sie unsere Leitfaden zur Einbindung von User Story Points um mit der Anwendung dieser Technik zu beginnen.

Da nicht viel über sie bekannt ist, ist es schwierig, Artikel mit niedrigerer Priorität richtig einzuschätzen. Wenn Sie auf der Prioritätenliste weiter unten stehen, wird Ihre Schätzung eher eine Vermutung sein, da Sie noch nicht über alle Informationen verfügen. Verwenden Sie in diesen Fällen eine einfache agile Schätzmethode, z. B. die Größe von T-Shirts (Kennzeichnung der Arbeitsaufgaben als XS, S, M, L, XL), um eine Schätzung vorzunehmen. Erstellen Sie auf der Grundlage der Informationen, die Sie zu diesem Zeitpunkt haben, eine ungefähre Schätzung des Aufwands, der für dieses Backlog-Element erforderlich ist.

Aufstrebend

Je mehr Sie über das Produkt und seine Kunden erfahren, desto mehr können Sie Ihren Produkt-Backlog verbessern. Das Backlog ist ein lebendiges Dokument, das Ihren Plan zu einem bestimmten Zeitpunkt darstellt. Es ist nicht in Stein gemeißelt und sollte im Laufe der Zeit überarbeitet und verbessert werden.

Mit den Informationen aus Rückblicken und dem Feedback von Stakeholdern können Sie das Backlog aktualisieren, um widerzuspiegeln, was Sie dabei gelernt haben. Erlauben Sie Ihrem Backlog, sich weiterzuentwickeln, indem Sie Elemente nach Bedarf hinzufügen, entfernen und verfeinern.

Priorisiert

Ein Produkt-Backlog muss priorisiert werden. Die Elemente oben haben eine höhere Priorität, und die Elemente im unteren Bereich haben eine niedrigere Priorität. Berücksichtigen Sie bei der Entscheidung, welche Elemente priorisiert werden sollen, den Wert, den jedes Element bietet.

Ihr Team kann seine Bemühungen maximieren, indem es die Backlog-Elemente priorisiert, die den Kunden zu einem bestimmten Zeitpunkt den größten Mehrwert bieten. Da sich dies je nach den aktuellen Bedürfnissen Ihrer Kunden ändern wird, müssen Sie Ihre Prioritätsreihenfolge kontinuierlich anpassen und verfeinern.

Erzielen Sie mit Easy Agile ein TIEFGREIFENDES Produkt-Backlog

Easy Agile hat es sich zur Aufgabe gemacht, agilen Teams zu helfen, effektiver zu arbeiten. Wir haben eine Suite von Jira-Apps, die für Teams entwickelt wurden, die Produkte entwickeln möchten, bei denen der Kunde bei der Entscheidungsfindung an erster Stelle steht.

Einfacher agiler Teamrhythmus Transformieren Sie Ihren flachen Produktbestand, indem Sie Prioritäten auf der Grundlage des Kundennutzens setzen und die Customer Journey zum Leben erwecken. Sie helfen Teams bei der Organisation und Priorisierung Anwenderberichte bei der Visualisierung der Kundenreise. Wenn Sie Ihre Kunden in Ihren Prozess einbeziehen, können Sie Feinentscheidungen treffen, die im besten Interesse des Kunden sind, unabhängig davon, in welcher Entwicklungsphase Sie sich befinden.

Erfahre mehr über unsere agile Apps und folge unserem Blog für die neuesten Inhalte für Jira-Teams.

Das Atlassian Marketplace ist mit hilfreichen Jira-Add-Ons oder -Plugins gefüllt. Diese Apps helfen Teams dabei, Projekte erfolgreich durchzuführen und pünktlich abzuliefern. In diesem Artikel gehen wir auf unsere Auswahl an Jira-Gadgets für Workflow-Management, Reporting und Projektverwaltung ein.

Wir zeigen Ihnen einige der besten Lösungen für:

• Analysieren Sie Daten über Jira-Probleme
• Automatisieren Workflows für Jira-Probleme
• Projekte migrieren und ihre Konfigurationen
• Bauen User-Story-Maps in Jira

Aber jetzt scheint der perfekte Zeitpunkt zu sein, um zu erklären, warum wir so große Fans von Jira Software und Jira-Add-Ons sind. 🙌

Warum Jira-Add-Ons gerade im Trend sind

Jira ist die führende Softwarelösung für kollaborative Teams — Entwickler auf der ganzen Welt verlassen sich darauf, um ihre Aufgaben zu verfolgen und Kunden einen Mehrwert zu bieten.

Einer der wichtigsten Vorteile von Jira ist die Anpassung. Jira-Benutzer können die Workflows und Vorgangstypen von Vorgängen anpassen, um beispielsweise Ihre Projektanforderungen zu erfüllen. Nachdem Sie Ihren Jira-Prozess eingerichtet haben, passen sich die Entwickler an das Tool an und passen sich an. Im Laufe der Zeit wird die Anzahl der Jira-Projekte und Probleme in Ihrem Unternehmen zunehmen. Sie benötigen daher ein System, das mit Ihrem Wachstumstempo Schritt hält. 📈

Die Skalierung des Wachstums bringt einige Herausforderungen mit sich. Aber es muss kein großes Problem sein! 🙅 Jira-Add-Ons bauen auf den Stärken von Jira auf und ermöglichen es dir, es so einzurichten, dass es den Bedürfnissen des Teams entspricht. Sie ermöglichen es Entwicklern, anderen Teammitgliedern wie Product Ownern und Stakeholdern aus dem Unternehmen, den größtmöglichen Nutzen aus einer gemeinsamen Plattform herauszuholen. Um die besten Jira-Add-Ons für dich auszuwählen, sieh dir an, wofür dein Team am dringendsten Hilfe benötigt, welche Preise es gibt und welche Tutorials verfügbar sind.

Schauen wir uns einige der angesagtesten Jira-Plugins an.

1. Einfache Agile User Story Maps für Jira

Einfache Agile User Story Maps für Jira ist einer unserer Jira-Add-ons und eine der meistverkauften Apps auf dem Atlassian Marketplace

Sie können Easy Agile User Story Maps for Jira verwenden, um einfache User-Story-Maps kollaborativ. Aber warum benötigen Sie User Story Maps?

Warum User Story Maps nützlich sind

User-Story-Maps erleichtern agile Teams während des Projektbeginns. Diese Karten sind eine visuelle Darstellung von Kundenreisen und die Aktivitäten und Aufgaben, die Kunden im Produkt ausführen.

Die Visualisierung der Kundenreise ist der größte Vorteil bei einem Umzug von flachen Produkt-Backlogs zu User Story Maps. Darüber hinaus können sie die Arbeit, die sie leisten müssen, um für Kunden wertvolle Produktveröffentlichungen bereitzustellen, verstehen und priorisieren.

Easy Agile User Story Maps for Jira bietet jedoch noch mehr. Die App ermöglicht Ihnen:

• Erstelle Epen und Anwenderberichte
• Update und Benutzerberichte verfeinern
• Teilen Sie Epen in Benutzergeschichten auf
• Anwenderberichte planen
• Aufwandsschätzungen in User Stories registrieren
• Bearbeiten Nutzer-Storypoint Schätzungen
• Ordnen Sie User Stories nach Kundenwert innerhalb der jeweiligen Scrum Sprint- oder Kanban-Version Swimlane mit Drag-and-Drop-Funktion
• Analysieren Sie Sprint- oder Versionsstatistiken, um sicherzustellen, dass die geplante Arbeit die Kapazität des Teams nicht überschreitet
• Visualisieren Sie, was das Team wann liefern wird, indem Sie User Stories in Sprint- oder Versions-Swimlanes zusammenfassen

2. Pivot-Bericht

Wenn du Jira bereits verwendest, befinden sich alle oder die meisten Softwareentwicklungsdaten deines Projekts in Jira. Das bedeutet, dass du dich bei der Analyse dieser Daten auf Jira verlassen solltest. Das Pivot Report Jira Add-on ist Ihre Lösung, wenn Sie Daten aus Jira-Problemen visualisieren oder präsentieren müssen in Form von eine Pivot-Tabelle. Es ist deine Art, das Gesamtbild deiner Jira-Probleme zu sehen. Wir werden das im Folgenden ausführlich erklären, aber zuerst schauen wir uns an, was Pivot-Tabellen sind.

Was ist eine Pivot-Tabelle?

Eine Pivot-Tabelle ist ein Datenanalyseartefakt, mit dem Sie Geschäftsfragen wie die Auswirkungen von Werbung auf den Umsatz oder den Zusammenhang zwischen Produktrücksendungen und Qualitätssicherungsverfahren beantworten können. Möglicherweise kennen Sie den Begriff aus Microsoft Excel. Pivot-Tabellen sind auch praktisch, um komprimierte und organisierte Geschäftsinformationen an Stakeholder zu senden. Sie können diese Informationen zur Entscheidungsfindung oder zur Prozessverbesserung verwenden, um nur einige Anwendungsfälle zu nennen.

Pivot-Tabellen sind leicht zu verstehen, da sie Ihnen helfen, Daten zu visualisieren. Da eine Pivot-Tabelle Daten speichert, können Sie sie verwenden, um mit diesen Daten herumzuspielen. Beispielsweise können Sie Daten filtern, sortieren, gruppieren und Berechnungen mit ihnen durchführen.

Pivot-Tabellen für Jira

Jiras Standardberichte, erweiterte Suche, und Dashboards sind nett genug, aber möglicherweise benötigen Sie auch Hilfe beim Anzeigen von allgemeinen Fortschrittsinformationen oder Gesamtwerten. Pivot-Tabellen helfen dabei.

Oft erfordern andere Reporting-Lösungen eine zusätzliche Einrichtung, um Ihren Jira-Einstellungen und Projektanpassungen zu entsprechen. Aber mit Pivot Report for Jira sind die Anpassungen, die du brauchst, mit nur ein paar Klicks erledigt.

Wenn Sie also das Gesamtbild Ihres Jira-Projekts benötigen, können Sie das Pivot Report Jira-Add-on verwenden. Es kann dir helfen, den Status deines Projekts aus diesen Perspektiven zu bewerten:

• Fortschritt beim Gesamtumfang
• Welche Jira-Probleme das Team angegangen ist — offene und geschlossene Probleme
• Wer genau hat jedes Problem gelöst
• Die Menge der noch zu erledigenden Arbeit
• Überfällige Probleme und andere Mängel, z. B. Probleme ohne Bevollmächtigten, überfällig oder veraltet

Sie können das Pivot Report-Add-on auch verwenden für:

• Zeiterfassung für Teammitglieder
• Maßgeschneiderte Fortschrittsvisualisierung, indem Sie die benötigten Indikatoren auswählen und nach Ihren Wünschen bestellen
• Verschaffen Sie sich einen Überblick über Ihre Jira-Probleme, z. B. die Beziehung zwischen Epen, Aufgaben und Unteraufgaben

3. JMWE (Jira Misc Workflow-Erweiterungen)

JMWE (Jira Misc Workflow-Erweiterungen) ist vielleicht die beste Jira Cloud-App zur Automatisierung von Jira-Issue-Workflows. Sie entstand aus dem Bedürfnis von Jira-Administratoren, Workflows anzupassen. Da die Standardfunktionen von Jira keine komplexen Workflow-Vorlagen enthalten, lautete die Antwort Anpassung... und JMWE.

Dieses Jira-Add-on erweitert Jira, um dir zu helfen, komplexe Workflows zu entwerfen und zu implementieren. Und je mehr du einen Workflow an deine Projektkonfiguration anpassen kannst, desto automatisierter wird die Dateneingabe.

Und wissen Sie, was noch besser ist als die Workflow-Anpassung in JMWE? Wenn Sie nicht programmieren möchten, müssen Sie das nicht tun! Wenn du trotzdem programmieren möchtest, kannst du Aktionen mit planen Jira-Abfragesprache (JQL).

Hier ist eine Liste mit einigen Beispielen dafür, was Sie in Ihren Workflows unter bestimmten Bedingungen mit JMWE automatisieren können:

• Erstellen Sie Probleme und weisen Sie sie Mitgliedern mit einer bestimmten Rolle zu
• Probleme verknüpfen oder die Verknüpfung aufheben, um ihre Abhängigkeiten aufzubauen
• Den Wert von Problemfeldern berechnen oder löschen
• Kopieren Sie den Wert von Problemfeldern von einem Problem in ein anderes
• Kommentieren Sie Probleme mit bestimmten Informationen
• Senden Sie alle Informationen, die Jira zu Problemen hat, per E-Mail, unabhängig davon, ob sie Anhänge enthalten oder nicht
• Definieren Sie Abfolgen von Aktionen innerhalb des Workflows, z. B. Übergänge zum Problemstatus

4. Projekt-Konfigurator für Jira

Du kannst Projekte und ihre Konfigurationen manuell von einer Jira-Instanz in eine andere kopieren. Aber wenn etwas das für dich tun könnte, wäre das großartig, oder? Nun, das ist was Projektkonfigurator für Jira tut.

Sie können komplette Projekte — also deren Konfiguration und Daten — oder nur bestimmte Projektkonfigurationen exportieren und importieren. Diese Konfigurationen können auf gemeinsam genutzte Objekte verweisen, wie z. B. benutzerdefinierte Felder, Workflow-Schemata, Schemata für Problemtypen, Bildschirmschemasund Workflows. Sie können den Project Configurator auch verwenden, um andere gemeinsam genutzte Objekte zu exportieren und zu importieren, z. B. Filter, Dashboards und Softwarekarten.

Wenn Sie Ihre Projektkonfiguration aus der Entwicklungsumgebung verwenden möchten, um die Produktionsumgebung zu konfigurieren, ist dieses Jira-Add-on Ihre Antwort.

Der Project Configurator hat noch einen weiteren Vorteil: Sie können ihn verwenden, um Importe zu simulieren. Auf diese Weise können Sie alle Probleme erkennen und lösen, die auftreten könnten, wenn Sie mit dem eigentlichen Import fortfahren. Später können Sie mit dem Import aus dem simulierten Importbericht fortfahren. Dieses gesamte Importszenario ist nützlich, um Aktualisierungen der Projektkonfiguration in einer Staging-Umgebung zu testen, die der Produktionsumgebung vorausgeht.

Jira-Add-Ons für alle Zwecke und Geschmäcker

Vielleicht findest du unsere Auswahl an Jira-Add-Ons, da ein Ökosystem von Jira-Tools für Workflow-Management, Reporting und Projektverwaltung Folgendes ermöglicht:

• Einfache Anpassung von Informationen, die aus Jira extrahiert wurden
• Jira-Datenvisualisierung für Entscheidungsfindung, Prozessverbesserung und Fortschrittsverfolgung
• Hohe Anpassungsfähigkeit anspruchsvoller Jira-Berichte
• Die Automatisierung manueller Jira-Aufgaben, um Zeit zu sparen und manuelle Fehler zu reduzieren
• Jira-Arbeitspläne für Sprints oder Versionen

Wir können dich nicht gehen lassen, bevor wir dich einladen, unser Jira-Add-on selbst auszuprobieren. Probiere es aus Einfache Agile User Story Maps für Jira.

Was ist eine Kundenpersona?

Customer Personas sind fiktive Verallgemeinerungen Ihrer wertvollsten Kunden.

Sie helfen Teams dabei, ihre Kunden zu verstehen, indem sie demografische Informationen wie Alter, Geschlecht, Standort und Einkommen sowie psychografische Informationen wie Interessen, Frustrationen und persönliche oder berufliche Beweggründe zusammenführen.

Was sind User Personas?

Auf den ersten Blick mag es trivial erscheinen, als Team zusammenzukommen und scheinbar gefälschte Dating-Profile für Ihre wichtigsten Kunden zu erstellen.

Diese Übung bildet jedoch die Grundlage für andere agile Praktiken in der weiteren Entwicklung, und ihre Vorteile werden oft unterschätzt.

Agile-Experten haben mehr funktionsübergreifende Teams gefordert, was bedeutet, dass dieses Wissen darüber, wer der Kunde ist, nicht mehr in der alleinigen Verantwortung Ihres Vertriebs- und Marketingteams liegt. Jeder ist dafür verantwortlich, zu verstehen, wer der Kunde ist.

Teams, die ein gemeinsames Verständnis haben und sich darüber einig sind, wer die von ihnen bereitgestellte Lösung tatsächlich nutzt, haben eine höhere Erfolgswahrscheinlichkeit.

Der Aufbau von Kundenpersönlichkeiten hilft Teams dabei, die folgenden Fragen zu beantworten:

• Wer sind unsere Kunden?
• Was sind ihre gemeinsamen Verhaltensmuster?
• Was sind ihre gemeinsamen Probleme (beruflich und persönlich)?
• Was sind ihre Ziele und Vorgaben?
• Welche allgemeinen demografischen und psychografischen Informationen können ihre Entscheidungen beeinflussen?
• Was treibt sie dazu, Kaufentscheidungen zu treffen?
• Ist der Kunde der Käufer oder der Entscheidungsträger?
  

Sie können zwei Schritte unternehmen, um diese Fragen zu beantworten und herauszufinden, wer Ihre Kundenpersönlichkeiten sind:

Definieren Sie zunächst Ihre Personas im Großen und Ganzen

Es ist nicht verrückt zu glauben, dass die meisten Unternehmen eine umfassende Vorstellung davon haben werden, wer zumindest einige ihrer Kundenpersönlichkeiten sind. Dieses Wissen wird im Laufe der Zeit gesammelt und basiert auf Kundenfeedback, Supportanfragen, Gesprächen/Interviews und ersten Marktforschungen.

Dieses Wissen darf nicht unterschätzt werden und ist ein guter Ausgangspunkt, bevor Sie sich mit Analysen befassen, um diese Personas in spezifischeren Details zu konkretisieren.

Zweitens sollten Sie auf Erkenntnisse und Analysen achten

Sobald Sie sich ein paar Kundenpersönlichkeiten ausgedacht haben, ist es an der Zeit, sie mit qualitativen und quantitativen Daten zu konkretisieren.

Also, wo können wir diese Informationen finden?

Schau dir Quellen an wie:

• Webseiten-Analytik
• Einblicke in Facebook
• Kundenbefragungen und Umfragen
• Branchenberichte
• Kundeninterviews oder
• Produktinterne Analytik

Nachdem Sie all diese Informationen durchgesehen haben, können Sie die Daten Ihren ursprünglichen Annahmen zuordnen.

Am Ende der Übung sollten Sie und Ihr Team eine ziemlich gute Vorstellung davon haben, wer Ihre Kunden sind und wie Sie sie am besten betreuen, mit ihnen kommunizieren und Lösungen für sie entwickeln können.

Kundenpersonas in Jira

Sobald diese Personas entwickelt wurden, besteht die Herausforderung darin, zu entscheiden, wo sie gespeichert werden sollen.

Wenn Sie die Personas gut sichtbar machen, sollten Sie Ihr Team dazu ermutigen, sie jedes Mal in Betracht zu ziehen, wenn neue Arbeit in den Backlog aufgenommen wird. Sie möchten, dass sie denken: „Was würde Sam, der Systemadministrator, von dieser neuen Funktion halten? Würde sie es benutzen? Wie würde sie ihrem Team die Vorteile vermitteln? Auf welche Probleme kann Sam beim ersten Gebrauch stoßen?“

Deshalb haben wir eine App für Jira entwickelt — Easy Agile Personas.

Easy Agile Personas ermöglicht es dir, deine User Personas parallel zu deiner Arbeit in Jira zu erstellen und zu verwalten, sodass das gesamte Team den Kunden im Auge behalten kann.

Unabhängig davon, ob Sie sich für Easy Agile Personas entscheiden oder nicht, die von Ihnen entwickelten Kundenpersonas sind für die Erstellung von User Story Maps von entscheidender Bedeutung.

Probiere es jetzt