DEEP: Die 4 Merkmale eines guten Produkt-Backlogs

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.

So wie Sie sich vor einem Roadtrip eine physische Landkarte ansehen, um die Etappen jeder Reise zu verstehen, helfen Roadmaps agilen Teams dabei, ihre Arbeitsbelastung für die kommenden Monate zu verstehen. Jira-Roadmaps bieten weitere Vorteile, wie z. B. die Visualisierung des Zeitplans und die Möglichkeit, relevante Informationen mit externen Stakeholdern zu teilen.

In diesem Artikel werden wir den Zweck von entpacken Produkt-Roadmaps und ob sie alle gleich sind und warum Einfache Agile Roadmaps für Jira ist das einfachste Roadmapping-Tool für Jira. Du wirst entdecken, wie Roadmaps helfen Produkteigentümer, agile Teammitglieder, Kunden und Stakeholder. Sie werden auch den Unterschied zwischen Roadmaps und Gantt-Diagrammen verstehen.

Lassen Sie uns damit beginnen, den Zweck von Roadmaps für agile Teams zu erörtern.

Warum braucht ein agiles Team eine Roadmap?

Roadmaps helfen agilen Teams dabei, ihre großen Arbeitsbereiche zu definieren und zu definieren, bis wann sie abgeschlossen werden müssen. Es ist ein Artefakt, mit dem Team, Kunden und anderen Projektbeteiligten zu kommunizieren.

Mithilfe von Roadmaps haben agile Teammitglieder einen Überblick über ihre Reise für die nächsten 3-6 oder sogar 12 Monate. Wenn Teams diese Reise verstehen, können sie die Entwicklung ihres Produkts besser verstehen.

Wenn Sie ein Product Owner sind, sind Roadmaps eine großartige Möglichkeit für Sie:

• Zeigen Sie, dass Sie die Unternehmensziele verstehen
• Zeigen Sie der C-Suite und dem agilen Team, dass Sie sich dessen bewusst sind Bedürfnisse des Kunden
• Zeigen Sie, dass Sie wissen, wie Sie Ihren Kunden ein wertvolles Produkt liefern und gleichzeitig die Ziele Ihres Unternehmens erreichen

Roadmaps sind auch eine großartige Möglichkeit, Sie und Ihr Team daran zu erinnern, wie ihre Arbeit in das Gesamtbild passt. Sie geben dir die Möglichkeit, Teammitglieder zu motivieren und ihnen zu helfen.

Außerdem, indem Sie Epen in Benutzergeschichten aufteilen in der Produkt-Backlog, Product Owner und das Entwicklungsteam können diese Arbeitselemente besser priorisieren, planen und Ressourcen zuweisen.

Nachdem wir die Grundlagen der Jira-Roadmaps behandelt haben, schauen wir uns an, wie wir sie für verschiedene Rollen anpassen können.

Maßgeschneiderte Roadmaps auf spezifische Bedürfnisse

Verschiedene Teammitglieder benötigen unterschiedliche Ansichten der Roadmaps. Einige Rollen konzentrieren sich auf die Analyse bestimmter Roadmap-Elemente, während andere Rollen sich auf andere Teile konzentrieren.

Das Entwicklungsteam benötigt Roadmaps mit voraussichtlichen Veröffentlichungsdaten, Meilensteinen und einer detaillierten Erläuterung des Kundennutzens.

Sie können Roadmap-Elemente nach dem Kundennutzen priorisieren, was sinnvoll ist, wenn Sie die agile Methode des Kunden in Betracht ziehen.

Oft haben Entwicklungsteams Roadmaps, die nach Sprints organisiert sind, und Arbeitsaufgaben, die auf einem Zeitplan angeordnet sind. Ein Arbeitselement kann eine Benutzergeschichte, eine Aufgabe oder ein Bug.

Die C-Suite verwendet Roadmaps, um die Arbeit der Entwicklungsteams den Unternehmenszielen und -kennzahlen zuzuordnen.

Diese Roadmaps zeigen Arbeitselemente an, die nach Monaten oder Quartalen geordnet sind. Diese Organisation hilft dabei, Fortschritte im Laufe der Zeit zu verfolgen und Schlussfolgerungen zur Zielerreichung zu ziehen.

Beim Roadmapping für die C-Suite müssen Sie sich keine Gedanken darüber machen, ihnen detaillierte Arbeitsaufgabenbeschreibungen zur Verfügung zu stellen.

Das Verkaufspersonal stützt sich auf Roadmaps, um mehr über neue Funktionen und den Kundennutzen zu erfahren. Diese Art von Informationen kann dazu beitragen, die Umsatzerlöse zu verbessern. Roadmaps sind eine großartige Möglichkeit für die Vertriebsmitarbeiter, bevorstehende Entwicklungen zu verstehen, für die sie die Kunden begeistern können.

Sie sollten auch Ihr Bestes tun, um Ihren Kunden visuell ansprechende und gut lesbare Roadmaps anzubieten. Sie werden nach einer priorisierten Übersicht über neue Funktionen suchen.

Jira-Roadmaps können dir bei der Bereitstellung dieser verschiedenen Arten von Roadmaps helfen.

Jira-Roadmaps

Atlassian hat Roadmaps in die Jira-Software der nächsten Generation aufgenommen. Mit Jira-Roadmaps kannst du Elemente in einer Zeitleiste definieren und organisieren und sie auf dem neuesten Stand halten. Du kannst den Arbeitsstatus sogar mit Stakeholdern teilen.

Aber das Coolste an Roadmaps in Jira ist, dass sie mit der Arbeit der Entwickler synchronisiert werden.

Da sich der Umfang eines Projekts ändern kann, während agile Teams arbeiten, kann es schwierig werden, eine aktuelle Roadmap aufrechtzuerhalten, insbesondere wenn Sie ein statisches Tool wie Excel oder Confluence verwendet haben. Zum Glück können Sie mit Jira-Roadmaps den Arbeitsstatus und die Prioritäten der Elemente schnell und einfach aktualisieren.

Agile Teams können User Stories an das Jira-Projekt anhängen, an dem sie gerade arbeiten. Infolgedessen aktualisiert Jira Software die eigentliche Arbeit in ihrer Roadmap.

Du kannst auch die Jira-Software verwenden, um das Problem zu lösen Roadmap-Elemente oder Epen, was bedeutet, die Arbeit in kleine Teile aufzuteilen. Und als ob das nicht schon genug Spaß gemacht hätte, kannst du die Drag-and-Drop-Funktionalität von Jira Software verwenden, um die Prioritäten von Elementen in der Timeline anzupassen. Folglich passt Jira Software die Daten in den Epen automatisch an.

Dies sind einige weitere Gründe, warum es sich lohnt, sich die Roadmaps von Jira anzusehen. Sie bieten:

• Zusammenarbeit der Interessengruppen bei der Erstellung und Pflege der Roadmap
• Die Fähigkeit, Informationen mit externen Stakeholdern zu teilen
• Höhere Verfügbarkeit und Sichtbarkeit für Teammitglieder
• Enge Verbindungen zwischen der Arbeit eines Teams und der Roadmap
• Nahtlose Aktualisierbarkeit von Gegenständen
• Visualisierung des Projektstatus
• Sowohl allgemeine als auch detaillierte Artikelbeschreibungen
• Verbindungen zwischen Jira-Ausgabedaten und Daten auf der Roadmap

Einfache Agile Roadmaps für Jira kann dir dabei helfen, deine Roadmap als Zeitleiste mit Swimlanes zu gestalten, die auf Arbeitsthemen oder Teams basieren. Ziehen Sie Elemente per Drag & Drop auf die Zeitleiste, um festzulegen, wann das Team mit der Bearbeitung beginnen und enden soll. Sie können auch:

• Meilensteine definieren
• Die Ansicht der Roadmap filtern
• Verfolge den Fortschritt der epischen Fertigstellung
• Teilen Sie eine PDF-Version der Roadmap mit Stakeholdern

Bevor Sie loslegen, sollten wir uns mit Gantt-Diagrammen und Roadmaps befassen.

Was sind Gantt-Diagramme?

Wenn wir sagen: „Gantt-Diagramme sind nützlich für agile Teams„, denkst du vielleicht sofort, „Das kann nicht stimmen!“ 😮 Gantt-Diagramme können jedoch im richtigen Kontext nützlich sein. Sie sind einfach nicht sehr agil.

Das Gantt-Diagramm, benannt nach dem Schöpfer des Diagramms, Henry Lawrence Gantt, bietet einen grafischen Zeitplan für die Planung und Visualisierung von Aufgaben, die nach Projektphasen organisiert sind.

Projektmanager verwenden Gantt-Diagramme, um Aufgabenabhängigkeiten und den kritischen Pfad zu verwalten. Dieser Pfad ist die Abfolge von Aufgaben, die die Teammitglieder pünktlich ausführen müssen, um das Enddatum des Projekts nicht zu gefährden.

Einfach ausgedrückt, wenn Sie ein Rechenzentrum bauen, müssen Sie die Reihenfolge definieren, in der das Team Aufgaben ausführen muss. Im Grunde kann das Team einige Aufgaben nicht beginnen, bevor es andere erledigt hat.

Lassen Sie uns nun klären, warum Roadmaps agil sind, Gantt-Diagramme jedoch nicht.

Warum Gantt-Diagramme und Roadmaps nicht austauschbar sind

Auf den ersten Blick scheinen Gantt-Diagramme Roadmaps zu ähneln. Im Kern dienen sie jedoch unterschiedlichen Zwecken und Zielgruppen.

Gantt-Diagramme gehen davon aus, dass die Teammitglieder ihre Arbeit linear erledigen. Das bedeutet, dass die Ausführung einiger Aufgaben von der Ausführung anderer Aufgaben abhängt. Und jede Änderung des Zeitplans kann das Enddatum des Projekts gefährden. Daher sollten Sie eine Neuplanung von Aufgaben vermeiden und die Ausführung der Aufgaben regelmäßig überwachen.

Aus diesem Grund widerspricht die Linearität von Gantt-Diagrammen den Prinzipien der Agilität. 🛑

Die agile Methodik entstand aus der Notwendigkeit, die Ineffizienzen traditioneller Projektmanagementpraktiken in der Softwareentwicklung zu beheben. Eine dieser Methoden ist die Wasserfallmethode.

Agile Teams planen adaptiv und liefern kontinuierlich Ergebnisse. Sie konzentrieren sich auch auf kontinuierliche Verbesserung. Deshalb würde kein Gantt-Diagramm in ein agiler Arbeitsablauf.

Gantt-Diagramme folgen einem linearen Bereitstellungsmodell mit vielen Aufgabenabhängigkeiten, das in der Regel langsam ist. 🐌

Auf der anderen Seite hat der agile Workflow kürzere Entwicklungszyklen — Iterationen — mit häufigen Lieferungen und den geringsten Aufgabenabhängigkeiten. Das beschleunigt die kontinuierliche Verbesserung. Darüber hinaus passen agile Teams ihre Roadmaps sehr gut an sich ständig ändernde Prioritäten und Anforderungen an.

Roadmaps sind gut, aber Jira-Roadmaps sind fantastisch

Jira-Roadmaps wie Einfache agile Roadmaps hilft dabei, Arbeitselemente nach Priorität zu ordnen und ihren Status zu aktualisieren. Projektbeteiligte können in Jira gemeinsam Änderungen an Roadmaps vornehmen, was sehr praktisch ist.

Das vielleicht beste Feature von Jira-Roadmaps ist, dass Entwickler sowohl die Arbeit in den Jira Software-User Stories als auch die Aufgaben auf diesen Roadmaps verfolgen können. Aus Sicht des Product Owners besteht der Vorteil darin, wie er die Arbeit der Entwickler visualisiert und mit den Stakeholdern kommuniziert.

Es ist wirklich wichtig sicherzustellen, dass sowohl die C-Suite als auch das agile Team sich an die Roadmap halten. Wenn sie das nicht tun, stimmen Sie die Arbeit Ihres Teams möglicherweise nicht auf die Unternehmensziele und Kundenbedürfnisse ab.

Denken Sie daran, dass die Vorteile von Roadmaps auf zwei Arten wirken: Die Teammitglieder erkennen besser, wie sie zur Erreichung der Unternehmensziele beitragen, und Sie können diesen Prozess überwachen.

Testen Sie unsere Einfache Agile Roadmaps für Jira. Ob du dem folgst Scrum-Rahmenwerk oder die Kanban-Framework, es hilft Ihnen dabei, die Arbeitsaufgaben Ihres Teams in einer Zeitleiste zu organisieren, Meilensteine zu definieren und den Fortschritt zu verfolgen.

Wie fühlst du dich, wenn jemand „Planung“ erwähnt? Freust du dich auf die Gelegenheit oder rennst du bei dem Gedanken, einen Plan zu schmieden, in die Berge?

Die Sprint-Planung ist ein entscheidender Teil des agilen Sprintzyklus. Sie hilft Ihnen und Ihrem Team dabei, gemeinsame Ziele zu erreichen, und bereitet Sie auf einen erfolgreichen Sprint vor. Auch wenn Planung nicht zu Ihren Stärken gehört, ist die gute Nachricht, dass Sie mit Hilfe einiger guter Ratschläge üben und im Laufe der Zeit besser werden können.

Wir haben unsere besten Tipps zur Sprint-Planung in einem ultimativen Leitfaden für agile Sprint-Planung zusammengefasst, der alles enthält, was Sie für effiziente und effektive Planungsbesprechungen benötigen.

Was ist agile Sprint-Planung?

Agile Sprintplanung ist eine wichtige Zeremonie im agilen Sprintzyklus. Sie bedeutet und bereitet das Team auf den Start des Sprints vor. Ohne diese Planung besteht das sehr reale Risiko, dass es dem Team an Fokus mangelt und es ihm nicht gelingt, sich auf das Wesentliche zu konzentrieren.

Eine effektive agile Sprint-Planung besteht aus drei Hauptteilen: einem Sprintziel, einem Verständnis der Teamkapazität und einer Reihe von priorisierten Backlog-Elementen. Jedes Element hängt vom anderen ab, um erfolgreich zu sein.

Die Idee ist, Ihr Team auf ein Ziel für den nächsten Sprint auszurichten, indem Sie sich auf eine Reihe von Backlog-Elementen einigen, die innerhalb des Sprints erreichbar sind und zum Erreichen des Sprintziels beitragen. Wenn Sie sich darauf konzentrieren und Klarheit darüber gewinnen, was Sie erreichen möchten, kann Ihr Team besser zusammenarbeiten und die Ziele erreichen.

Es ist am besten, mit einem vereinbarten Sprintziel zu beginnen. Anschließend können Sie die Arbeit an den spezifischen Backlog-Elementen priorisieren, für deren Erledigung Ihr Team in der Lage ist. Dies wird dazu beitragen, dass Ihr Sprintziel Wirklichkeit wird.

Wie die Sprint-Planung in den Scrum-Prozess passt

Wir sind große Fans des Scrum-Prozesses und er ist bei vielen Softwareentwicklungsteams sehr beliebt. Agile Sprintplanung kann zwar viele Formen annehmen innerhalb der anders agil Methodologien, für die Zwecke dieses Leitfadens konzentrieren wir uns auf die agile Sprint-Planung innerhalb des Scrum-Frameworks.

Wenn Ihr Team Scrum nicht befolgt, machen Sie sich keine Sorgen — unsere Tipps zur Vorbereitung, unser Meeting-Leitfaden, die zu vermeidenden Fehler und die Ressourcen zur Sprint-Planung sind für Sie von Nutzen.

💡 Erfahre mehr: Was ist der Unterschied zwischen Kanban und Scrum?

Scrum-Rollen: Die Menschen

In einem Scrum-Team gibt es drei Hauptrollen.

1. Inhaber des Produkts
2. Scrum Master
3. Entwicklungsteam

Der Product Owner legt die Arbeit im Voraus an. Sie helfen bei der Priorisierung der Artikel aus dem Produkt-Backlog und entscheiden, welche Elemente in den Sprint-Backlog. Diese wichtigen Entscheidungen leiten die Ziele des Sprints und bestimmen die Aufgaben, die das Team im nächsten Sprint bewältigen wird.

Das Scrum Master fungiert als Leitfaden und leitet Besprechungen, die sicherstellen, dass das Scrum-Framework während des gesamten Sprints eingehalten wird, um das Team auf Kurs zu halten. Der Scrum Master hilft dem Team, das Beste aus dem gesamten Scrum-Prozess und jeder einzelnen Scrum-Zeremonie herauszuholen.

Das Entwicklungsteam besteht aus den verschiedenen Personen, die die bei der Sprintplanung vereinbarten Arbeiten erledigen werden.

Es gibt noch andere, auf die Sie sich bei der Sprint-Planung beziehen könnten, z. B. Stakeholder, Benutzer und Kunden. Dies sind zwar technisch gesehen keine Scrum-Rollen, aber sie spielen eine entscheidende Rolle bei der Produktentwicklung. Stakeholder sollten früh und häufig in den Prozess einbezogen werden, und Kunden sollten bei Entwicklungsentscheidungen immer im Vordergrund stehen. Einige Teams halten User Personas für eine wertvolle Methode, um den Nutzerwert im Mittelpunkt zu behalten.

Artefakte: Was wird gemacht

Artefakte sind die Dinge, die erledigt werden müssen — verschiedene Aufschlüsselungen dessen, was das Team zu erreichen hofft:

1. Produktrückstand
2. Sprint-Backlog
3. Zuwächse

Artikel im Produktbacklog sind die Aufgaben, von denen das Team glaubt, dass sie sie erledigen müssen, um ein Produkt oder eine spezifische Verbesserung eines Produkts fertigzustellen. Es ist die große Masterliste mit allem, was das Team glaubt, erledigen zu müssen. Das Produkt-Backlog ist flexibel und iterativ und wird sich weiterentwickeln, wenn das Team mehr über das Produkt, das Feedback der Interessengruppen und die Kundenbedürfnisse erfährt.

Der Sprint-Backlog ist fokussierter als der Produkt-Backlog. Der Product Owner verschiebt zu Beginn jedes Sprints die wichtigsten Backlog-Elemente aus dem Produkt-Backlog in das Sprint-Backlog, basierend auf aktuellen Problemen, Prioritäten und Kundenbedürfnissen. Das Team ist bestrebt, im Laufe des Sprints alle Elemente des Sprint-Backlogs abzuschließen.

Ein Zuwachs ist ein Trittbrett aus Beton zur Erreichung des Produktziels. Eine Erhöhung muss als brauchbar verifiziert werden, um einen Mehrwert zu bieten. Das bedeutet, dass jede abgeschlossene Arbeit nicht als Teil einer Erhöhung betrachtet werden kann, es sei denn, sie entspricht der Definition von Erledigt (eine Vereinbarung zwischen dem Team darüber, was „erledigt“ bedeutet). Dabei handelt es sich um eine formale Beschreibung des Zuwachses, wenn es die für ein Produkt geltenden Qualitätsstandards erfüllt. Sobald die abgeschlossene Arbeit der vereinbarten Definition von Erledigt entspricht, erhalten Sie einen Zuschlag.

Scrum-Zeremonien: Wo Sprint Planning passt

In Scrum gibt es eine Reihe von Zeremonien, die in jedem Sprint stattfinden. Hier passt die Sprint-Planung in den Scrum-Prozess.

1. Sprint-Planung
2. Tägliches Scrum (oder Standup)
3. Sprint-Bewertung
4. Sprint-Rückblick

💡 Erfahre mehr: Agile Ceremonies: Ihr Leitfaden für die vier Stufen

Sprint-Planung ist die erste Scrum-Zeremonie — sie bereitet das Team auf den Sprint vor. In der Planungssitzung wird alles in Bewegung gesetzt und das Team darauf ausgerichtet, was für diesen Sprint am wichtigsten ist. In diesem Moment werden Entscheidungen getroffen und wichtige Backlog-Elemente aus dem Produkt-Backlog in das Sprint-Backlog verschoben.

Die zweite Zeremonie wiederholt sich an jedem Tag des Sprints. Tägliche Standups Bringen Sie das Team zusammen, um Fortschritte und Hindernisse zu besprechen, die möglicherweise im Weg stehen. Indem die Bedenken frühzeitig an die Öffentlichkeit gebracht werden, kann das Team die Frustration aufgrund von Verzögerungen vermeiden und sicherstellen, dass die Arbeit reibungslos abläuft.

Die letzten beiden Zeremonien finden am Ende des Sprints statt. Für der Sprint Review, kommt das Team zusammen, um anhand der abgeschlossenen Arbeit den Erfolg des Sprints zu ermitteln. Es ist auch eine Gelegenheit, Stakeholder einzubeziehen, um Feedback zu dem einzuholen, was bisher erreicht wurde. Das Sprint-Review stellt sicher, dass Kundeninformationen immer im Mittelpunkt stehen, die Stakeholder kontinuierlich Fortschritte verfolgen und garantiert, dass das Produkt nie zu weit von dem abweicht, wonach die Stakeholder suchen.

Das Sprint-Rückblick sammelt wichtige Einblicke von Teammitgliedern darüber, wie der Sprint verlaufen ist. Was lief gut, was lief nicht so gut und was könnte beim nächsten Mal verbessert werden? Diese wertvollen Erkenntnisse machen Scrum agil — das Team denkt immer kritisch über den Prozess nach und sucht nach Möglichkeiten, die Arbeit und die Art und Weise, wie sie zusammenarbeiten, zu verbessern.

Wir werden im Folgenden ausführlicher auf diese Zeremonien eingehen, wenn wir besprechen, was nach dem Sprint-Planungsmeeting passiert.

Die Vorteile der agilen Sprint-Planung

Agile Sprintplanung ist ein leistungsstarkes Meeting, das nicht übersehen oder unterschätzt werden sollte. Es ist eine Gelegenheit für:

• Bringen Sie das gesamte Team zusammen und orientieren Sie sich an gemeinsamen Zielen
• Stellen Sie den Kontext ein, indem Sie den Sprint mit klaren Prioritäten beginnen
• Identifizieren Sie potenzielle Hindernisse, bevor sie auftreten
• Bringen Sie das Feedback der Stakeholder in den Planungsprozess ein
• Lernen Sie aus früheren Sprints, indem Sie Sprint Review und retrospektive Einblicke in Betracht ziehen
• Berücksichtigen Sie die Teamkapazität und passen Sie sie entsprechend an, um sicherzustellen, dass die Ziele erreichbar sind und das Team im bevorstehenden Sprint nicht überfordert ist.
• Berücksichtigen und planen Sie Abhängigkeiten, die sich auf den Arbeitsablauf auswirken können.

So bereiten Sie sich auf ein Sprint-Planungstreffen vor

Wir wissen, dass wir gesagt haben, dass ein Sprint mit der Sprint-Planung beginnt, aber es gibt tatsächlich ein paar wichtige Schritte, die Sie ergreifen müssen, um sich auf die Planungssitzung vorzubereiten. Leider müssen Sie für das Planungstreffen ein wenig planen.

Verfeinerung des Backlogs

Durch die Pflege oder Verfeinerung Ihres Backlogs bleibt Ihr Backlog gesund, aktuell und bereit für die Sprint-Planung. Ein verfeinertes Backlog trägt dazu bei, dass die Planungszeit Ihres Teams effizient und effektiv genutzt wird, da Sie keine Zeit damit verschwenden müssen, dem Backlog Details hinzuzufügen, die im Voraus hätten abgeschlossen werden können, bevor alle zusammengekommen sind.

Der Produktmanager sollte das Backlog einige Tage vor dem Sprint-Planungsmeeting bereinigen, um sicherzustellen, dass es fertig ist.

Tipps zur Aufrechterhaltung eines gesunden Backlogs:

• Stellen Sie sicher, dass die Geschichten in der Reihenfolge ihrer Priorität angeordnet sind
• Priorisieren Sie Artikel, die dem Kunden den größten Mehrwert bieten
• Details zu den Backlog-Elementen mit der höchsten Priorität hinzufügen
• Teilen Sie alle User Stories auf, die zu groß sind
• Löschen Sie alle User Stories, die nicht mehr relevant sind
• Erstellen Sie neue User Stories auf der Grundlage neuer oder klarerer Bedürfnisse
• Fügen Sie Artikel hinzu, die auf dem Feedback neuer Interessengruppen basieren
• Nehmen Sie Anpassungen auf der Grundlage von Fehlerkorrekturen vor
• Weisen Sie genauere Schätzungen zu

💡 Erfahre mehr: Unverzichtbare Checkliste für eine effektive Backlog-Verfeinerung (und was zu vermeiden ist)

Sei konsistent

Eine einheitliche Besprechungszeit, die weit im Voraus geplant wird, stellt sicher, dass das gesamte Scrum-Team das Zeitfenster offen hält. Buchen Sie Ihr Sprint-Planungsmeeting bei jedem Sprint am selben Tag und zur gleichen Zeit, damit niemand es vergisst oder doppelt bucht.

Bei der Sprint-Planung handelt es sich nicht um ein Meeting, das hin- und hergeschoben, verzögert oder ignoriert werden kann — Besprechungen zur Sprint-Planung sind für den Erfolg eines jeden Sprints unerlässlich. Fragen Sie Ihr Team nach einer bestimmten, wiederkehrenden Zeit für ein Meeting und stellen Sie sicher, dass es für alle funktioniert.

So führen Sie ein Sprint-Planungsmeeting durch

Die agile Methode ist zwar flexibel und kollaborativ, aber nicht chaotisch; alles muss mit einem Plan beginnen.

1. Halten Sie sich an eine festgelegte Sitzungsdauer zur Sprint-Planung

Wie bei jeder Art von Besprechung kann das Team ohne Timebox leicht abgelenkt werden. Schließlich ist es oft einfacher, über die Arbeit zu sprechen, die erledigt werden muss, als sie tatsächlich abzuschließen. Es ist die Aufgabe des Scrum Masters, das Team auf Kurs zu halten und sicherzustellen, dass das Zeitlimit nicht überschritten wird.

Gehen Sie gut vorbereitet in das Sprint-Planungsmeeting. Eine klare Agenda und ein gut ausgearbeitetes Backlog sorgen dafür, dass Ihr Team direkt mit der Planung beginnen kann.

Legen Sie eine realistische Zeitbox für das Meeting fest und halten Sie sich daran. Wir empfehlen Ihnen, nicht mehr als 2-3 Stunden für ein Sprint-Planungs-Meeting einzuplanen, aber je besser Sie sich mit der Sprint-Planung auskennen, desto besser verstehen Sie, wie viel Zeit für Sie und Ihr Team in Frage kommt.

2. Verwenden Sie Schätzungen, um realistische Entscheidungen zu treffen

Sie möchten, dass Ihr Team so produktiv wie möglich ist, aber eine Überlastung kann die Produktivität und Konzentration tatsächlich beeinträchtigen. Unangemessene Erwartungen sind demotivierend und übermäßig engagierte Teammitglieder machen mit größerer Wahrscheinlichkeit Fehler.

Sie müssen wissen, wie viel Aufwand und Zeit erforderlich sind, um die Ziele zu erreichen, die Sie sich für jeden Sprint gesetzt haben. Agile Schätzungstechniken und Storypoints ermöglichen ein besseres Verständnis der Teamkapazität, der individuellen Kapazität und der Frage, wie eine angemessene Arbeitsbelastung aussieht. Angemessene und realistische Ziele helfen Ihrem Team, motiviert zu bleiben und einen konsistenten Arbeitsablauf zu unterstützen.

3. Definieren Sie klare Ziele und Ergebnisse

Was will das Team bis zum Ende des Sprints erreichen? Setze klar definierte Ziele und Ergebnisse, die jeder versteht. Stimmen deine Ziele mit dem überein, was du aus vergangenen Sprints gelernt hast? Stimmen sie mit den Kundenbedürfnissen überein? Sind sich alle einig, wie der nächste Sprint (ungefähr) aussehen wird?

Gehen Sie nicht davon aus, dass alle auf derselben Seite sind. Stellen Sie Fragen und ermutigen Sie Ihr Team, sich zu äußern, wenn etwas unklar ist. Es ist besser, Unstimmigkeiten oder Missverständnisse jetzt auszuräumen, als zu Beginn der Arbeit.

Um Sprintziele effektiv zu setzen, muss das SMART-Framework befolgt werden, eine anerkannte Strategie im Projektmanagement und bei der Zielsetzung in verschiedenen Branchen. Das Akronym SMART steht für:

• Spezifisch: Definieren Sie klar, was Sie erreichen möchten. Vermeiden Sie vage Ziele, indem Sie präzise Ergebnisse festlegen.
• Messbar: Legen Sie Kriterien für die Messung des Fortschritts fest. Dies hilft bei der Nachverfolgung von Erfolgen und der Identifizierung von Bereichen, in denen Anpassungen erforderlich sind.
• Erreichbar: Streben Sie Ziele an, die herausfordernd sind, aber mit den vorhandenen Ressourcen erreichbar sind. Überehrgeizige Ziele können ein Team demoralisieren, wenn sie nicht realistisch sind.
• Relevant: Stellen Sie sicher, dass jedes Ziel mit den übergeordneten Zielen des Projekts übereinstimmt. Irrelevante Aufgaben können die Energie von dem ablenken, was wirklich wichtig ist.
• Zeitgebunden: Legen Sie eine klare Frist fest, um die Dringlichkeit und den Fokus aufrechtzuerhalten. Die Sprintziele müssen mit dem begrenzten Zeitplan des Sprints übereinstimmen, um einen fristgerechten Abschluss zu gewährleisten.

In der Praxis bedeutet die Anwendung des SMART-Frameworks auf Sprintziele, dass Ihr Team synchronisiert ist und sich auf Prioritäten konzentriert, die das Projekt effizient vorantreiben. Indem Sie dafür sorgen, dass die Ziele innerhalb des Zeitrahmens des Sprints relevant und erreichbar sind, vermeiden Sie eine Fehlverteilung der Anstrengungen und stellen sicher, dass der Fortschritt den allgemeinen Projektzielen entspricht.

Veröffentlichen Sie Ihr Sprintziel an einem leicht zugänglichen Ort, damit das Team während des gesamten Sprints darauf zurückgreifen kann.

💡 Erfahre mehr: So holen Sie das Beste aus Ihren Sprintzielen heraus

4. Entscheide, was es heißt, „fertig“ zu sein

Was bedeutet „erledigt“ für ein bestimmtes Backlog-Element, eine Erhöhung, ein Produktproblem oder ein Produkt als Ganzes? Das Team und Ihre Stakeholder müssen sich darauf einigen, wie „Erledigt“ aussieht, um realistische Ziele zu setzen, die den Erwartungen aller Beteiligten entsprechen.

Wenn du dir Ziele setzt und auswählst, welche Backlog-Elemente du für den nächsten Sprint erledigen möchtest, solltest du dir darüber im Klaren sein, was es bedeutet, die Ziele, die du erreichen möchtest, zu erreichen und zu erreichen.

5. Richten Sie Sprintziele mit Produktzielen aus

Sprintziele sollten immer mit Ihren umfassenderen Produktzielen übereinstimmen. Ihr Sprint kann je nach aktuellen Produktproblemen, Bugfixes oder Kundenanliegen eine bestimmte Richtung einschlagen, aber es ist wichtig, das Gesamtbild im Auge zu behalten.

Wählen Sie Backlog-Elemente sorgfältig aus — stellen Sie sicher, dass sie sich auf das übergeordnete Produktziel beziehen und dass alle Elemente synchron funktionieren, um die Entwicklung voranzutreiben. Das Übersehen von Produktzielen in der Sprint-Planung könnte bedeuten, dass jeder Sprint eher wie eine zufällige Auswahl von To-do-Listen aussieht, die sich nicht auf die Kundenbedürfnisse beziehen, keinen Bezug zu Produktzielen haben oder Ihnen helfen, wichtige Etappen zu erreichen. Das Ergebnis wird sich wie ein Mangel an Fortschritten anfühlen, was die Gefahr birgt, dass das Team und andere wichtige Interessengruppen, wie Ihre Benutzer, aus dem Blickfeld geraten.

Was passiert als Nächstes?

Nachdem die Planung abgeschlossen ist, können Sie Ihren Plan umsetzen und die Arbeit abschließen. Das heißt aber nicht, dass die Teammitglieder losziehen und isoliert arbeiten.

Tägliches Scrum (oder Stand-up)

Das tägliches Gedränge oder Stand-up ist eine Gelegenheit für ein kollaboratives agiles Team, den Fortschritt aufrechtzuerhalten. Es sollte ein schneller Check-in zu Beginn eines jeden Tages sein.

Das Team wird besprechen, was in den letzten 24 Stunden getan wurde, auf welche Hindernisse es gestoßen sein könnte und was das Team am nächsten Tag zu erreichen hofft.

Dieses wichtige Check-In hilft dem Team, auf derselben Wellenlänge zu bleiben, trägt dazu bei, den kontinuierlichen Arbeitsfluss sicherzustellen und das Team auf Kurs zu halten, um die Sprintziele zu erreichen.

Sprint-Bewertung

Am Ende eines Sprints findet ein Sprint-Review-Meeting statt. Es ist eine Gelegenheit für das Team, alle „Erledigt“ -Probleme für diesen Zeitraum zu überprüfen. Das Sprint-Review bestimmt, ob das Ziel für den Sprint erreicht wurde oder nicht.

Es ist eine Gelegenheit, dem Team die lieferbaren, funktionstüchtigen Produktzuwächse zu demonstrieren, und auch eine Gelegenheit, Feedback von Interessenvertretern einzuholen. Dieses Feedback gibt Ihnen wertvolle Erkenntnisse, anhand derer Sie beurteilen können, ob Sie auf dem richtigen Weg sind oder im nächsten Sprint Änderungen vornehmen müssen. Das Sprint-Review ist auch eine hervorragende Vorbereitung auf die nächste Backlog-Grooming- und Sprint-Planungssitzung.

💡 Erfahre mehr: Einführung in Sprint Reviews

Sprint-Rückblick

Während im Sprint-Review untersucht wird, was erreicht wurde und wie es weitergehen soll, untersucht die Retrospektive Ihre Prozesse und die Zusammenarbeit des Teams.

Was hast du im letzten Sprint gelernt? Retrospektiven können zwar viele Formen annehmen, aber das Ziel besteht darin, herauszufinden, was gut funktioniert hat, was nicht so gut gelaufen ist und was beim nächsten Mal verbessert werden könnte. Ihr Team wird die in der Retrospektive gesammelten Erkenntnisse nutzen, um Ihre Zusammenarbeit zu verbessern und Ihren Kunden in Zukunft einen Mehrwert zu bieten.

💡 Erfahre mehr: 5 Schritte zur Durchführung effektiver Sprint-Retrospektiven

Fehler bei der agilen Sprint-Planung

Es ist leicht, in schlechte Angewohnheiten zu verfallen, besonders wenn Termine und Produkteinführung Termine nähern sich. Vermeiden Sie diese üblichen agile Planungsfehler um sicherzustellen, dass Ihr Team immer das Beste aus der agilen Methodik und dem Scrum-Prozess herausholen kann.

Unrealistische Erwartungen

Wenn Sie unerreichbare Ziele wählen, ist Ihr gesamtes Team zum Scheitern verurteilt. Wenn Sie Ihre Sprintziele Sprint für Sprint nicht erreichen, schadet dies der Motivation und Moral des Teams.

Verwenden Sie Schätzungen, um so gut wie möglich vernünftige Ziele zu setzen. Berücksichtigen Sie die Teamkapazität und berücksichtigen Sie Ihr bisheriges Wissen darüber, wie lange die Erledigung von Aufgaben dauert, wie das Team arbeitet und welche Hindernisse sich dabei ergeben könnten.

Fehlender Kontext

Ihr Team wird von einem Verständnis dafür profitieren, wie die Probleme, an denen es arbeitet, in das Gesamtbild passen.

Je nachdem, welches Tool Sie für die Planung und Verwaltung Ihrer Arbeit verwenden, kann es schwierig sein, die kontextuellen Details zu erkennen, die für eine klare Planung und Arbeit erforderlich sind. Je mehr Elemente Sie haben, desto schwieriger und überwältigender wird es sein, sie zu organisieren und zu priorisieren. Verwenden Sie Tools, mit denen Sie Kontext, Tiefe und Kundeneinblicke mit übersichtlichen Funktionen hinzufügen können, um Ihren Plan an die Bedürfnisse Ihres Teams und Ihrer Stakeholder anzupassen.

Vernachlässigen Sie Ihren Backlog

Wir haben diesen Punkt erwähnt, als wir darüber gesprochen haben, was Sie tun müssen, um sich auf die Sprint-Planung vorzubereiten. Es lohnt sich, ihn noch einmal zu erwähnen, da es sich um einen häufigen Fehler handelt.

Wenn Sie ohne einen gut verwalteten Backlog in ein Sprint-Planungsmeeting gehen, fehlt Ihnen die Klarheit, die Sie für eine effektive Planung benötigen. Ihre Zeit ist wertvoll, ebenso wie die Zeit Ihres Teams. Sie sollte daher mit Sorgfalt behandelt und effektiv genutzt werden.

Ein gut verwaltetes Backlog ist TIEF:

• Angemessen detailliert
• Geschätzt
• Aufstrebend
• Priorisiert

💡 Erfahre mehr: Die 4 Merkmale eines guten Produkt-Backlogs

Keine Anpassung des Plans

Wenn du deinen Sprint planst, wirst du alles in deiner Macht Stehende tun, um die wichtigsten Aufgaben für die Dauer des Sprints zu priorisieren. Es ist wichtig, dass Sie versuchen, sich so gut wie möglich an den Plan zu halten, aber Sie müssen sich auch anpassen, wenn Sie neue Informationen erhalten.

Seien Sie bereit, im Handumdrehen Änderungen vorzunehmen, falls Sie auf Hindernisse stoßen oder neue Informationen über Kundenbedürfnisse, Bedenken oder Produktprobleme erhalten.

Stakeholder nicht verstehen

Sie müssen die Ziele und Prioritäten der Stakeholder verstehen, um erfolgreich zu sein. Nur weil Sie mit dem, was Sie erreicht haben, zufrieden sind, heißt das nicht, dass Ihre Stakeholder es auch tun werden.

Stellen Sie sicher, dass Ihre Stakeholder früh und häufig in Ihren Prozess einbezogen werden, und machen Sie ihnen klar, wie Sie arbeiten, um ihnen einen Mehrwert zu bieten. Holen Sie regelmäßig Feedback von Stakeholdern ein, um sicherzustellen, dass Ihre Ziele aufeinander abgestimmt sind. Ein guter Zeitpunkt dafür ist während des Sprint Reviews. Stellen Sie einfach sicher, dass diese Erkenntnisse auf Ihr nächstes Planungsgespräch übertragen werden.

Wählen Sie keine Tools mit einem kundenorientierten Ansatz

Eine erfolgreiche Produktentwicklung liefert, was der Kunde braucht und will. Um Produkte für Ihre Kunden zu entwickeln, ist es hilfreich, Tools für Planung und Arbeitsmanagement zu verwenden, mit denen Sie sie ganz einfach im Auge behalten können. Wenn Sie User Story Maps und Kundenpersönlichkeiten in Ihre Planung einbeziehen, können Sie und Ihr Team die Arbeit priorisieren, die zuerst den größten Nutzen bringt.

💡 Erfahre mehr: 10 Tipps für effektivere User Personas

Versäumnis, rückwirkende Erkenntnisse in die Planung einzubeziehen

Retrospektiven sind das Beste, was Sie tun können, um Ihrem Team zu helfen, besser zusammenzuarbeiten. Während einer Retrospektive bitten Sie Ihr Team, offen und ehrlich darüber zu sprechen, wie sich die Dinge im Laufe des Sprints entwickelt haben, damit Sie voneinander lernen können.

Wenn Sie nicht aus diesen Erkenntnissen lernen, bedeutet dies, dass die kollektive Zeit, die Sie in der Retrospektive verbracht haben, verschwendet wurde und das Feedback, das Ihr Team geteilt hat, abgewertet wird.

Wenn Sie die Erkenntnisse, die Sie aus einer Retrospektive gewinnen, in Ihre nächste Planungssitzung und in den nächsten Sprint einfließen lassen, wird Ihr Team dabei unterstützt, jedes Mal besser zu werden, sodass es mit der Arbeit zufriedener wird und bessere Ergebnisse erzielt.

Virtuelle oder persönliche Sprint-Planung

Die Vorteile der Telearbeit stellen auch die kollaborative Planung vor Herausforderungen. Ganz gleich, für welche Art sich Ihr Team entscheidet, ob virtuell, persönlich oder in einer Kombination aus beidem, es ist wichtig, dass Sie Werkzeuge wählen die den Bedürfnissen Ihres Teams entsprechen.

Tipps für die virtuelle Sprint-Planung:

• Seien Sie wirklich vorbereitet — kommunizieren Sie Ihre Pläne im Voraus klar und deutlich, sodass jeder klare Erwartungen hat.
• Verwenden Sie ein Videokonferenz-Tool, das Breakout-Sitzungen ermöglicht
• Richten Sie die interaktiven Online-Ressourcen ein, die Sie verwenden möchten, und fügen Sie Links in die Besprechungsanfrage ein.
• Online-Diskussionen beginnen nicht so natürlich wie persönlich. Teilen Sie daher die Diskussionsthemen im Voraus mit und überlegen Sie, ob Sie einige Eisbrecher vorbereiten sollten.
• Stellen Sie sicher, dass Sie Zeitunterschiede für Teams berücksichtigt haben, die sich über mehrere Zeitzonen erstrecken.
• Technische Probleme treten auf, unabhängig davon, wie weit Sie im Voraus planen und testen. Erwarte immer das Unerwartete.

Tipps für die persönliche Sprint-Planung:

• Buchen Sie einen Tagungsraum mit viel Platz für Ihr Team und ziehen Sie separate Räume für Breakout-Sitzungen in Betracht.
• Stellen Sie sicher, dass Ihr Besprechungsraum eine gemeinsame Ansicht Ihres Sprint-Plans bietet. Benötigen Sie eine Wand für Haftnotizen oder einen Bildschirm, auf dem Sie ein digitales Tool gemeinsam nutzen können?
• Wenn einige Ihrer Teammitglieder remote arbeiten, ist es schwierig, sie auf die gleiche Weise einzubeziehen. Überlegen Sie sich also, wie das für Ihr Team funktionieren könnte. Sie werden ein Whiteboard oder Haftnotizen nicht so einfach lesen können, daher ist eine digitale Lösung möglicherweise die beste.
• Wenn Sie sich dafür entscheiden, Ihren Sprint „an der Wand“ zu planen, sollten Sie am Ende des Planungsgesprächs unbedingt jemanden benennen, der Ihren Plan in Ihr Arbeitsmanagement-Tool transkribiert.

Egal, wo Ihre Planung stattfindet, denken Sie immer daran, Ihr Backlog im Voraus vorzubereiten, damit Sie während der Sprint-Planung fokussierte und fundierte Diskussionen führen können.

Zusätzliche agile Ressourcen

Wir erweitern ständig unsere Inhaltsbibliothek, die mit Ressourcen, Anleitungen, Produktupdates und vielem mehr gefüllt ist.

📚 Füge diese zu deiner Liste hinzu:

• Easy Agile Podcast Ep.20: Die Bedeutung der Team-Retrospektive
• Easy Agile Podcast Ep.18 Die besten Eigenschaften eines agilen Leiters und Teams
• Easy Agile Podcast Ep.16 Unterstützung leistungsstarker agiler Teams mit Adaptavist
• Agil sein oder agil handeln
• Der ultimative Leitfaden für User Story Mapping
• Der ultimative Leitfaden für Buyer Personas
• Der ultimative Leitfaden zur PI-Planung [2022 SAFe Edition]

Verwenden von Easy Agile zur Verbesserung der Sprint-Planung

Machen Sie Ihre Sprint-Planung reibungslos und effektiv mit Einfacher agiler Teamrhythmus. Verwandeln Sie Ihren flachen Produktbestand in eine dynamische, flexible und visuelle Darstellung der zu erledigenden Arbeit. TeamRhythm ist nahtlos in Jira integriert und bietet folgende Möglichkeiten:

• Sieh dir deine Jira-Storys, Aufgaben und Bugs im Kontext an, geordnet unter ihren Epen auf der Story-Map
• Ziehen Sie Jira-Issues per Drag-and-Drop aus dem Backlog in einen Sprint
• Neue Ausgaben direkt auf der Storymap erstellen
• Schätzen Sie Probleme auf der Story-Map ab und messen Sie die Kapazität anhand der Gesamtzahl der Story-Punkte in jeder Sprint-Swimlane
• Veröffentlichen Sie das Sprintziel auf jeder Sprint-Swimlane, damit es immer im Vordergrund steht
• Verwenden Sie Filter, um sich auf die Geschichten und Themen zu konzentrieren, die gerade am wichtigsten sind
• Gruppieren Sie Epen nach einer dritten Hierarchieebene, um leicht zu erkennen, wie die Arbeit im Fokus zum Gesamtbild beiträgt

Easy Agile TeamRhythm unterstützt auch Team-Retrospektiven mit flexiblen und intuitiven Retrospektiven-Boards, die für jeden Sprint erstellt werden. Du kannst rückblickende Elemente direkt von der Sprint-Swimlane aus hinzufügen, damit du keine wichtigen Punkte vergisst. Und du kannst rückwirkende Maßnahmen in Jira-Ausgaben umwandeln, die für zukünftige Sprints geplant werden können, sodass du in dem, was du tust, immer besser wirst und das für deine Kunden lieferst.

Vielen Dank, dass Sie unseren ultimativen Leitfaden zur agilen Sprint-Planung gelesen haben! Wenn Sie Fragen zu diesem Leitfaden, unseren anderen Inhalten oder unseren Produkten haben, wenden Sie sich an unser Team zu jeder Zeit. Wir freuen uns, von Ihnen zu hören.

Wir werden diesen Leitfaden weiter aktualisieren, sobald wir mehr Erkenntnisse, Techniken, Tools und Best Practices zur agilen Planung gewinnen.