User Story Maps

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.

‍

Bei Easy Agile suchen wir ständig nach neuen Wegen, um unsere Produkte zu verbessern. Eine der Möglichkeiten, Innovationen zu fördern, sind die Dash Days — eine fokussierte Phase, in der unser Team von den täglichen Aufgaben Abstand nimmt, um zu experimentieren, zu erforschen und neu zu erfinden, wie unsere Tools den Kunden besser dienen können.

Während unserer letzten Dash Days haben wir die Benutzeroberfläche von zwei unserer Flaggschiffprodukte neu betrachtet: Einfacher agiler Teamrhythmus und Einfache agile Programme. Ziel war es, die Interaktion und Auffindbarkeit zu verbessern, damit Benutzer den vollen Nutzen unserer Tools ohne unnötige Komplexität nutzen können.

Hier erhalten Sie einen Einblick in unseren Denkprozess, unsere Herausforderungen und die aufregenden Lösungen, die wir untersucht haben.

Die Herausforderung

Im Zuge der Weiterentwicklung der Programme Easy Agile TeamRhythym und Easy Agile haben wir leistungsstarke Funktionen eingeführt, die den Benutzern mehr Kontrolle und Flexibilität bieten. Mit dem Hinzufügen neuer Funktionen wurde die Benutzeroberfläche jedoch ausgefeilter. Für uns ist dies eine Chance — eine Gelegenheit, einen Schritt zurückzutreten, die Benutzererfahrung zu vereinfachen und den Benutzern zu helfen, mehr von dem zu nutzen, was unsere Produkte bieten.

Um diesem Problem zu begegnen, haben wir Mitarbeiter aus dem gesamten Unternehmen zusammengebracht, um zu überlegen, wie wir das Erlebnis mit beiden Produkten verbessern können. In diesen Sitzungen haben wir einige wichtige Möglichkeiten identifiziert:

• Auffindbarkeit: Wie erleichtern wir es Benutzern, die leistungsstarken Funktionen unserer Tools zu finden und zu verwenden?
• Sichtbarkeit: Was ist der beste Weg, um Benutzern die richtigen Informationen und Funktionen zur Verfügung zu stellen, wenn sie sie benötigen?
• Kohärenz: Wie schaffen wir ein einheitlicheres Erlebnis innerhalb und zwischen unseren Produkten, um die Navigation intuitiver zu gestalten?

Mit diesen Erkenntnissen ausgestattet, machten wir uns dann daran, Lösungen zu finden, die auf die individuellen Herausforderungen jedes Produkts zugeschnitten sind.

Ein persönlicheres Erlebnis mit Easy Agile Programs

Bei den Programmen haben wir uns auf drei konzentriert.“wie könnten wir“ Fragen, um unsere Herausforderungen in Chancen umzuwandeln:

1. Wie können wir den Fokus mehr auf die Aktionen legen, die Benutzer ausführen möchten?
2. Wie können wir die Navigation intuitiver und einfacher gestalten?
3. Wie können wir Benutzern helfen, wenn sie mehr Kontext darüber erhalten, wo sie sich in der App auf einem bestimmten Bildschirm befinden?

Von den vielen Lösungen, die wir untersucht haben, war diejenige, die uns am meisten begeistert hat, die Idee einer Startbildschirm von Easy Agile Programs—ein personalisiertes Dashboard, das die Benutzer je nachdem, wo sie sich in ihrem Planungszyklus befinden, als Leitfaden dient.

Dieser Startbildschirm könnte sich an die Position anpassen, an der sich die Benutzer auf ihrer Reise befinden, und relevante Anleitungen und Aktionen anbieten.

• Für neue Nutzer, der Startbildschirm könnte klare Onboarding-Schritte und einen einfachen Zugriff auf die Hilfe bieten, sodass sie schnell und sicher loslegen können.
• Für erfahrene Anwender, es könnte Einblicke und wichtige Maßnahmen im Zusammenhang mit ihren Fortschritten bieten, sodass sie sich auf das konzentrieren können, was am wichtigsten ist. Benutzer sehen möglicherweise sogar Daten, die ihre Erfolge zusammenfassen, was es einfacher macht, Erfolge mit ihren Teams zu teilen.

Ganz gleich, ob jemand mit dem Produkt noch nicht vertraut ist oder gerade mit der Umsetzung begonnen hat, der Startbildschirm könnte eine großartige Möglichkeit sein, unsere Benutzer anzuleiten und zu coachen und ihnen dabei zu helfen, Fragen wie „Was soll ich als Nächstes tun?“ zu beantworten. oder „Welchen Mehrwert verpasse ich?“.

Eine fokussiertere Oberfläche für Easy Agile TeamRhythm

Für TeamRhythym lauteten unsere drei wichtigsten „Wie könnten wir“ -Fragen:

• Wie können wir bei der Sprint-Planung mehr Fokus auf die User Story Map legen?
• Wie können wir die Auffindbarkeit von Problemen ohne Epen verbessern?
• Wie können wir das Layout verbessern, um wichtige Funktionen hervorzuheben und die allgemeine Benutzerfreundlichkeit zu verbessern?

Vor dem Hintergrund dieser Fragen haben wir eine Reihe von Ideen untersucht, um die Sprint-Planung zu vereinfachen und es Benutzern zu erleichtern, ihre Arbeit vorzubereiten, zu planen und zu überprüfen, unabhängig davon, ob sie Scrum oder Kanban verwenden.

Die Sprint-Planung kann sich manchmal überwältigend anfühlen, wenn mehrere Sprints um Aufmerksamkeit konkurrieren. Um den Benutzern zu helfen, sich zu konzentrieren, haben wir die Idee untersucht, eine einzuführen fokussierter Blick bei der Sprint-Planung.

• Dies würde es Benutzern ermöglichen, einen bestimmten Sprint und nur den Backlog zu vergrößern, während andere ausgeblendet werden.
• Jedes Problem hätte seine eigene Zeile in der Detailansicht, und Benutzer können entweder eine ganze Zeile ziehen und ablegen oder einzelne Probleme ziehen, um sie schnell nach Prioritäten zu ordnen.
• In der Sprint-Ansicht werden auch Epics ausgeblendet, die im aktuellen Sprint keine verknüpften Probleme haben, sodass die Benutzer einen klareren Überblick darüber haben, was für ihre aktuelle Arbeit relevant ist.

Wir haben auch nach Möglichkeiten gesucht Verbessern Sie die User Story Map-Oberfläche um die nützlichsten Tools und Funktionen in den Vordergrund zu stellen. Indem wir die Darstellung wichtiger Funktionen verbessern, helfen wir Teams dabei, schnell auf das zuzugreifen, was sie benötigen, wann sie es benötigen, sodass sie ohne Unterbrechung produktiv bleiben können.

Auf diese Weise können wir Teams, die TeamRhythm verwenden, ein reibungsloseres, fokussierteres Erlebnis bieten, sodass sie sich auf das konzentrieren können, was vor ihnen liegt, ohne von allem anderen abgelenkt zu werden.

Du bist dran. Was denkst du?

Bei Easy Agile denken wir immer darüber nach, was als Nächstes kommt.

Diese Ideen stehen noch nicht auf unserer offiziellen Roadmap, aber sie sind die Art von Innovationen, auf die wir uns freuen.

Wenn Sie der Meinung sind, dass diese Änderungen Ihre Erfahrung mit Easy Agile TeamRhythm und Easy Agile Programs verbessern würden, lassen Sie es uns wissen! Ihr Feedback hilft uns bei der Entscheidung, welche Prioritäten gesetzt werden sollen, damit wir weiterhin Tools entwickeln können, die für Ihre Teams wirklich einen Unterschied machen.

‍

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.

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.

Storypoints können etwas verwirrend sein und werden oft missverstanden. Story Points sind ein wichtiger Bestandteil des User Story Mappings, und viele agile Teams verwenden sie bei der Planung ihrer Arbeit. Sie sind jedoch nicht so einfach wie das Hinzufügen von Zahlen zu Aufgaben oder das Abschätzen, wie lange ein Job dauern wird.

Selbst wenn Sie Story Points schon eine Weile verwenden, werden Sie feststellen, dass verschiedene Teams und Organisationen sie unterschiedlich verwenden.

Lassen Sie uns also Storypoints definieren, besprechen, warum sie für agile Teams so nützlich sind, und über einige der verschiedenen Arten sprechen, wie Teams sie beim Story-Mapping und der Sprint-Planung umsetzen.

Was sind User Story Points?

Story Points sind eine nützliche Maßeinheit in Agile und ein wichtiger Bestandteil der Prozess zur Zuordnung von User Storys. Sie weisen jeder User Story eine Zahl zu, um den Gesamtaufwand abzuschätzen, der erforderlich ist, um ein Feature oder eine Funktion zum Leben zu erwecken.

Wann sollten Storypoints geschätzt werden?

User Stories können während des User Story-Mappings, der Backlog-Verfeinerung oder während der Sprint-Planung geschätzt werden.

Sobald eine User Story definiert, dem Backbone zugeordnet und priorisiert wurde, ist es an der Zeit, die Storypoints abzuschätzen. Es ist eine gute Idee, dabei mit Ihrem Team zusammenzuarbeiten, da jedes Teammitglied in verschiedenen Storys eine andere Rolle spielt und die Arbeit kennt, die mit UX, Design, Entwicklung, Test und Markteinführung verbunden ist. Die Zusammenarbeit bei der Schätzung von Storypoints hilft dir auch dabei, Abhängigkeiten frühzeitig zu erkennen.

Es empfiehlt sich, jeder User Story Story Points zuzuweisen, bevor du sie in Releases oder Sprints aufteilst. Auf diese Weise können Sie die Komplexität, den Aufwand und die Ungewissheit jeder User Story im Vergleich zu anderen in ihrem Backlog einschätzen und fundierte Entscheidungen über die Arbeit treffen, die Sie für jeden Sprint oder Release aufwenden.

Wie schätzt man User Story Points ein

Bei der Schätzung von Story Points berücksichtigen Sie den Gesamtaufwand, der erforderlich ist, um dieses Feature oder diese Funktion verfügbar zu machen, damit sie dem Kunden einen Mehrwert bieten kann. Ihr Team muss Fragen wie die folgenden besprechen:

• Wie komplex ist die Arbeit?
• Wie viel Arbeit ist erforderlich?
• Was sind die technischen Fähigkeiten des Teams?
• Was sind die Risiken?
• Bei welchen Teilen sind wir uns nicht sicher?
• Was müssen wir an Ort und Stelle haben, bevor wir beginnen oder fertig werden können?
• Was könnte schief gehen?

Tipp: Wenn du Schwierigkeiten hast, eine Story einzuschätzen oder der Umfang der Arbeit überwältigend ist, musst du deine Story möglicherweise in kleinere Teile zerlegen, um mehrere User Stories zu erstellen.

Was ist ein Storypoint wert?

An dieser Stelle können Storypoints etwas verwirrend werden, da Storypoints keinen festgelegten universellen Wert haben. Du musst irgendwie herausfinden, was sie für dich und dein Team wert sind (ja, wirklich tiefgründiges und bedeutungsvolles Zeug).

So funktioniert das:

• Jeder Geschichte wird eine bestimmte Anzahl von Storypoints zugewiesen
• Punkte bedeuten für verschiedene Teams oder Organisationen unterschiedliche Dinge.
• Ein Storypoint für dein Team entspricht möglicherweise nicht dem gleichen Aufwand, der mit einem Storypoint für ein anderes Team verbunden ist
• Der Aufwand für 1 Story Point sollte stabil bleiben dein Teamarbeit bei jedem Sprint und es sollte von einer Story zur nächsten stabil bleiben
• 2 Story Points sollten dem doppelten Aufwand im Vergleich zu 1 Story Point entsprechen
• 3 Story Points sollten dem dreifachen Aufwand entsprechen im Vergleich zu 1 Story Point... und so weiter

Die Zahl, die Sie vergeben, spielt keine Rolle — was zählt, ist das Verhältnis. Die Story Points sollen dir dabei helfen, den relativen Aufwand zwischen jeder Story und jedem Sprint nachzuweisen.

Zum ersten Mal Storypoints einschätzen

Da Story Points relativ sind, müssen Sie sich einige grundlegende Schätzungen geben, wenn Sie zum ersten Mal eine Story Point-Schätzung durchführen. Dadurch erhalten Sie einen Bezugsrahmen für alle zukünftigen Geschichten.

Wählen Sie zunächst Geschichten in verschiedenen Größen aus:

• Eine sehr kleine Geschichte
• Eine mittelgroße Geschichte
• Eine große Geschichte

... ein bisschen wie T-Shirt-Größen.

Weisen Sie dann jeder dieser grundlegenden Geschichten Punkte zu. Ihre kleinste Geschichte könnte 1 sein. Wenn deine mittlere Geschichte dreimal mehr Aufwand erfordert, dann sollte es 3 sein. Wenn Ihre große Geschichte den 10-fachen Aufwand erfordert, sollte es das 10-fache sein. Diese Zahlen hängen von der Art der Geschichten ab, an denen Ihr Team normalerweise arbeitet, sodass Ihre grundlegenden Story-Zahlen möglicherweise anders aussehen als diese.

Das Wichtigste ist, dass Sie diese grundlegenden Geschichten verwenden können, um all Ihre zukünftigen Geschichten abzuschätzen, indem Sie den relativen Aufwand vergleichen.

Mit der Zeit werden Sie und Ihr Team feststellen, dass es einfacher wird, Nutzerberichte einzuschätzen, wenn sich Ihr gemeinsames Verständnis der Arbeit entwickelt. Hier werden Storypoints am wertvollsten. Sie helfen Ihrem Team dabei, die Erwartungen aufeinander abzustimmen und effektiver zu planen.

Vereinfachen Sie die Schätzung

Eine App für Jira wie Einfacher agiler Teamrhythmus macht es einfach, das Teamengagement für jeden Sprint oder jede Version zu sehen, mit geschätzten Gesamtwerten für jede Swimlane.

Verwendung der Fibonacci-Sequenz zur Story-Point-Schätzung

Einige Teams verwenden die Fibonacci-Sequenz (1, 2, 3, 5, 8, 13, 21, 34, 55, 89 usw.) für ihre Story-Point-Schätzungen, anstatt linear zu bleiben oder Teams zu erlauben, eine beliebige Zahl (1, 2, 3, 4, 5, 6, 7 usw.) zu verwenden.

Das hat seine Vorteile. Wenn Sie sich beispielsweise eine Geschichte ansehen und abschätzen möchten, ob es sich um eine 5, 8 oder 13 handelt, ist es viel schneller und einfacher, eine Antwort zu finden, als zu versuchen, auf der richtigen Zahl zwischen beispielsweise 4-15 zu landen. Sie werden wahrscheinlich viel schneller zu einem Konsens kommen.

Das bedeutet auch, dass ihr nicht in der Lage sein werdet, den Durchschnitt der Storypoints des Teams zu ermitteln, um die Schätzung abschliessen zu können. Stattdessen müsst ihr die Arbeit besprechen und euch für die beste Schätzung aus einer begrenzten Anzahl von Optionen entscheiden.

Aber es schränkt Ihre Möglichkeiten ein — wenn Sie eine Geschichte haben, die mehr Aufwand als 34, aber weniger als 55 erfordert, ist Ihre Schätzung möglicherweise weniger genau.

Verwendung von Story Points zur Schätzung der Geschwindigkeit

Nach einiger Zeit der Zusammenarbeit werden die meisten Teams eine gute Vorstellung davon haben, wie viel Aufwand in den einzelnen Storypoints steckt.

Natürlich ist das Timing nicht genau - es gibt eine Glockenkurve, und Story Points sind so konzipiert, dass sie eine Schätzung des Aufwands und nicht der Zeit sind.

Storypoints (und die Kenntnis ihres ungefähren Zeitpunkts) können jedoch hilfreich sein, wenn es darum geht, herauszufinden, wie viel Ihr Team in jedem Sprint erledigen kann.

Du solltest in der Lage sein, abzuschätzen, wie viele Storypoints dein Team während eines zweiwöchigen Sprints bewältigen kann, oder in welchem Zeitrahmen auch immer du gerade arbeitest.

Wenn dein Team beispielsweise in der Regel 3 Story Points pro Tag durchstehen kann, können sich in einem zweiwöchigen Sprint bis zu 30 Story Points summieren. Das ist deine Geschwindigkeit.

Velocity ist nützlich für das User Story Mapping und die Sprint-Planung. Wenn Sie Ihre User Stories Sprints oder Versionen zuordnen, können Sie die Gesamtzahl der Storypoints überprüfen und sicherstellen, dass sie mit Ihrer Geschwindigkeit übereinstimmt, damit Sie sich nicht zu sehr oder zu wenig engagieren.

Wie Sie sehen, gibt es verschiedene Methoden zur Schätzung der Arbeit. Der beste Rat ist, konservativ zu sein und das Team nicht zu überlasten.

Im Laufe der Zeit sollten Ihre Schätzungen genauer werden.

Verwendung von Story Points in Scrum, Kanban und Extreme Programming

Story Points sind in vielen agilen Methoden von zentraler Bedeutung für Schätzungs- und Planungsprozesse. Scrum und Extreme Programming (XP) stützen sich stark auf Story Points, um den Aufwand und die Komplexität von User Stories einzuschätzen.

Scrum-Teams verwenden während der Sprint-Planung Storypoints, um zu entscheiden, welche Aufgaben in den kommenden Sprint aufgenommen werden sollen, und fördern so Diskussionen, die zu einem gemeinsamen Kontext und einem gemeinsamen Verständnis der Arbeit führen.

Extreme Programming hingegen verwendet Story Points, um die Größe von Funktionen zu beurteilen, sodass Teams Ressourcen effektiv priorisieren und zuweisen können. Teams, die Kanban verwenden, können von Storypoints profitieren, indem sie sie nutzen, um Grenzen für laufende Aufgaben festzulegen und den gesamten Aufgabenablauf zu optimieren.

Die spezifischen Praktiken können sich zwar unterscheiden, aber Story Points können dazu beitragen, die Zusammenarbeit im Team und einen vorhersehbareren Arbeitsablauf zu fördern.

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.

Es ist eine der gängigsten Praktiken in der agilen Softwareentwicklung; der flache Produkt-Backlog. Wir haben sie alle gesehen, wir haben alle zu ihnen beigetragen und wir sind alle unweigerlich in ihnen ertrunken.

In seiner einfachsten Form ist ein flacher Produktrückstand eine lange Liste mit Dingen, die zu erledigen sind, die dem Kunden letztendlich einen Mehrwert bieten. Diese umsetzbaren Punkte werden in der Reihenfolge, in der der Wert geliefert wird, priorisiert (von oben nach unten). Wenn ein Team die Scrum-Methode anwendet, wird das Backlog in zukünftige Sprints aufgeteilt, um einen Hinweis darauf zu geben, was wann geliefert wird.

Je nach Größe und Anforderungen der Organisation kann die Liste der zu erledigenden Aufgaben 10, 100 oder 1.000 umsetzbare Punkte umfassen. Es ist leicht nachzuvollziehen, dass die Verwaltung der letzteren Aufgaben mit den Herausforderungen einhergeht, diese Aufgaben zu aktualisieren, zuzuweisen, zu verbessern und zu planen.

Was ist falsch an flachen User Story Backlogs?

Bisher wissen wir, dass flache Rückstände eine Liste von Dingen darstellen, die getan werden müssen. Dies ist mit Herausforderungen verbunden, und seine Unzulänglichkeiten lassen sich am besten mit folgenden Worten beschreiben Jeff Patton, als er sagte;

Wir verbringen viel Zeit damit, mit unseren Kunden zusammenzuarbeiten. Wir arbeiten hart daran, ihre Ziele, ihre Benutzer und die wichtigsten Teile des Systems, das wir bauen könnten, zu verstehen. Dann kommen wir endlich zu den Details — den Teilen der Funktionalität, die wir entwickeln möchten. In meinem Kopf sehe ich einen Baum, in dem der Stamm auf den Zielen oder gewünschten Vorteilen basiert, die das System antreiben; große Zweige sind Benutzer; die kleinen Zweige und Zweige sind die Fähigkeiten, die sie benötigen; und schließlich sind die Blätter die Benutzergeschichten, die klein genug sind, um sie in Entwicklungsiterationen zu integrieren.



Nach all der Arbeit, nachdem wir all das gemeinsame Verständnis hergestellt haben, habe ich das Gefühl, dass wir alle Blätter vom Baum ziehen und sie in einen Laubsack laden — und dann den Baum fällen.



Das ist für mich ein flacher Backlog. Eine Tüte kontextfreien Mulchs

Wie wählen Sie einen Artikel aus einer Liste aus und halten ihn für das, was Ihren Kunden den größten Mehrwert bietet, ohne diesen zusätzlichen Kontext?

Mängel eines flachen Produktrückstands

• Der flache Backlog macht es unmöglich, das „Rückgrat“ Ihres Produkts zu entdecken — das Interaktionserlebnis des Kunden mit dem Produkt
• Das Anordnen der User Stories in der Reihenfolge, in der sie geliefert werden, hilft einem Produktmanager nicht, anderen zu erklären, was das System tut
• Das flache Backlog bietet keinen Kontext oder ein Gesamtbild der Arbeit, die ein Team leistet
• Ein flacher Backlog macht es für den Produktmanager schwierig, festzustellen, ob er die relevanten User Stories identifiziert hat
• Bei einem flachen Backlog ist die Release-Planung schwierig. Wie priorisiert man in einer endlosen Wäscheliste, was zuerst erstellt werden soll?

Story-Maps von Benutzern

Eine Storymap ist eine visuelle Darstellung von die Reise, die ein Kunde mit einem Produkt unternimmt, einschließlich der Aktivitäten und Aufgaben, die sie erledigen. Diese Visualisierung hilft dem Team, die Entwicklung darauf zu konzentrieren, den Kunden den größtmöglichen Nutzen zu bieten und die gewünschten Ergebnisse zu erzielen.

Es bietet Kontext für Teams, indem es die folgenden Fragen beantwortet:

• Warum bauen wir das?
• Für wen bauen wir das?
• Welchen Wert bietet die Lösung für den Kunden und wann?

Die Story-Map zeigt immer noch, was getan werden muss, aber der Unterschied besteht hier in der Art und Weise, wie diese Informationen visualisiert werden. Wie Sie sehen können, wird jedes Element nicht aufgelistet, sondern einem größeren Werk zugeordnet. Neben der Art und Weise, wie die Informationen visualisiert werden, besteht der Hauptunterschied zwischen einem flachen Produkt-Backlog und einer User Story Map in der Fokussierung auf die Customer Journey. Lassen Sie uns das entpacken, indem wir die Anatomie der User Story Map aufschlüsseln.

Was eine User Story Map erreicht, was ein flaches Produkt-Backlog nicht kann

• Konzentrieren Sie sich auf die gewünschten Kundenergebnisse: Die Visualisierung der Kundenreise ermöglicht es Teams, Funktionen auf der Grundlage der Kundenergebnisse zu identifizieren und zu implementieren und den Fortschritt auf einen Blick anhand einer Storymap zu verfolgen
• Erwecken Sie die Customer Journey zum Leben: Die Transformation des flachen Produkt-Backlogs in eine kundenorientierte Storymap bedeutet, dass die Teams ihre Customer Journey besser verstehen und wissen, was ihre Kunden wollen und schätzen
• Priorisierung von Maßnahmen auf der Grundlage des Nutzens für den Kunden: Die Visualisierung der Kundenreise ermöglicht es Teams, die Arbeit auf der Grundlage des „Nutzens für den Kunden“ zu priorisieren, was zu besseren Ergebnissen und weniger Verschwendung führt

Verirren Sie sich in Ihrem flachen Produktbacklog? Sie stecken in einem endlosen Entwicklungszyklus fest, sind sich aber nicht sicher, über wen oder warum Ihr Gebäude verfügt?

Einfacher agiler Teamrhythmus

Easy Agile TeamRhythm unterstützt User Story Mapping, Sprint- oder Versionsplanung, Backlog-Refinement und Team-Retrospektiven.

Das Sprintziel ist ein wichtiger Aspekt jedes Sprints und sollte während Ihres zweiwöchigen Prozesses im Mittelpunkt stehen. Das Ziel stellt sicher, dass sich das Team auf ein klares Ziel für den Sprint konzentriert, und wenn es gut gemacht wird, inspiriert das Team, während des gesamten Sprints auf Kurs zu bleiben.

Was macht also ein gutes Sprintziel aus und wie passt das Sprintziel in den Rahmen eines Sprints? In diesem Beitrag werden wir im Wettlauf (oder sollten wir sagen Sprint 😉) eine Zusammenfassung des Scrum-Prozesses durchgehen, gefolgt von einer Liste mit fünf kritischen Elementen eines effektiven Sprintziels. Du erfährst, wie du deine Sprintziele für einen erfolgreichen Sprint alle zwei Wochen am besten erstellst, verwaltest und umsetzt.

Ein Überblick über den Scrum-Prozess

Wir sind große Fans von Gedränge! Brauchen Sie eine kleine Auffrischung? So funktioniert der Scrum-Prozess und wo das Sprintziel in das Gesamtbild passt.

Scrum ist ein agiles Framework, das hauptsächlich von Softwareentwicklungsteams verwendet wird und den Teammitgliedern einen optimierten Arbeitsablauf bietet, um die Bedürfnisse von Stakeholdern und Kunden zu erfüllen. Der Scrum-Workflow umfasst vier Besprechungen (auch bekannt als Zeremonien), die alle einen bestimmten Zweck haben. Diese Struktur bedeutet, dass sich die Teammitglieder problemlos gegenseitig unterstützen können, indem sie Ergebnisse teilen, verfolgen und verbessern.

Das Scrum-Framework unterteilt die Arbeit in sich wiederholende zweiwöchige Sprints, in denen ein festgelegter Arbeitsaufwand — das Sprintziel — abgeschlossen wird. Jedes Scrum beginnt mit einem Sprint-Planungsmeeting, und während dieser Zeit definiert der Product Owner das Sprintziel. Sie entscheiden, welche Aufgaben aus dem Produkt-Backlog in das Sprint-Backlog übertragen werden, um im darauffolgenden zweiwöchigen Sprint abgeschlossen zu werden.

Die Artikel im Produktbacklog geben einen Überblick darüber, was vor der Fertigstellung oder Veröffentlichung eines Produkts zu tun ist. Die Elemente des Sprint-Backlogs sind das, was das Team (hoffentlich) im Laufe des Sprints erreichen wird.

Das Scrum Master fungiert als Scrum-Guide, der das Team durch die Besprechungen und Schritte des Scrum-Prozesses führt. Während des gesamten Sprints trifft sich das Scrum-Team zu einem tägliches Scrum um miteinander abzuchecken und berichten Sie, welche Arbeiten in den letzten 24 Stunden abgeschlossen wurden.

Am Ende des Sprints ein Sprint-Review und Sprint-Rückblick helfen Sie dem Team, Feedback von Stakeholdern einzuholen und ihre Prozesse zu verbessern, bevor der nächste Sprint beginnt. Der gesamte Prozess wiederholt sich bei der Sprint-Planung erneut und wiederholt sich so lange, bis das Produkt oder Projekt abgeschlossen ist.

Einfache Sprint-Planung:

Ziehe Elemente direkt aus deinem Backlog auf deine TeamRhythm User Story Map. Bearbeiten Sie Story-Zusammenfassungen und Story-Point-Schätzungen online. Zeige dein Sprintziel auf jeder Sprint-Swimlane an.

PROBIERE: TEAMRHYTHM SANDBOX DEMO

Was macht ein gutes Sprintziel aus?

Das Sprintziel sorgt dafür, dass sich das Team darauf konzentriert, was jeder für jeden Sprint zu erreichen versucht. Es ist eine Erweiterung der allgemeinen Produkt- oder Projektziele, aber das Sprintziel kann sich auf wichtige Komponenten konzentrieren, die das Team für diesen bestimmten Sprint in Angriff nehmen möchte.

Was macht ein gutes Sprintziel aus? Lass es uns herausfinden.

1. Das Ziel ist erreichbar

Das Ziel des Sprints muss innerhalb des für den Sprint vorgesehenen Zeitrahmens erreichbar sein. Im Allgemeinen ist das Team in einem Scrum-Framework an zwei Wochen gebunden.

Wenn neue Informationen gewonnen werden und andere Hindernisse auftreten, besteht immer die Möglichkeit, dass das Sprintziel nicht erreicht wird. Das sollte Sie jedoch nicht davon abhalten, erreichbare Ziele zu setzen. Wenn ein Team die Ziele des Sprints und des Projekts kontinuierlich nicht erreicht, sinken die Moral und der Enthusiasmus.

Es ist wichtig, dass die Sprintziele innerhalb der vorgegebenen Zeit des Sprints überschaubar sind. Sprintziele können zu groß werden, wenn ein Team versucht, zu viele verschiedene Komponenten gleichzeitig zu erledigen, oder wenn zu viel vom Produkt-Backlog in das Sprint-Backlog aufgenommen wird. Nehmen Sie stattdessen eine einigermaßen erreichbare Arbeitslast aus dem Produkt-Backlog heraus, um das Sprint-Backlog zu bilden. Andernfalls erhalten Sie am Ende eine entmutigende Gesamtliste und keine klare Richtung für jeden Sprint.

2. Das Team versteht die Definition von erledigt

Je klarer das Sprintziel, desto besser. Du musst die Ziele des Sprints klar definieren und klar definieren, was es bedeutet, getan zu werden. Woher weiß das Team, ob es die gewünschten Ergebnisse erzielt hat? Wie sieht „erledigt“ aus? Sind sich alle über diese Definition für jede gegebene Aufgabe und die Gesamtziele des Sprints einig?

Deine Ziele müssen messbar sein, um Unklarheiten, Subjektivität oder widersprüchliche Meinungen über den Erfolg des Sprints zu vermeiden.

Wenn ein Team aufeinander abgestimmt ist und jeder versteht, was erreicht werden muss, verbessert sich die Entscheidungsfindung und jeder Aspekt des Scrum-Teams kann harmonisch auf dieselben Ziele hinarbeiten.

3. Das Sprintziel ist für das Team von Bedeutung

Das Team muss nicht nur wissen, was das Team in jedem Sprint zu erreichen hofft, sondern auch die Gründe hinter dem Sprintziel verstehen.

Stellen Sie sicher, dass jeder versteht, warum er auf ein bestimmtes Sprintziel hinarbeitet. Welche Bedeutung hat das Sprintziel? Im Idealfall bezieht sich die Bedeutung des Sprintziels auf die Bedürfnisse der Stakeholder, die Kundenreise oder die Benutzererfahrung Ihres Produkts.

Visualisieren und priorisieren Sie die Arbeit, die Ihren Kunden den größten Mehrwert bietet

Einfacher agiler Teamrhythmus

VERSUCHE ES JETZT

4. Das Sprintziel entspricht den allgemeinen Produktzielen

Das Sprintziel kann sich auf einen bestimmten Aspekt der Produktentwicklung konzentrieren, sollte aber dennoch mit den allgemeinen Produktzielen in Verbindung stehen.

Stellen Sie bei der Erstellung von Sprintzielen sicher, dass die übergreifende Produktvision nicht verloren geht oder ignoriert wird. Jeder Sprint ist zwar spezifisch für seine eigenen Ziele, sollte aber darauf abzielen, Ihre Produktziele zu erreichen.

5. Das Sprintziel ist während des gesamten Sprints sichtbar

Das Sprintziel kann kein „Setz es und vergiss es“ -Aspekt deines Sprints sein. Es sollte für das Team die ganze Zeit sichtbar sein, und das Team muss das Ziel kontinuierlich überprüfen, um sicherzustellen, dass es auf dem richtigen Weg ist, es zu erreichen.

Das gemeinsame Ziel sollte im Mittelpunkt der täglichen Scrum-Meetings stehen. Wenn möglich, zeigen Sie das Sprintziel für alle sichtbar an. Beziehen Sie sich beim Erledigen der Backlog-Elemente und beim Durcharbeiten des Sprints kontinuierlich auf das Sprintziel und die Fortschritte, die Sie auf dem Weg dorthin machen. Wie wahrscheinlich ist es, dass Sie das Sprintziel erreichen, wenn Sie die verbleibende Zeit des Sprints berücksichtigen? Was könnte der Erreichung dieses Ziels im Weg stehen?

Während der Sprint-Retrospektive solltest du den Erfolg oder Misserfolg besprechen, den das Team beim Sprintziel erzielt hat. Was lief gut und hat zu deinem Erfolg beigetragen? Was lief nicht so gut, dass du es für den nächsten Sprint ändern oder anders machen könntest?

Mit Easy Agile TeamRhythm verfügt jedes Scrum Board in Jira über eine zugehörige User Story Map.

Während des gesamten Sprints kann das Team auf die User Story Map zurückgreifen, um sicherzustellen, dass der Zeitplan eingehalten wird, Abhängigkeiten koordiniert und das Gesamtbild im Blick behält.

MACHEN SIE EINE PRODUKTTOUR

Ein kundenorientierter Ansatz

Lassen Sie uns einige der wichtigsten Faktoren zusammenfassen, die Sie bei der Festlegung und Umsetzung Ihres Sprintziels berücksichtigen sollten:

✅ Stellen Sie sicher, dass das Ziel erreichbar ist.

✅ Stellen Sie sicher, dass das Team die Definition von erledigt versteht.

✅ Stellen Sie sicher, dass das Sprintziel für das Team von Bedeutung ist.

✅ Stellen Sie sicher, dass das Sprintziel mit den allgemeinen Produktzielen übereinstimmt.

✅ Stellen Sie sicher, dass das Sprintziel während des gesamten Sprints sichtbar ist.

Vielen Dank, dass Sie bei uns bleiben und den Easy Agile-Blog nutzen. Wir sind begeistert davon, Teams dabei zu helfen, mit Agile besser zu arbeiten. Wir haben eine Suite von Jira-Apps entwickelt, um den Kunden bei jedem Schritt des Entwicklungsprozesses im Auge zu behalten.

Suchen Sie nach einem Tool zur Optimierung Ihrer Sprint-Planungssitzungen? Auschecken Einfacher agiler Teamrhythmus, was den flachen Produktbestand in ein aussagekräftiges Bild der Arbeit verwandelt.

Die Retrospektive ist ein wichtiger Teil des agilen Prozesses und bietet Teams die Möglichkeit, zu erörtern, wie sie sich verbessern können. Eine Sprint-Retrospektive findet am Ende jedes Sprints statt und bietet dem Team die Möglichkeit, seine Prozesse zu bewerten.

Was ist gut gelaufen? Was ist nicht so gut gelaufen? Was muss das Team tun, um sich beim nächsten Mal zu verbessern? Bei Agile dreht sich alles ums Lernen und Iterieren. Jedes Mal, wenn Sie einen Sprint abschließen, gibt es Lektionen zu lernen. Agile nimmt kontinuierlich das, was ein Team lernt — die guten, die schlechten und die langweiligen — und setzt diese Erfahrungen in umsetzbare Verbesserungen um.

Dieser Beitrag befasst sich mit Sprint-Retrospektiven, einschließlich der Vorteile, ihrer Einbettung in den Scrum-Prozess, der Durchführung eines effektiven Sprint-Retrospektiv-Meetings und der häufigsten Fehler, die es zu vermeiden gilt.

Der Zweck der Sprint-Retrospektive

Die Sprint-Retrospektive ist der Teamdiskussion gewidmet. Die Zeit wird am Ende jedes Sprints zugeteilt, sodass alle Teammitglieder überprüfen können, was gut gelaufen ist und was geändert werden muss. Das alles ist Teil der agileren Methode, Ihre Prozesse kontinuierlich zu verbessern, während Sie mehr lernen. Es gibt keine festgelegte Vorgehensweise, und es gibt immer Spielraum, um effizienter und effektiver zu werden.

Ein Sprint-Rückblick:

• Fördert eine Denkweise der kontinuierlichen Verbesserung
• Schafft einen sicheren Raum für den Austausch von positivem und konstruktivem Feedback
• Gibt jedem im Team die Möglichkeit, Gedanken, Ideen und Erfahrungen auszudrücken
• Gibt nach jedem Sprint Feedback in Echtzeit
• Bringt das Team zusammen, um gemeinsame Ziele zu erreichen
• Zeigt alle Probleme aus dem vorherigen Sprint an, die das Team zurückhalten
• Informiert die Führung über Erfolge und mögliche Hindernisse
• Hilft Produktbesitzern, Entscheidungen für die nächste Sprint-Planung zu treffen
• Bringt das Team auf einen positiven Weg, um in den nächsten Sprint überzugehen

Wie die Sprint-Retrospektive in den Scrum-Prozess passt

Die Art der Retrospektive, die Sie abhalten, hängt von der Art des Sprints bzw. wendig Methodik Ihr Team trainiert. Eine der gängigsten Methoden in der Softwareentwicklung ist das Scrum-Framework.

Ein Scrum-Team hat drei Arten von Rollen:

• Inhaber des Produkts
• Scrum Master
• Entwicklungsteam

Zu Beginn jedes Scrums entscheidet der Product Owner, welche Artikel aus der Gesamtwertung Produkt-Backlog werden verschoben in die Sprint-Backlog muss im kommenden 2-4-wöchigen Sprint abgeschlossen werden. Der genaue Zeitrahmen für den Sprint wird im Voraus festgelegt.

Das Scrum besteht aus vier verschiedene Zeremonien oder Veranstaltungen:

• Sprint-Planung
• Tägliches Scrum oder Stand-ups
• Sprint-Bewertung
• Sprint-Rückblick

Nachdem die Planung abgeschlossen ist und das Team weiß, welche Backlog-Elemente es für den aktuellen Sprint angehen wird, beginnt die Arbeit. Das Team checkt während des gesamten Sprints über eine tägliches Scrum- oder Stand-up-Meeting. Dieser schnelle, aber wichtige Check-In ermöglicht es dem Scrum-Team, seine Fortschritte zu besprechen und potenzielle Hindernisse täglich zu beheben.

Das Sprint-Review-Meeting findet am Ende des Sprints statt; es ist eine Gelegenheit für die Mitglieder des Scrum-Teams, die während des Sprints geleistete Arbeit zu präsentieren. Dies kann eine interne Präsentation oder eine formellere Demonstration für Stakeholder sein.

Zuletzt kommt die unglaublich wichtige Scrum-Retrospektive. Während dieser Zeit kann das Team besprechen, was gut gelaufen ist und was verbessert werden könnte, damit der bevorstehende Sprint effizienter ablaufen kann. Alles, was im Laufe der Zeit gelernt oder in der Retrospektive entdeckt wurde, wird in die nächste Sprint-Planungssitzung aufgenommen. Dieser Scrum-Prozess wiederholt sich, bis es keine Artikel mehr im Produkt-Backlog gibt oder das Produkt vollständig ist.

So führen Sie ein effektives Sprint-Retrospektiv-Meeting durch

Die Retrospektive ist ein wichtiger Teil des agilen Prozesses, der mit Sorgfalt und Respekt behandelt werden sollte. Gehen Sie mit einem Plan rein. Wenn du zuwinkst, kommst du vielleicht durch, aber jeder wird mehr aus dem Prozess herausholen, wenn die Person oder die Personen, die die Retrospektive leiten, vorbereitet sind.

Verwenden Sie unsere unten aufgeführten Strategien, um effektive Retrospektiven durchzuführen, auf die sich alle freuen.

1. Stellen Sie sicher, dass die Stimme aller gehört wird

Die lautesten Stimmen in einer Sprint-Retrospektive erhalten oft die meiste Aufmerksamkeit und Redezeit, aber sie haben nicht unbedingt bessere Einblicke als alle anderen. Jeder Person, die am Sprint-Prozess beteiligt ist, sollte die Möglichkeit gegeben werden, zu sprechen.

Wenn Sie feststellen, dass einige Personen das Gespräch dominieren oder dass einige Personen nie etwas beitragen, ändern Sie Ihre Strategie, um alle einzubeziehen. Gehen Sie nacheinander durch den Raum und stellen Sie eine Frage, die jede Person beantworten muss, z. B. „Was ist Ihrer Meinung nach in diesem Sprint gut gelaufen?“ oder „Was war deine größte Herausforderung?“

2. Starten, stoppen, weitermachen

Das retrospektive Format „Start, Stop, Continue“ kann in vielen Formen ausgedrückt werden, aber die allgemeine Praxis ist dieselbe. Am Ende eines Sprints entscheiden Sie, womit Sie beginnen möchten, womit Sie aufhören möchten und was Sie weiter tun möchten, wenn Sie in Ihren nächsten Sprint übergehen. Es ist ein einfaches Format, das sowohl abdeckt, was gut als auch was nicht so gut gelaufen ist.

Andere Versionen dieser Übung umfassen die Rose Bud Thorn-Übung, bei der die Teilnehmer etwas Positives teilen, eine neue Gelegenheit und etwas Negatives, das es zu verbessern gilt. Es gibt auch die Übung „Anker und Segel“, bei der die Teilnehmer erzählen, was ihnen Wind in die Segel gebracht hat (lief gut) und was sie verankert hat.

3. Legen Sie bestimmte Aktionspunkte fest

Die Retrospektive ist Zeitverschwendung, wenn Sie nicht mit bestimmten Aktionspunkten abreisen. Was wird Ihr Team gegen die in der Besprechung aufgeworfenen Probleme unternehmen? Stellen Sie sicher, dass Sie den Überblick über die Probleme und das positive Feedback der Teilnehmer behalten, damit Sie sie vor Abschluss des Meetings in umsetzbare Aufgaben oder Ziele umwandeln können.

Sie können nicht absolut jede Änderung umsetzen, die angesprochen wird, aber die Diskussion sollte Ihnen einen Ausgangspunkt bieten. Arbeiten Sie mit dem Team zusammen, um herauszufinden, welche Änderungen die größte Wirkung haben. Sie können eine verwenden Wirkungsaufwandsmatrix oder ähnliche agile Tools, um fundierte Entscheidungen zu treffen.

4. Rückblick — der Rückblick

Nehmen Sie sich hin und wieder die Zeit, Ihre Retrospektive Revue passieren zu lassen. Bitten Sie alle Teammitglieder um Feedback, wie der Prozess verbessert werden könnte. Was würde die Erfahrung für das Team einfacher machen? Was würden sie gerne umgesetzt sehen? Was hat bei deinen wiederkehrenden Retros nicht funktioniert?

Wow, das wird ein bisschen Meta, aber es ist ein wichtiger Schritt. Sie müssen auch Ihren Rückblick kontinuierlich überprüfen, um sicherzustellen, dass Sie das Beste aus dem Erlebnis herausholen.

Eine Sache, auf die Sie achten sollten: Wenn sich Menschen langweilen, engagieren sie sich weniger, was bedeutet, dass es wichtig ist, die Dinge auf den Kopf zu stellen. Sie möchten nicht, dass Ihr retrospektiver Prozess stagniert oder an Effektivität verliert.

5. Prüfen Sie die Aktionspunkte bei der nächsten Sprint-Retrospektive

Stellen Sie sicher, dass sich die harte Arbeit Ihrer Retrospektive auszahlt. Nehmen Sie sich zu Beginn der nächsten Retrospektive etwas Zeit, um Ihre bisherigen Aktionspunkte zu überprüfen. Mit welchen Zielen und Aktionspunkten hast du die letzte Retrospektive verlassen? Haben Sie erreicht, was Sie sich vorgenommen haben, oder müssen Sie noch daran arbeiten?

Häufige Fehler bei der Rückschau, die es zu vermeiden gilt

Vermeiden Sie diese häufigen Fehler bei der Durchführung von Sprint-Retrospektiv-Besprechungen:

❌ Erlaube ein paar Leuten, das Gespräch zu dominieren

❌ Keine Stärkung leiser Stimmen

❌ Ohne gründliche Diskussion voreilige Schlüsse ziehen

❌ Immer wieder dieselben Fragen stellen, ohne die Dinge durcheinander zu bringen

❌ Die Aktionspunkte der vorherigen Retrospektive vergessen oder nicht umgesetzt

❌ Überspringen einer Retrospektive aus Zeit- oder Ressourcenmangel

❌ Vergessen der Bedürfnisse von Stakeholdern und Kunden

❌ Es gelingt Ihnen nicht, Ihren retrospektiven Prozess zu verbessern

Setzen Sie Ihre Retrospektiv-Ideen mit Easy Agile TeamRhythm in die Tat um

Sprint-Retrospektiven helfen dem gesamten Team, aus jeder Erfahrung zu lernen und sich zu verbessern. Sie effektiv durchzuführen bedeutet, die Retrospektive selbst zu bewerten, Stimmen zu stärken und ihnen zuzuhören.

Unsere Leidenschaft ist es, die Bedürfnisse des Kunden in den Vordergrund zu stellen. Easy Agile entwickelt Produkte, die speziell für Jira-Benutzer entwickelt wurden, um agilen Teams zu helfen, effizienter und effektiver zu arbeiten.

Einfacher agiler Teamrhythmus unterstützt die Arbeit Ihres agilen Teams von der Planung bis hin zur Retrospektive und fördert die kontinuierliche Verbesserung, damit Sie in dem, was Sie tun, immer besser werden und Ihren Kunden bessere Ergebnisse liefern.

EASY AGILE TEAMRHYTHM KOSTENLOS TESTEN

Das Sprint-Planning-Meeting hilft agilen Teams dabei, jeden Sprint zu planen und auf derselben Wellenlänge zu sein. Es ist eine Gelegenheit, auf der Grundlage der Produktvision, der Dringlichkeit des Problems, des Feedbacks der Stakeholder und des Wissens aus dem vorherigen Sprint über die Priorisierung zu entscheiden.

Ziel des Treffens ist es, festzulegen, welche Backlog-Elemente im kommenden Sprint angegangen werden sollten. Das Team entscheidet unter der Leitung des Product Owners und des Scrum Masters, welche Elemente aus dem Produkt-Backlog in das Sprint-Backlog verschoben werden sollen, damit sie in den kommenden Wochen (Sprint-Dauer) hoffentlich abgeschlossen werden können.

Die Sprint-Planung spielt im Scrum-Prozess eine entscheidende Rolle. Das Meeting stellt sicher, dass die Teams vorbereitet in einen Sprint starten und die Arbeitsaufgaben sorgfältig ausgewählt werden. Das Endergebnis sollte ein gemeinsames Verständnis der Sprintziele sein, das als Richtschnur für den nächsten Sprint dienen wird.

Die Sprint-Planung sollte zwar vor jeder Art von Sprint erfolgen, aber für die Zwecke dieses Artikels werden wir uns auf Sprint-Planungssitzungen für Scrum-Teams konzentrieren. Lesen Sie weiter, um unsere wichtigsten Tipps für ein erfolgreiches Sprint-Planungsmeeting zu erfahren. 🎉

Wie passt das Sprint-Planungsmeeting in das Scrum-Framework?

Scrum ist eine äußerst beliebte agile Methode, die in der Produktentwicklung eingesetzt wird. Der Prozess umfasst eine Reihe von Sprints, die auf der Grundlage des kontinuierlichen Feedbacks von Kunden, Stakeholdern und Teammitgliedern verbessert und angepasst werden.

Beim Sprint-Planungsmeeting kommt das gesamte Team zusammen, um zu entscheiden, welche Arbeit es im kommenden Sprint erledigen möchte. Der Product Owner hilft bei der Entscheidung, welche wichtigen Artikel aus dem Produkt-Backlog in den Sprint-Backlog. Dies ist eine unglaublich wichtige Phase, die die Ziele des Teams in den nächsten zwei Wochen bestimmt.

Der Scrum Master fungiert als Scrum Guide. Sie helfen dem Entwicklungsteam, in jedem Sprint auf Kurs zu bleiben und stellen sicher, dass jeder das Beste aus dem Prozess herausholen kann. Das Scrum-Team arbeitet zusammen, um den Arbeitsaufwand zu erledigen, der bei der Sprint-Planung festgelegt wurde. Um sicherzustellen, dass alle auf dem richtigen Weg und auf derselben Seite bleiben, tägliche Stand-ups finden jeden Tag statt. Dies bietet den Teammitgliedern die Möglichkeit, Probleme oder potenzielle Engpässe zu lösen, die einen reibungslosen Arbeitsablauf verhindern könnten.

Im Anschluss an den Sprint findet ein Sprint-Review statt, das den Stakeholdern die Möglichkeit gibt, Feedback zu geben. Schließlich ein Sprint-Rückblick Das Treffen gibt dem Team die Möglichkeit, seinen Prozess zu bewerten und zu verbessern. Das Scrum endet und beginnt erneut mit einem weiteren Sprint-Planungsmeeting.

Hier sind einige Tipps, um sicherzustellen, dass jedes Sprint-Planungs-Meeting Sie auf Erfolgskurs bringt:

1. Reservieren Sie die gleiche Zeit für die Sprint-Planung ⏰

Buchen Sie Ihr Sprint-Planungstreffen alle zwei Wochen am selben Tag und zur gleichen Zeit, um sicherzustellen, dass Ihr gesamtes Team dieses Zeitfenster zur Verfügung hat. Die Sprint-Planung ist entscheidend für den Erfolg jedes Sprints — es ist ein Meeting, das nicht durcheinander gebracht werden sollte.

Wählen Sie eine Zeit, die für alle Beteiligten geeignet ist, und bitten Sie Ihr Team um Feedback, wann es am besten ist. Planen Sie die Besprechungen weit im Voraus in den Kalender aller Beteiligten ein, damit niemand sie vergisst oder andere Termine bucht.

2. Lege eine Sitzungsdauer für die Sprint-Planung fest und halte dich daran ⏳

Die Sprint-Planung ist wichtig, aber das heißt nicht, dass sie ewig dauern sollte. Legen Sie ein Zeitlimit für Ihr Meeting fest und tun Sie Ihr Bestes, um es einzuhalten. Wenn Sie mit einer Tagesordnung gut vorbereitet sind und verfeinerter Backlog, Sie sollten in der Lage sein, direkt mit der Planung zu beginnen.

Wir empfehlen, nicht mehr als 2-4 Stunden für die Sprint-Planung einzuplanen. Lassen Sie den Scrum Master dafür verantwortlich sein, dass das Team auf dem richtigen Weg bleibt und die Planung in der vorgesehenen Zeit abschließt.

3. Schließe die Backlog-Verfeinerung ab, bevor die Sprint-Planung beginnt 📝

Vervollständige deine Verfeinerung des Backlogs vor Ihrem Sprint-Planungsmeeting. Andernfalls werden Sie viel zu viel Zeit damit verbringen, Details hinzuzufügen, abzuschätzen oder die Arbeit aufzuteilen.

Das Sprint-Planungstreffen sollte der Planung und Zielsetzung vorbehalten sein. Das Backlog sollte zwar nicht in Stein gemeißelt sein, aber es sollte den Teammitgliedern genügend Details liefern, um mit der Planung statt mit der Verfeinerung fortzufahren.

4. Integrieren Sie das Feedback der Stakeholder aus dem Sprint Review 😍

Welche Erkenntnisse haben die Stakeholder während des Sprints oder während des Sprint Reviews geteilt? Sie entwickeln dieses Produkt für sie, daher ist es entscheidend, ihr Feedback einzubeziehen, um das Endergebnis zu erzielen.

Stellen Sie sicher, dass jede Entscheidung auf den Kundenbedürfnissen basiert. Teilen Sie Ihren Stakeholdern nach jedem Sprint Ihre Produkt- und Sprintziele mit und passen Sie sie an deren Feedback an.

5. Integrieren Sie Erkenntnisse aus der Sprint-Retrospektive 💡

Sprint-Retrospektiven sind ein wichtiger Teil des agilen Prozesses und bieten dem Team Zeit, um zu besprechen, wie es sich verbessern kann. Jedes Mal, wenn Sie einen Sprint oder eine Iteration abschließen, gibt es Lektionen zu lernen. Agile nutzt kontinuierlich das, was ein Team lernt, und setzt diese Erfahrungen in umsetzbare Verbesserungen um. Diese Lektionen zu ignorieren, wäre also sehr unagil von Ihnen. 🤔

Wie lief der letzte Sprint? War jedes Teammitglied mit dem Prozess zufrieden und was wurde erreicht? Welche Änderungen hat Ihr Team beschlossen, um den nächsten Sprint effektiver zu machen? Nutze diese Erkenntnisse, um jeden Sprint besser zu machen als den letzten.

6. Definiere klar, wie Erfolg aussieht ✅

Legen Sie klar definierte Ziele, Vorgaben und Kennzahlen fest. Was ist die Definition von erledigt? Woher weiß das Team, ob es erfolgreich ist? Sie sollten das Sprint-Planungs-Meeting mit einer klaren Vorstellung davon verlassen, was erledigt werden muss und wie Erfolg aussieht.

7. Verwenden Sie Schätzungen, um Entscheidungen auf der Grundlage der Teamkapazität zu treffen 📈

Die Überlastung Ihres Teams oder einer Einzelperson über ihre Kapazitäten hinaus schadet weit mehr als es nützt. Es ist wahrscheinlicher, dass das Team Fehler macht, und die Moral wird sinken, da die Ziele ständig außer Reichweite bleiben.

Benutzen agile Schätztechniken und Storypoints um Arbeitslast und Kapazität besser zu verstehen. Wie viel Arbeit und Mühe sind erforderlich, um Ihre Ziele zu erreichen? Stellen Sie sicher, dass Sie sich realistische und vernünftige Ziele setzen, die auf Ihren besten Schätzungen basieren.

8. Richten Sie die Sprintziele an den allgemeinen Produktzielen aus 🎉

Stellen Sie sicher, dass Sie ein Ziel für den Sprint haben und dass sich alle Backlog-Elemente auf das Endziel beziehen. Ihre Sprintziele sollten mit Ihren allgemeinen Produktzielen übereinstimmen.

Wenn Sie Ihre Ziele nicht priorisieren, kann dies zu einer zufälligen Auswahl von Aufgaben führen. Durch das Erledigen unzusammenhängender Backlog-Elemente wird zwar immer noch Arbeit erledigt, aber das führt zu unerwarteten Ergebnissen und einem geringen Erfolgserlebnis für das Team. Jedes Backlog-Element sollte mit einem klaren Zweck ausgewählt werden, der sich auf Ihre Produkt- und Sprintziele bezieht.

9. Lass Raum für Flexibilität 💫

Jede agile Methode ist von Natur aus flexibel, und Scrum ist da keine Ausnahme. Wenn es keinen Raum für Flexibilität gibt, ist etwas ernsthaft schief gelaufen.

Es ist wichtig anzuerkennen, dass nicht immer alles nach Plan läuft. Sie werden ständig neue Informationen, Erkenntnisse über Interessengruppen und Abhängigkeiten finden, an die sich das Team im Laufe der Zeit anpassen muss. Stellen Sie sicher, dass das Team versteht, dass es flexibel sein muss und dass es bei jedem Sprint unterstützt wird.

Sprint-Planung leicht gemacht

Die Effektivität der Sprint-Planung kann für ein Scrum-Team über den Erfolg oder Misserfolg der kommenden Woche entscheiden. Es ist wichtig, dass sich das Entwicklungsteam die nötige Zeit nimmt, um sich auf jeden bevorstehenden Sprint vorzubereiten. Das bedeutet, dass Sie mit klaren Zielen, dem Feedback der Stakeholder und einem verfeinerten Backlog in das Meeting gehen müssen.

Machen Sie das Beste aus Ihrer Sprint-Planung und erledigen Sie sie mit Leichtigkeit Einfacher agiler Teamrhythmus. Transformiere dein flache Produktkarten in dynamische, flexible und visuelle Repräsentationen der Kundenreise. Story Points helfen Ihrem Team dabei, Entscheidungen zu treffen und Kapazitäten zu berücksichtigen, während der Kunde stets im Mittelpunkt steht.

Erfahre mehr über die Vorteile von User Story Mapping und lesen Sie unsere ultimativer Leitfaden für User Story Maps.

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.

„Tu es oder tu es nicht; es gibt keinen Versuch.“ Dies ist sicherlich das berühmteste Zitat von Jedi-Meister Yoda, aber es trifft nicht gerade auf die agile Entwicklung zu. Tatsächlich ist es quasi das Gegenteil von agil. Wenn Yoda ein Scrum Master wäre, würde das Zitat jedoch viel eher so aussehen: „Versuche es und versuche es noch einmal; so machst du es.“

Der Scrum Master unterstützt das Scrum-Team und führt es zu einem hoffnungsvollen Sieg. Es ist lohnend, aber die Rolle des Scrum Masters ist voller Druck. Der Erfolg des Scrum und das Wohlbefinden des Teams liegen auf den Schultern des Scrum Masters.

Wenn Sie ein Scrum Master sind oder einer werden möchten, sind Sie bei uns genau richtig. Meistern Sie die Scrum-Theorie und Ihre Führungsqualitäten mit unseren sechs Strategien für Scrum Master.

Scrum-Werte und die Rolle des Scrum Masters verstehen

Scrum ist eine agile Praxis, die häufig für die Produktentwicklung verwendet wird. Es basiert darauf, eine bestimmte Menge an Arbeit in kurzen Phasen — sogenannten Sprints — zu erledigen, sodass Teams kontinuierlich Iterationen erstellen können, während sie mehr über ein Produkt und seine Stakeholder erfahren.

Kenneth Schwaber hat in den frühen 1990er Jahren das Scrum-Framework mitentwickelt, um Teams bei der Verwaltung komplexer Entwicklungsprojekte zu unterstützen. Er gründete auch die Scrum Alliance und gründete Scrum.org, eine Online-Ressource für agile Teams.

Zu Beginn eines Scrums entscheidet der Product Owner, welche Product Backlog-Artikel in den Sprint-Backlog. Von dort aus übernimmt der Scrum Master und führt das Team durch Scrum-Events, darunter:

• Sprint-Planung
• Tägliches Scrum oder tägliche Standups
• Sprint-Bewertung
• Sprint-Retrospektiven

Die Rolle des Scrum Masters besteht darin, das Team durch den Scrum-Prozess zu führen. Sie erleichtern den Prozess und helfen dem Team, das Framework zu beherrschen und sich von einem Sprint zum nächsten zu verbessern.

Eigenschaften, die einen großartigen Scrum Master ausmachen

Ein effektiver Scrum Master zu sein, geht über das einfache Befolgen der Scrum-Regeln hinaus. Hier sind einige zusätzliche Merkmale, die Exzellenz in dieser Rolle wirklich definieren:

1. Emotionale Intelligenz

Ein guter Scrum Master besitzt eine hohe emotionale Intelligenz. Das bedeutet, dass sie:

• Verstehe und verwalte ihre eigenen Emotionen.
• Fühlen Sie sich in die Gefühle und Perspektiven der Teammitglieder ein.
• Ermöglichen Sie eine konstruktive Kommunikation und lösen Sie Konflikte elegant.

2. Starke Fähigkeiten zur Moderation

Es geht nicht nur darum, die täglichen Scrum-Meetings zu verwalten. Sie müssen:

• Ermutigen Sie zu einem offenen Dialog.
• Stellen Sie sicher, dass jede Stimme gehört wird.
• Führe das Team zum Konsens, ohne überheblich zu sein.

3. Anpassungsfähigkeit

Die Landschaft eines Projekts kann sich schnell ändern. Großartige Scrum Master:

• Passen Sie sich schnell an Veränderungen an, ohne den Fokus zu verlieren.
• Helfen Sie dem Team, Strategien schnell zu entwickeln und gleichzeitig die Moral aufrechtzuerhalten.

4. Lebenslanger Lerner

Die Welt von Agile entwickelt sich ständig weiter. Außergewöhnliche Scrum Master:

• Verpflichten Sie sich zu kontinuierlichem Lernen.
• Bleiben Sie mit den neuesten Praktiken, Tools und Methoden auf dem Laufenden.

5. Dienende Führung

Im Mittelpunkt der Rolle eines Scrum Masters steht die servative Führung. Das beinhaltet:

• Stellen Sie die Bedürfnisse des Teams über ihre eigenen.
• Beseitigung von Hindernissen, die den Fortschritt des Teams behindern.
• Befähigung der Teammitglieder, Verantwortung zu übernehmen und Entscheidungen zu treffen.

6. Analytisches Denken

Ein guter Scrum Master sollte in der Lage sein:

• Analysieren Sie die Prozesse des Teams und identifizieren Sie Engpässe.
• Nutzen Sie datengestützte Erkenntnisse, um kontinuierliche Verbesserungen zu fördern.

7. Motivierende Fähigkeiten

Die Motivation des Teams zu erhalten, ist entscheidend für eine nachhaltige Produktivität. Sie zeichnen sich aus durch:

• Kleine Erfolge anerkennen und feiern.
• Förderung einer positiven, kollaborativen Teamkultur.

8. Exzellente Kommunikation

Kommunikation ist der Schlüssel. Sie müssen:

• Vermitteln Sie Ideen klar und präzise.
• Stellen Sie sicher, dass alle Beteiligten auf derselben Wellenlänge sind.

Indem ein Scrum Master diese Eigenschaften verkörpert, ermöglicht er nicht nur ein effektives Projektmanagement, sondern fördert auch ein florierendes Teamumfeld, das Innovation und Erfolg fördert.

Sechs Strategien, um ein großartiger Scrum Master zu werden

Hier sind sechs Strategien für Scrum Master, um ihre Fähigkeiten zu verbessern oder sich auf ihre zukünftigen Rollen vorzubereiten.

1. Vergiss nicht, selbst agil zu sein

Lebst du selbst nach agilen Prinzipien? Wie agil sind Sie in Ihrem Führungsstil?

Effektive Scrum Master wissen, dass sie sich auch aufgrund neuer Erfahrungen, Erfolge und Misserfolge kontinuierlich verbessern müssen. Es ist wichtig, aus Ihren Fehlern zu lernen, damit Sie sie nicht noch einmal machen, aber es ist genauso wichtig, aus Ihren Erfolgen zu lernen. Nehmen Sie sich die Zeit, Ihren Prozess zu überprüfen, einschließlich dessen, was gut gelaufen ist und was nicht, damit Sie wissen, wie Sie sich als Führungskraft und Moderator verbessern können.

2. Lerne dein Team kennen

Ihre Fähigkeit, Ihr Team zu führen, hängt davon ab, wie gut Sie es kennen. Sie sollten kontinuierlich die Stärken und Schwächen Ihres Teams kennenlernen. Wie gut arbeiten sie zusammen? Wer bringt das Beste aus einander heraus und wer arbeitet nicht so gut zusammen? Gehen Sie tief in die Tiefe, um die grundlegende Dynamik des Teams wirklich zu verstehen.

Erfahre auch mehr über jeden Einzelnen im Team. Wobei benötigen sie Hilfe? Worin zeichnen sie sich aus? Welches Feedback können Sie ihnen geben, um ihnen zu helfen, in ihrer Rolle weiterzuentwickeln? Wie können Sie ihnen zum Erfolg verhelfen? Bauen Sie eine Beziehung zu Ihren Teammitgliedern auf, indem Sie sie fragen, wie es ihnen geht, Feedback geben und entgegennehmen und Gemeinsamkeiten finden.

3. Fördern Sie eine Kultur des kontinuierlichen Feedbacks

Die agile Methodik basiert auf kontinuierlicher Verbesserung. Wie werden sich die Personen in Ihrem Team verbessern, wenn Sie ihnen kein Feedback geben? Und wie wirst du dich verbessern, wenn du das Team nicht um Feedback bittest und es nicht akzeptierst?

Feedback ist eine Einbahnstraße, und es funktioniert nur, wenn es konstruktiv und kontinuierlich ist. Warten Sie nicht, bis Sie etwas Negatives zu beheben haben — Sie müssen regelmäßig sowohl positives als auch negatives Feedback geben. Wenn Sie dies regelmäßig tun, können Sie und Ihr Team sich daran gewöhnen, Feedback zu hören, sodass es nicht erschütternd oder abschreckend wirkt, wenn Sie dies tun.

Als Scrum Master sollten Sie ein Umfeld fördern, in dem alle Mitglieder geben und empfangen konstruktives Feedback.

4. Verbessern Sie Ihre Kommunikationsfähigkeiten

Das Sagen zu haben bedeutet nicht, dass du ständig redest. Das Gegenteil ist der Fall: Gute Führungskräfte sind großartige Kommunikatoren. Als Führungskraft müssen Sie Ihrem Team ständig zuhören und beide Ohren offen halten für alle Probleme, mit denen sich Ihr Team oder die Mitglieder des Teams möglicherweise befassen.

Hören Sie sich aktiv die Anliegen des Entwicklungsteams an und überlegen Sie, wie jeder Einzelne in Ihrem Team am liebsten kommuniziert. Bevorzugen sie mutige und auf den Punkt gebrachte Interaktionen? Oder brauchen sie Zeit, um ein Gespräch zu beginnen? Jeder kommuniziert ein bisschen anders, und wenn Sie die Präferenzen Ihres Teams verstehen, können Sie das Beste aus jeder Interaktion herausholen.

Scrum Master müssen ihre Kommunikationsfähigkeiten verbessern, um effektive Führungskräfte für ihre Teams zu sein. Beurteilen Sie regelmäßig Ihren Kommunikationsstil und dessen Effektivität und bitten Sie Ihr Team um Feedback dazu, wie es Ihnen geht.

5. Machen Sie das Beste aus jeder Retrospektive

Die Retrospektive ist die letzte Veranstaltung eines Scrums. Sie sind ein unglaublich wichtiger Teil des Scrum-Prozesses und sollten nicht übersehen, überstürzt oder zu wenig genutzt werden. Als Scrum Master müssen Sie die Verantwortung dafür übernehmen, dass Retrospektiven wirksam sind und nach jedem Scrum stattfinden. Gehen Sie mit einem Plan los, um das Beste aus jedem Retro-Meeting herauszuholen.

Das bedeutet nicht, dass Sie sich um alles kümmern müssen. Es ist hilfreich, Ihr Team gelegentlich eine Retrospektive durchführen zu lassen. Alle Beteiligten sollten kontinuierlich ihre eigenen Ideen einbringen, um das Meeting zu verbessern.

Sammeln Sie regelmäßig Feedback von Ihrem Team darüber, wie Ihre Retrospektiven ihrer Meinung nach verlaufen. Fragen Sie nach Ideen, wie sie sich verbessern und die Dinge ändern könnten. Die Wiederholung exakt derselben Fragen und rückblickende Aktivitäten langweilen Ihr Team und führen zu geringerem Engagement.

Einen tieferen Rückblick finden Sie in unseren fünf Schritten zu Durchführung effektiver Sprint-Retrospektiven.

6. Werden Sie zertifizierter Scrum Master

Eine Scrum Master-Zertifizierung kann Sie vom einfachen Scrum Master zum meisterhaften Scrum Master machen. Eine Zertifizierung ist zwar nicht erforderlich, um ein professioneller Scrum Master zu werden, aber sie hilft auf jeden Fall.

Scrum.org, die vom Mitbegründer von Scrum gegründete Website, bietet ein dreiteiliges Zertifizierungsprogramm namens The Professional Scrum MasterTM an. Das Programm besteht aus drei Bewertungsstufen, die Ihr Wissen über das Scrum-Framework und die praktische Anwendung der Scrum-Theorie bestätigen.

• Der professionelle Scrum MasterTM I (PSM I)
• Der professionelle Scrum MasterTM II (PSM II)
• Der professionelle Scrum MasterTM III (PSM III)

Wir sind auch große Fans der SAFe-Trainingsprogramme von Pretty Agile:

• SAFe Scrum Master SSM Zertifizierung
• SAFe Advanced Scrum Master

Eine Zertifizierung ist eine großartige Ergänzung zu Ihrem Lebenslauf und hilft Ihnen dabei, Ihre Moderationsfähigkeiten und Ihr Scrum-Wissen zu verfeinern.

Easy Agile für Scrum Master

„Versuche es und versuche es noch einmal; so machst du es.“

Das Schöne an Agilität ist, dass unabhängig davon, wie viele Zertifizierungen oder Jahre Erfahrung Sie haben, es immer mehr zu verbessern gibt. Agile ist ein iterativer Prozess, bei dem das Lernen von Sprint zu Sprint und von Projekt zu Projekt fortgesetzt wird. Als Scrum Master liegt es an Ihnen, das Handwerk weiter zu erlernen und Ihre Moderationsfähigkeiten zu perfektionieren. Die Rolle des Scrum Masters beinhaltet lebenslanges Lernen.

Easy Agile entwickelt Produkte, die Scrum Mastern und agilen Entwicklern helfen, effizienter und effektiver zu arbeiten. Unsere Tools wurden speziell für Teams entwickelt, die Jira verwenden und lieben, aber mehr Funktionen benötigen, um die Kundenbedürfnisse zu priorisieren.

Versuche Einfacher agiler Teamrhythmus um die Agilität Ihres Teams von der Planung bis zur Überprüfung zu unterstützen. TeamRhythm unterstützt das Mapping von User-Storys, die Verfeinerung des Backlogs, die Sprint- und Versionsplanung sowie Team-Retrospektiven und baut so einen kontinuierlichen Verbesserungszyklus direkt in Jira auf. Es ist eine Win-Win-Situation für Scrum Master, Entwicklungsteams und Kunden. Testen Sie unsere Produkte 30 Tage lang absolut kostenlos.