Keine Artikel gefunden.

Einsatz von Epics: Agile Teams maximieren die Leistung mit diesem Tool

Inhalt
Dies ist ein Text innerhalb eines div-Blocks.
Dies ist ein Text innerhalb eines div-Blocks.
Dies ist ein Text innerhalb eines div-Blocks.
Abonnieren Sie unseren Newsletter

Heb deine Hand, falls du jemals einen Streit hattest, hoppla 😳 — ich meine eine hitzige Diskussion — darüber, wie Jira eingerichtet und organisiert werden kann. Ja, wir auch.

Zu den heiß umkämpften Themen gehören:

  • Projekt: Ist es am besten, nach Team, Funktion, Funktion oder Produkt zu organisieren?
  • Agile Epen, Features, Stories, Aufgaben, Unteraufgaben, Bugs — was solltest du wann verwenden?
  • Spaltenüberschriften und Swimlanes im Sprint-Board — da gehen wir gar nicht hin.

Leider gibt es in Jira oder einem anderen Tool, das dein Agile-Team verwendet, nicht den besten Workflow. Wichtiger als dein Workflow ist es, deine Teammitglieder so einzurichten, dass sie deinen Endbenutzern einen konsistenten Geschäftswert bieten. Das Ziel Ihres agilen Projektmanagements ist es, Ihr Scrum-Team bei diesem Unterfangen zu befähigen und zu unterstützen.

Wir werden uns einen Aspekt Ihres Prozesses ansehen — anhand der Epics, die agile Teams verwenden. Bleiben Sie bei uns und wir erklären, was ein Epos ist, warum agile Epen wichtig sind und wie Sie einige epische Fehler vermeiden können.

Was ist ein Epos?

Epics agile: Woman thinking through agile process

Einfach ausgedrückt ist ein Epos ein Eimer, der kleinere Arbeitsaufgaben enthält, die erledigt werden müssen, um die Aufgabe zu erfüllen. Manche Leute betrachten Epics als eine große Nutzerstory. Das ist in Ordnung, wenn es dir hilft, es zu visualisieren, aber Epen unterscheiden sich stark von Geschichten.

  • Agile Teams verwenden Epics für die Planung unterschiedlich oder gar nicht.
    Dein Team kann ihm zwar eine T-Shirt-Größe geben, aber der Arbeitsaufwand in einem Epos ist normalerweise zu groß, um ihn in Storypoints abzuschätzen. Manche Epen sind so umfangreich, dass sie in kleinere Epen aufgeteilt werden müssen, bevor du überhaupt nach Schätzungen für das Team fragst.
  • Ein Epos ist nicht wie eine User Story geschrieben.
    Sie kennen die Vorlage — „Als Benutzer möchte ich X, damit ich Y kann.“ Das ist perfekt für eine User Story, aber nicht so sehr für ein Epos. Ein episches Beispiel könnte „Cross-Sells hinzufügen“ mit einer Beschreibung sein, die Orte auflistet, an denen der Product Owner dem Endverbraucher Gelegenheiten zum Kauf verwandter Produkte bieten möchte. Das ist keine Geschichte, sondern eine Bitte um Funktionalität.
  • Das Epos könnte als Platzhalter für Arbeiten dienen, die noch definiert werden müssen.
    Ihr Product Owner kann Epics als Platzhalter in einer Produkt-Roadmap für die langfristige Planung verwenden. Sie werden mit der Definition der Arbeit warten, bis der Zeitrahmen für die Implementierung näher rückt.
  • Ein Epos wird selten in einem einzigen Sprint abgeschlossen.
    Aufgrund ihrer Größe passen Epen normalerweise nicht in eine Iteration. Ihr Softwareentwicklungsteam teilt die Funktionalität so auf, dass es in jedem Sprint funktionierende Software liefern kann. Das kann bedeuten, dass sie zwei Sprints lang eine oder zwei Geschichten aus einem Epos fertigstellen, einen Sprint überspringen und dann im nächsten Sprint zu den Geschichten in diesem Epos zurückkehren.
  • Epics können Akzeptanzkriterien haben oder nicht.
    In einigen Scrum-Teams müssen Epics keine Akzeptanzkriterien haben, da diese in den Geschichten enthalten sind. Wenn alle Kindergeschichten dem entsprechen, was das Scrum als Definition von Erledigt definiert, ist das Epos auch erledigt.

Epen sind Eltern und Großeltern von Geschichten und Aufgaben. Entwicklungsteams arbeiten nicht an Epics, sondern programmieren eher für die kleineren User Stories unter dem Epos.

Die Bedeutung von Epics in Ihrer agilen Praxis

Epics agile: Agile team in a discussion

Unterschätzen Sie nicht den organisatorischen Wert, den Epen für Ihr Produkt-Backlog haben. Das Korrigieren von 10 oder 20 verwandten Backlog-Elementen kann die Sprint-Planung stören. Epics bieten einen kohärenteren Blick auf die Arbeit und ermöglichen es Ihrem Scrum-Team, das Gesamtbild zu sehen.

Epics bieten Führungskräften und Produktmanagern einen umfassenden Überblick über laufende Arbeiten und zukünftige Entwicklungen.

Product Owner verwenden Epics, um einen Produktplan aus geschäftlicher Sicht zu erstellen. Aktuelle Geschäftsziele können vorschreiben, dass sich die Entwicklungsarbeit auf ein bestimmtes Merkmal konzentriert, das durch Epics repräsentiert wird. Im Gegensatz dazu helfen Epics Product Ownern auch dabei, Sprints mit einem angemessenen Arbeitsverhältnis aus mehreren Epics zu planen. Product Owner können einen Schritt von den detaillierten Nutzerberichten Abstand nehmen und sicherstellen, dass jede Iteration Geschichten aus mehreren Epen enthält, um mehrere Stakeholder zufrieden zu stellen.

Die Art und Weise, wie Epics in Produkt-Backlogs und Roadmaps visuell dargestellt werden, ist für die langfristige Planung von entscheidender Bedeutung. Können Sie sich vorstellen, eine sechsmonatige Roadmap auf User-Story-Ebene zu planen? Es wäre Chaos!

Agile Frameworks fördern — nein — fordern die Fähigkeit, den Kurs nach Bedarf anzupassen, um den sich ändernden Bedürfnissen der Interessengruppen, Marktanforderungen und Geschäftsziele gerecht zu werden. Mit Epics können Sie Ihre Roadmaps einfach und schnell an Veränderungen anpassen.

Wie Epics der agilen Entwicklung einen Mehrwert verleihen

Businessman holding a briefcase, covered in sticky notes

Discovery ist ein wichtiger Aspekt agiler Methoden und des Produktmanagements. Zu Beginn dieses Prozesses werden Ihre Teams Events stürmen, Personas erstellen und Journey Maps erstellen. Die umsetzbaren Ergebnisse dieser Aktivitäten können in Jira mit Epics einfach protokolliert und organisiert werden.

Wenn diese Epen weiter verfeinert werden, werden sie einer Roadmap hinzugefügt und dann auf die Tagesordnung einer Verfeinerungszeremonie gesetzt. Während der Verfeinerung engagieren sich die Mitglieder des Scrum-Teams für Zuordnung von Benutzergeschichten Übungen und beginnen Sie mit der Erstellung der Details, die das Entwicklungsteam zur Ausführung benötigt.

Epics bieten zwar einen weniger detaillierten Überblick über Funktionen und Anfragen Ihres Product Owners, sind aber für die Erstellung von User Stories von entscheidender Bedeutung. Ohne den kohärenten Überblick über Ihren Sprint-Backlog, der mithilfe von Epics präsentiert wird, besteht bei agilen Sprints die Gefahr, dass eine Menge Arbeit geleistet wird, die nichts miteinander zu tun hat, aber nur einen geringen Mehrwert bietet.

Wann sollte man kein Epos benutzen

Wir lieben das Agile Epic, aber es ist nicht für alles perfekt. Hier sind einige Dinge, die Sie bei der Verwendung von Epics vermeiden sollten.

Das immergrüne Epos

Du kennst den einen. Das Epos entstand, als die Leute aufgehört haben, kabelgebundene Telefonleitungen zu benutzen, und es ist seither in einem halbfertigen Zustand in Ihrem Backlog hängen geblieben. Tief im Inneren findest du Geschichten und Aufgaben von Nutzern, die vielleicht kaum oder gar nichts miteinander zu tun haben. Dieses arme Epos ist zur Müllhalde für verwaiste Geschichten geworden, die nirgendwo anders ein Zuhause gefunden haben.

Immergrüne Epen können das Ergebnis einer Änderung der Geschäftsziele oder der Produktmerkmale sein. Das ist großartig — du hast dich angepasst! Jetzt musst du dein Epos aktualisieren, um das widerzuspiegeln. Geschichten können entfernt werden, Code kann bereitgestellt oder zurückgestellt werden, und unvollständige Geschichten können gelöscht oder aus dem Epos entfernt und neu priorisiert werden.

Brainstorming ist auch ein Grund für immergrüne Epen. Oben haben wir erwähnt, dass die Ergebnisse von UX-Aktivitäten eine großartige Möglichkeit sind, umsetzbare Elemente zu verwalten. Wir haben nicht gesagt, dass Sie Epics als Zuhause für jede Idee verwenden sollten, die während des Brainstormings auftaucht und die es vielleicht nie in Ihre Roadmap schaffen wird oder auch nicht.

Epen sind nicht dafür bestimmt, ewig zu leben. Sie stellen eine Reihe von Arbeiten dar, die Ihren Endbenutzern einen Mehrwert bieten. Sie müssen abgeschlossen sein, damit Sie die Ergebnisse Ihrer Bemühungen messen können. Immergrüne Epen überladen Ihre Roadmap, lassen Ihren Fokus verschwimmen und schränken deren Planungswert ein.

Das Themen-Epos

Young work team sitting behind a wall that says "prioritize"

Es ist einfach, Geschichten Epen zuzuordnen, weil sie sich auf einen bestimmten Bereich im Produkt beziehen, eine bestimmte Codebasis berühren oder eine Einzelperson oder eine Gruppe von Stakeholdern zufrieden stellen. Das ist nicht der Zweck eines Epos. Themes eignen sich besser, um Arbeiten nach anderen Attributen als nach einer bestimmten Feature-Implementierung zu gruppieren.

Sie können Ihre Unternehmensziele erreichen, indem Sie Themen verwenden, um diese Geschichten miteinander zu verknüpfen und gleichzeitig die Integrität des Umfangs innerhalb Ihres Epos zu wahren.

Verwenden Sie Epics, um sich auf bestimmte Ergebnisse oder Funktionen zu konzentrieren. Verwandt oder nicht, wenn eine Geschichte innerhalb eines Epos nicht zum Hauptfokus des Epos beiträgt, entferne sie. Das heißt nicht, dass es nicht wichtig ist oder dass es nicht die richtige Arbeit ist, die während der Iteration erledigt werden muss. Das heißt nur, dass es nicht Teil dieses Epos ist.

Wenn Sie sorgfältig mit dem Umfang umgehen, sind Ihre Schätzungen übersichtlicher und für die zukünftige Planung nützlicher. Unnötige Geschichten in Epen übertreiben ihre Schätzungen und den tatsächlichen Aufwand. Wenn Sie einmal auf ältere Arbeitsaufgaben zurückblicken müssen, werden Sie sich wahrscheinlich nicht erinnern, dass das Hinzufügen von zwei Geschichten, die nichts miteinander zu tun haben, ein Epos von einem mittleren zu einem großen gemacht hat. Wenn Sie dieses alte Arbeitselement als Leitfaden für die zukünftige Planung verwenden, haben Sie den Aufwand einfach überschätzt, weil Sie den Umfang nicht auf das Ziel des Epos beschränkt haben.

Denken Sie daran — nicht jede Geschichte braucht ein episches Elternteil. Manche Geschichten stehen für sich alleine gut da und lassen sich anhand von Themen vielleicht besser visualisieren und planen.

Das Release-Epos

Eine Veröffentlichung ist kein Epos. Eine Version ist ein bestimmter Satz von Code und Dateien, die gebündelt und gleichzeitig an die Produktion geliefert werden. Eine Veröffentlichung kann ein Epos oder viele Epen enthalten oder auch nicht. Aber an sich ist eine Veröffentlichung kein Epos.

Es gibt hervorragende Tools auf dem Markt, die speziell entwickelt wurden, um Sie beim Release-Management zu unterstützen. Ordnen Sie Ihre Epics auf jeden Fall einer Version zu, aber verwenden Sie Release-Tools, um Ihre Releases zu organisieren, und verwenden Sie Epics, um Ihre Funktionen zu organisieren.

Epics sind mehr als eine große User Story

Team climbing to a plateau during a sunrise

Ihr agiler Coach oder Scrum Master hat Sie wahrscheinlich mit den Prinzipien agiler Software vertraut gemacht, daher kennen Sie das folgende Zitat von Die 12 Prinzipien agiler Software:

„Einfachheit — die Kunst, die Menge zu maximieren
wenn die Arbeit nicht erledigt ist — das ist essenziell.“

Aber was hat das mit Epen zu tun?

Epics vereinfachen deinen Backlog. Sie ermöglichen es Ihnen, sich zur richtigen Zeit auf die richtigen Dinge zu konzentrieren und den Lärm fernzuhalten. Sie behalten den Ball im Auge, wenn es darum geht, Werte zu priorisieren und die Knöchelbeißer in Ihrem Backlog zu ignorieren.

Wir glauben, dass die Verwendung von Epics zu einer besseren Organisation Ihres Backlogs und einer besseren Planung für Ihre agilen Teams führt. Epics helfen Ihnen dabei, schneller einen Mehrwert zu liefern, indem Sie sich auf das große Ganze konzentrieren und sich vom Unklaren fernhalten.

Wenn du eine kontextuellere Ansicht deiner Epen und User Stories in Jira haben möchtest, probieren Sie Easy Agile TeamRhythm aus. Das stark visuelle Story-Map-Format verwandelt das flache Jira-Backlog in ein aussagekräftiges Bild der Arbeit, sodass Sie Ihr Backlog einfacher verwalten und Sprints oder Versionen planen können.

Easy Agile TeamRhythm
Verbessern Sie die Zusammenarbeit und Bereitstellung im Team

Verwandte Artikel

  • Workflow

    Der ultimative Leitfaden zum User Story Mapping [2024 Guide]

    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 Mapping Session

    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

    Anatomy of a 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:

    As a software developer, I want to tick off my tasks as I complete them so that I always know where I’m up to.

    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.

    The Backbone

    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

    Flat Backlog to Story Map

    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?

    Team does story mapping

    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:

    What a traditional user story mapping session can look like

    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).
    backlog
    „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

    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.

    A screenshot of Easy Agile User Story Maps is shown for a car media/controls system. Stories are mapped to epics, including navigation, car statistics, phone integration, play media, and fatigue management. They’re split across Sprint 1 and Sprint 2, with a backlog of unscheduled items on the right.

    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.

  • Workflow

    Wie schreibt man User Stories in der agilen Softwareentwicklung

    Manchmal scheint die Idee, User Stories zu schreiben, eine weitere „Sache“ zu sein, die zu einer ohnehin schon vollen Arbeitsbelastung hinzukommt. Aber für Softwareentwicklungsteams, die ihre eigenen Verbesserungen selbst vorantreiben und Software liefern wollen, die für ihre Kunden funktioniert, ist das Schreiben effektiver User Stories der erste Schritt.

    Wenn Sie diesen Beitrag lesen, bedeutet das, dass Sie herausfinden möchten, was für die Menschen, die Ihre Software verwenden, am besten funktioniert, und Ihre Herangehensweise an die Softwareentwicklung verbessern möchten. Das ist großartig! Unser Ziel bei Easy Agile ist es, Ihnen dabei zu helfen.

    Beginnen wir also damit, warum gute User Stories wichtig sind.

    Warum User Stories schreiben?

    Sie fragen sich vielleicht, warum Sie User Stories schreiben sollten, anstatt stattdessen Funktionen oder Aufgaben zu schreiben.

    Wenn das nach Ihnen klingt, haben Sie vielleicht noch nicht erkannt, wie wichtig es ist, User Stories zu schreiben, und dass sie einem ganz anderen Zweck dienen als das Schreiben von Funktionen oder Aufgaben.

    Es ist leicht, sich in einem Zyklus der Feature-Entwicklung zu verlieren, dem es an Kontext mangelt. Das Ziel besteht mehr darin, sich den Weg durch einen großen Backlog freizumachen, als Lösungen zu entwickeln, die Ihren Kunden einen Mehrwert bieten. Um erfolgreiche Software zu entwickeln, müssen Sie sich auf die Bedürfnisse der Menschen konzentrieren, die sie verwenden werden. Ihre menschlichen Kunden. Nutzerberichte bringen diesen Kontext und diese Perspektive in den Entwicklungszyklus ein.

    Was ist eine User Story?

    Eine User Story hilft agilen Softwareentwicklungsteams, sich in ihre Kunden hineinzuversetzen. Aus der Sicht des Kunden (oder Benutzers) geschrieben, helfen User Stories dem Entwicklungsteam zu verstehen, was es entwickeln muss und warum es es erstellen muss.

    User Stories sind vereinfachte, allgemeine Beschreibungen der Anforderungen eines Benutzers, die aus der Sicht des Endbenutzers verfasst wurden. Eine User Story ist kein kontextloses Feature, das in der Sprache der Entwickler geschrieben ist.

    user story or task

    Eine User Story = das „Was“

    Eine User Story beschreibt eine Funktion aus der Sicht des Benutzers.

    User Stories unterteilen Funktionen in Geschäftsprozesse.

    Eine Aufgabe = das „Wie“

    Aufgaben sind die Aktivitäten, die ausgeführt werden müssen, um ein Ergebnis zu erzielen.

    Aufgaben sind einzelne Arbeiten.

    Wie schreiben wir User Stories?

    Vielleicht möchten Sie sich eine User Story als „Gleichung“ vorstellen:

    Als [Benutzer] + möchte ich [Absicht] +, damit [Wert]

    Lassen Sie uns das weiter aufschlüsseln;

    Als [Benutzer] — das ist die WHO. Für wen bauen wir das? Wer ist der Nutzer?

    Ich will [Absicht] — das ist das WAS. Was bauen wir? Was ist die Absicht?

    Also das [Wert] — das ist das WARUM. Warum bauen wir es? Was ist der Wert für den Kunden?

    who what why

    Schauen wir uns ein paar einfache Beispiele an;

    Als Internetbanking-Kunde

    ich will um einen fortlaufenden Saldo für meine täglichen Konten zu sehen

    Also das Ich kann nach jeder Transaktion den Überblick über meine Ausgaben behalten

    ODER

    Als Administrator

    ich will um andere Administratoren für bestimmte Projekte erstellen zu können

    Also das Ich kann Aufgaben effizienter delegieren

    Gemäß dieser Gleichung sollten Teams sicherstellen, dass ihre User Stories alle der folgenden Checkboxen ankreuzen:

    user story checklist

    Um erfolgreiche User Stories zu schreiben:

    • Halte sie kurz
    • Halte sie einfach
    • Schreiben Sie aus der Sicht des Benutzers
    • Machen Sie den Wert oder Nutzen der Geschichte deutlich
    • Beschreiben Sie eine Funktion
    • Schreiben Sie im Team User Stories
    • Verwenden Sie Akzeptanzkriterien, um einen MVP anzuzeigen.

    Akzeptanzkriterien

    User Stories ermöglichen es agilen Teams, die Bedürfnisse, Wünsche und Werte ihrer Kunden mit den Aktivitäten in Einklang zu bringen, die sie durchführen müssen, um diesen Mehrwert zu bieten.

    Der Link, der diese beiden Dinge miteinander verbindet, sind Akzeptanzkriterien.

    Die Akzeptanzkriterien oder „Erfüllungsbedingungen“ geben einen detaillierten Überblick über die Benutzeranforderungen. Sie helfen dem Team, den Wert der User Story zu verstehen und helfen dem Team zu wissen, wann es erwägen kann, etwas zu tun.

    Ziele der Akzeptanzkriterien

    Die Akzeptanzkriterien sollten:

    • klären Sie, was das Team bauen soll, bevor es mit der Arbeit beginnt
    • Sicherstellung eines gemeinsamen Verständnisses des Problems oder der Bedürfnisse des Kunden
    • Helfen Sie den Teammitgliedern, zu wissen, wann die Geschichte abgeschlossen ist
    • helfen Sie dabei, die Geschichte durch automatisierte Tests zu überprüfen.

    Schauen wir uns ein Beispiel für eine abgeschlossene User Story mit Akzeptanzkriterien an:

    Als potenzieller Konferenzteilnehmer möchte ich mich online für die Konferenz anmelden können, sodass die Registrierung einfach und papierlos ist.

    Akzeptanzkriterien:

    • Teilnahmeformular für die Konferenz
    • Ein Benutzer kann kein Formular einreichen, ohne alle Pflichtfelder auszufüllen (Vorname, Nachname, Firmenname, E-Mail-Adresse, Position, Rechnungsinformationen)
    • Informationen aus dem Formular werden in der Registrierungsdatenbank gespeichert.
    • Der Schutz vor Spam funktioniert
    • Die Zahlung kann per Paypal, Lastschrift oder Kreditkarte erfolgen
    • Nach dem Absenden des Formulars wird dem Teilnehmer eine Bestätigungs-E-Mail gesendet

    Vor diesem Hintergrund sollten die Teams sicherstellen, dass ihre Akzeptanzkriterien alle folgenden Punkte berücksichtigen:

    • Negative Szenarien der Funktionalität
    • Funktionale und nicht funktionale Anwendungsfälle
    • Leistungsbedenken und Richtlinien
    • Was das System oder die Funktion zu tun beabsichtigt
    • durch/Benutzerfluss
    • Der Einfluss einer User Story auf andere Funktionen
    • UX-Bedenken
    acceptance criteria checklist

    Die Akzeptanzkriterien sollten NICHT Folgendes beinhalten:

    • Die Codeüberprüfung wurde durchgeführt
    • Nichtblocker oder größere Probleme
    • Leistungstests durchgeführt
    • Abnahme und Funktionstest abgeschlossen

    Warum?

    Ihre Akzeptanzkriterien sollten keines der oben genannten Punkte enthalten, da Ihr Team bereits ein klares Verständnis davon haben sollte, was Ihre Definition of Done (DoD) beinhaltet, zum Beispiel:

    • Einheit/integriertes Testen
    • bereit für den Abnahmetest
    • auf dem Demoserver bereitgestellt
    • lösbar

    Das Schreiben effektiver User Stories ist eine wertvolle Praxis, die Ihnen und Ihrem Team dabei hilft, Software bereitzustellen, die für Ihre Kunden relevant bleibt.

    Wenn Sie User Stories als mehr als nur eine weitere Aufgabe auf Ihrer Checkliste betrachten, sondern sie stattdessen als unverzichtbares Instrument betrachten, um Kontext und Wert für Ihre Projekte zu schaffen, können Sie mit Ihrem wichtigsten Fokus in Verbindung bleiben — Ihrem Kunden.

    Verwandeln Sie Ihr Backlog in ein aussagekräftiges Bild der Arbeit, um Kontext für die Sprint- und Versionsplanung, die Backlog-Verfeinerung und das User Story Mapping zu erhalten.

    Konzentrieren Sie sich auf Ihre Kunden

    Einfacher agiler Teamrhythmus

  • Agile Best Practice

    7 Produktmanagement-Softwaretools zur Rationalisierung der Entwicklung

    Sie können Dutzende von Produktmanagement-Tools finden, die den SaaS-Zielen entsprechen.

    Diese Tools unterscheiden sich in ihren Merkmalen, Funktionen und Preisen. Eines ist jedoch sicher: Produktmanagement-Tools sind unterstützender als je zuvor.

    Finden Sie heraus, welches Produktmanagement Ihre Softwareentwicklung am besten unterstützen kann.

    Was sind Produktmanagement-Softwaretools?

    Softwaretools für das Produktmanagement helfen dabei, Softwareentwicklungsteams durch ihren Arbeitsablauf zu führen.

    Produktmanagement-Tools können Teammitgliedern dabei helfen, Recherchen durchzuführen, Bewertungen zu erstellen, Iterationen durchzuführen und ihre Produkteinführungen zu planen. Einige Tools unterstützen sogar das Roadmapping der Produktentwicklung, sodass sie agile Teams unterstützen können.

    Entwicklungsteams können Roadmapping-Tools verwenden, um:

    • Optimieren Sie die Produktstrategie
    • Erstellen Sie ihren Produktplan
    • Erstellen Sie ihre Produkt-Roadmaps
    • Entwickeln Sie User Journey Maps
    • Backlogs verwalten
    • Recherchen zu den Kundenbedürfnissen durchführen
    • Verbessern Sie die Priorisierung von Produktmerkmalen
    • Bestimmen Sie die Länge ihrer Scrum-Sprints
    • Analysieren Sie Daten für ihre Produktforschung
    • Führen Sie eine Prozesszuordnung durch
    • Produktveröffentlichungen verwalten
    • Verbessern Sie die Zusammenarbeit agiler Teams
    • Neue Produkte erstellen
    • Liefern Sie bessere Produkte
    • Teammitgliedern eine Nachricht senden

    Die Verwendung von Produktmanagement-Tools ist ideal für die Arbeit mit Remote-Teams. Es ist auch die Lösung für die Verbesserung der Zusammenarbeit zwischen funktionsübergreifenden Teams.

    Viele oder die meisten dieser Produktmanagement-Tools lassen sich auch gut in bestehende Software integrieren, sodass es keine große Sache ist, bestehende Systeme anzupassen. Sie können viele dieser Produktmanagement-Tools auch an die Anforderungen Ihres Produktteams anpassen.

    Hier sind acht der bekanntesten Produkt-Softwaretools, mit denen Sie Ihre neue Roadmapping-Reise beginnen können.

    1. Jira

    Jira wird in der Regel als das beste Produktmanagement-Softwaretool für die Softwareentwicklung angesehen. Viele andere Branchen verwenden Jira jedoch für das Roadmapping und die Verwaltung ihrer Projekte. Diese Beliebtheit ist auf die Tatsache zurückzuführen, dass Jira einen kostenlosen Plan anbietet, der jedoch noch tiefer geht.

    Jira ist das ideale Software-Management-Tool für die Verwaltung von Scrum, Kanban, Waterfall und anderen agile Methoden. Die Benutzeroberfläche ist intuitiv, sodass sie einfach und bequem zu bedienen ist, egal ob Sie ein Produktmanager für Software oder andere Produkte sind. Da es sich auch um ein praktisches Tool handelt, können Sie es verwenden, um Aufgaben zuzuweisen und Projekte und Produktentwicklung zu verwalten.

    Produktmanager können Arbeitsabläufe, agile Teamverantwortlichkeiten und Aufgaben leicht im Auge behalten. Sie können sehen, wo sich Backlogs in Scrum oder Kanban aufbauen. Mit der Jira-Software kannst du auch Velocity-Charts, Burndown-Charts, Release-Burndown- und Sprint-Berichte verwalten.

    Du kannst auch Software wie Slack, GitHub und andere hinzufügen, um dein Jira-Produktmanagement-Tool abzurunden.

    Zu den wichtigsten Funktionen, die Sie in dieser Software erwarten können, gehören:

    • Visuelle Erfassung der Produktvision zur Entwicklung besserer Produkte
    • Tools für die Zusammenarbeit, um Teams in Echtzeit an Bord zu halten
    • Gantt-Diagramme zur Anzeige des Projekt- und Produktfortschritts
    • EIN Scrum oder Kanban-Board
    • Benutzerfreundliche Roadmaps
    • Meilensteinverfolgung
    • Portfoliomanagement
    • Umfassendes Agle-Reporting
    • Umfassende Automatisierung des Produktmanagementprozesses
    • Die Fähigkeit, Codes mit Problemen zu verbinden

    In Bezug auf die Preisgestaltung entscheiden sich kleine Unternehmen häufig für den kostenlosen Tarif. Mit dem kostenlosen Tarif von Jira können 10 Benutzer gleichzeitig auf Roadmapping und andere Funktionen zugreifen. Der kostenpflichtige Tarif kostet etwa 7$ pro Monat für jeden Benutzer.

    Agile Teams, die Jira verwenden, können davon profitieren Einfache Agile-Programme für Jira. Es hilft Teams, sich auf ihre Ziele zu konzentrieren, sich auf Funktionen und Epen zu konzentrieren und Abhängigkeiten zu erkennen. Aber alle Einfache Agile-Plugins arbeite mit Jira. Sie vereinfachen alles, von der PI-Planung bis zur Erstellung Personas und Straßenkarten.

    2. Trello

    Trello verwendet ein Kartensystem, um Kanban- und andere Produktentwicklungsabläufe zu verwalten. Wenn der Administrator das Trello-Board einrichtet, erhalten die Produktteams eine visuelle Darstellung von Workflows. Sie können Anwenderberichte sehen, wer für Aufgaben verantwortlich ist, und einen Gesamtüberblick über Arbeitsabläufe und Produktlebenszyklen erhalten. All diese und andere Funktionen sind ein hervorragendes Roadmap-Tool.

    Der Nachteil dieses Systems ist, dass es keinen Kalender hat. Ein weiterer Nachteil ist, dass es grundlegende Ordner für die Aufgabenkategorisierung bietet. Es wird beispielsweise schwierig sein, Trello für Scrum zu verwenden, da Sie nur eingeschränkten Zugriff auf Ordner haben und es keine Unterordner gibt. Du kannst jedoch auf mehrere User Stories zugreifen, um Arbeitsabläufe für einfache Projekte zu optimieren.

    Trotz dieser Nachteile bietet Trello dank des Butler-Roboters eine Workflow-Automatisierung. Mit dieser kleinen Roboterfunktion können Sie bestimmte Regeln und Kalender-Trigger festlegen, sodass Sie sich wiederholende Aufgaben automatisieren können. Trello eignet sich wahrscheinlich besser für Startups oder die Verfolgung des Fortschritts, wenn Sie eine kleine Vertriebsmannschaft haben.

    Da die Trello-Plattform einfach (aber intuitiv) ist, ist die Zusammenarbeit im Team praktisch. Die Kommunikation über Trello ist auch benutzerfreundlich und hilft den Produktteams, sofort zu sehen, wer was tut und welche Aufgaben zu erledigen sind.

    Trello verwendet standardmäßig die Kanban-Methode, du kannst sie aber auch für andere Projekttypen verwenden.

    Es gibt mehrere Funktionen, auf die du dich bei Trello freuen kannst, darunter:

    • Priorisierung von Aufgaben
    • Termine verfolgen
    • Gantt-Diagramme
    • Kanban-Tafel
    • Tools für agile Teamzusammenarbeit
    • Ressourcen- und Aufgabenmanagement
    • Automatisierung von Arbeitsabläufen
    • Den Fortschritt der Teammitglieder verfolgen
    • Verschiedene Vorlagen

    Trello hat einen kostenlosen Plan, bei dem Produktmanager bis zu 10 Boards für jedes ihrer Teams verwenden können. Du kannst den Schmerzplan auch auf jährlicher Basis erwerben, was etwa 10$ pro Benutzer kostet.

    3. Wrike

    Wrike ist sowohl ein Tool zur Rationalisierung von Arbeitsabläufen als auch zur Verwaltung der Produktentwicklung. Wrike ist flexibel, anpassungsfähig und dynamisch und ein Tool, das für bessere Produktentscheidungen entwickelt wurde.

    Sie können es für das Management kleiner Produkte, für die Verwaltung einzelner Kunden oder als unternehmensweites Tool für das Produktmanagement verwenden. Wrike ist auch vielseitig genug, um es in der Softwareproduktentwicklung oder im Marketing einzusetzen. Diese Plattform verfügt auch über ein spezielles Tool für das Marketing, das die Verwaltung von Salesforce-Abläufen erleichtert.

    Wrike ist anpassbar, sodass Sie Gantt-Diagramme und Kanban-Boards hinzufügen können, um die Zusammenarbeit der Teammitglieder zu verbessern. Eine weitere Funktion dieser Plattform ist das Work Intelligence KI-Tool, mit dem Produktmanager das Produktrisiko automatisieren und vorhersagen können.

    Wrike funktioniert gut mit Jira, Slack, GitHub, Dropbox und mehreren anderen Tools. Sie können auch andere Integrationen anpassen, um Wrike auf Produktmanagement-Teams zuzuschneiden. Wenn Sie Software hinzufügen möchten, die diese Plattform nicht unterstützt, können Sie das tun. Sie erstellen einfach die Lösung, die Sie benötigen.

    Die wichtigsten Funktionen von Wrike sind:

    • Die Fähigkeit, Anwendungen von Drittanbietern zu integrieren
    • Seine umfassende, vielseitige API
    • Verwaltung mehrerer Vorlagenoptionen
    • Erlaubnis und Zugriffskontrolle
    • Daten importieren und exportieren
    • Integration von Tabellenkalkulationen und Tabellen
    • Komfortables Aufgabenmanagement
    • Eine Benutzeroberfläche zum Ziehen und Ablegen
    • Produktaufgaben kategorisieren und strukturieren
    • Kalender- und Zeitleistensteuerung
    • Verwaltung von Dateien und Dokumenten
    • Aktivitäten und Fortschritte verfolgen
    • Filterung von Daten
    • Statistiken und Berichterstattung
    • Gemeinsamer oder öffentlicher Arbeitsbereich

    Wrike bietet einen kostenlosen Tarif für die Nutzung einfacher Funktionen an. Sie müssen jedoch für jeden Benutzer etwa 9,80 USD pro Monat bezahlen, um auf komplexere Funktionen zugreifen zu können.

    4. Produktboard

    Productboard steht mit Unternehmen wie Zendesk ganz oben. Es bietet eine der besten Funktionen zum Sammeln von Benutzerfeedback. Wie jedes Softwareentwicklungsteam weiß, kann das Feedback der Benutzer über den Erfolg eines Produkts entscheiden oder ihn zum Scheitern bringen. Mit diesem Produkt können Sie Kundenfeedback kategorisieren, in wertvolle Informationen umwandeln und dieses Feedback priorisieren.

    Mit Productboard können Sie ihr Feedback während des Lebenszyklus jedes Produkts über ein Portal verfolgen. Dieses Portal unterstützt den Ideenaustausch und das Management. Diese Informationen nutzen die Teammitglieder als Input, um den Produktwert zu steigern. Dieses Software-Tool eignet sich auch hervorragend zum Sammeln Anwendungsfälle und das Nutzerverhalten zu verstehen, um die richtigen Produkte für Kunden zu entwickeln.

    Sie können Slack und E-Mail mit dem Productboard verwenden, aber wenn Sie eine zusätzliche Softwareintegration wünschen, müssen Sie dies selbst arrangieren. Zum Glück ist die API in diesem Produkt benutzerfreundlich, um dies zu ermöglichen.

    Zu den Hauptfunktionen von Productboard gehören:

    • Lagerhäuser für Produktfeedback
    • Kundensegmente, die besonders dynamisch sind
    • Die Fähigkeit, Kundenfeedback zu priorisieren und zu kategorisieren
    • Feedback in wertvolle Erkenntnisse umwandeln
    • Ein leistungsstarkes System zur Wertbewertung
    • Roadmapping-Tools, die Sie anpassen können
    • Priorisierung von Aufgaben

    Sie können einen jährlichen Productboard-Basisplan für etwa 20 USD pro Monat für jeden Benutzer erwerben.

    5. ProdPad

    ProdPad berücksichtigt die Benutzererfahrung. Es verfügt über eine schlanke Roadmapping-Funktion, mit der Sie Ziele und Vorgaben hervorheben können. Sie können mit diesem Produktsoftwaretool experimentieren, um Benutzerfeedback in die Produktentwicklung einzubeziehen. ProdPad ist auch als eines der besten Produktmanagement-Softwaretools auf dem Markt bekannt.

    Die Produkt-Roadmap-Tools sind einfach zu verwenden und enthalten eine Farbcodierung für das Roadmapping. ProdPad verfügt über eine einfache Drag-and-Drop-Funktion sowie Datenschutzeinstellungen, und Sie können die Prioritätsprüfpunkte nach Bedarf verwenden.

    Entwicklungsteams können auf eine Funktion zur Ideenverwaltung zugreifen, um Prioritätsdiagramme zu erstellen. Hier können sie sehen, wie Rückstände die Wirkungs- und Aufwandsdiagramme in Workflows beeinflussen. Sie können auch einfach Daten aus anderen Quellen importieren, um bei Bedarf die Entwicklung neuer Produkte voranzutreiben.

    Eine weitere Funktion, die ProdPad auszeichnet, ist die Fähigkeit der Teammitglieder, Zusammenhänge zwischen Benutzerideen und Produktentwicklung zu erkennen. Sie können auch Kundenlisten erstellen, um weitere Fragen zu ihren Produkterfahrungen zu stellen.

    Sie können Anwendungsfälle sammeln und das Nutzerverhalten besser verstehen. All diese Informationen können Sie dann als Input für die Entwicklung neuer Produkte verwenden.

    Funktionen, die Sie von diesem Produktmanagement-Tool erwarten können, sind:

    • Ideengenerierung und Erfassung
    • Erfassung und Speicherung von Kundenfeedback
    • Integration mit Apps, die Kundenfeedback unterstützen
    • Integration mit anderen Apps von Drittanbietern
    • Prioritätenliste der Ideen
    • Lean Produkt-Roadmaps
    • Auf Zielsetzungen basierendes Produkt-Roadmapping
    • Erstellung von Kundenportfolios

    Sie können den Essential Plan von ProdPad für etwa 149 USD pro Monat für die jährliche Abrechnung erwerben. Mit diesem Plan können Sie drei Administratoren oder Redakteure für die Produktplanung verwenden.

    6. Asana

    Asana ist auch eine nützliche Verwaltungsplattform. Sie können es als Lösung für die Planung von Arbeitsabläufen verwenden. Asana ist bei kleinen Unternehmensgründungen und größeren Unternehmen beliebt.

    Diese Verwaltungslösung ist cloudbasiert. Sie ermöglicht es Teammitgliedern, ihren Arbeitsbereich gemeinsam zu nutzen und Aufgaben und Arbeitsfortschritte zuzuweisen und zu verfolgen. Asana ist auch eine hervorragende Plattform für die Zusammenarbeit von Teammitgliedern.

    Mit Asana erhalten Sie nicht viel Kundensupport. Und obwohl Asana nicht ideal für ein komplexes Teammanagement ist, bietet es viele nützliche Funktionen, von denen einige Folgendes beinhalten:

    • Exzellente Kommunikation und Zusammenarbeit im Team
    • Ideal, um detaillierte Ziele zu skizzieren
    • Effizient für die Verwaltung mehrerer Aufgaben und Teammitglieder
    • Ein benutzerfreundliches Dashboard
    • Verfolgung von Meilensteinen
    • Automatisierung
    • Option für mehrere Vorlagen
    • Funktionen zur Projektplanung
    • Mehrere Analyse- und Berichtsoptionen
    • Verwaltung von Ressourcen
    • Zeit- und Kostenerfassung

    Asana hat einen kostenlosen Tarif, wenn Sie mit eingeschränkten Funktionen zurechtkommen. Bezahlte Tarife beginnen bei etwa 10,99 USD pro Monat für jeden Benutzer. Das Unternehmen stellt jährlich Rechnungen ab.

    7. SEGELFLUGZEUG

    Es gibt mehrere Verwaltungslösungen zur Rationalisierung von Produktabläufen. GLIDR bietet eine weitere Plattform, von der aus die Entwicklungsziele für Produktsoftware erreicht werden können. Sie können detaillierte Produktpläne entwickeln, die den Kundenerwartungen entsprechen. GLIDR hebt das Kundenerlebnis hervor und stellt daher deren Feedback in den Vordergrund, um die besten Produktleistungen zu erzielen.

    Auf dieser Plattform können Sie Produktrecherchen, Anwendungsfälle und Nutzerverhalten verwalten. Anschließend können Sie Produktspezifikationen erstellen, Ideen verknüpfen und realisierbare Ideen erstellen Anwenderberichte, priorisieren Sie Funktionen und vieles mehr.

    GLIDR bietet verschiedene Board-View-Optionen, die Softwareentwicklern helfen, Themen aus Ideen zu erstellen. Sie können Ideen auch nach ihrem Status kategorisieren, Zeitleisten ausfüllen oder diese Ideen auf Kanban-Boards zeigen.

    Zu den weiteren hilfreichen Funktionen gehört die Möglichkeit, Apps wie Intercom und Zendesk in GLIDR zu integrieren. Sie können Jira und Trello auch mit dieser Produktverwaltungssoftware verknüpfen.

    Produktmanager und Teams können GLIDR verwenden, um ihre Arbeitsabläufe zu optimieren, den Produktfortschritt zu verfolgen, Berichte zu erstellen und Roadmaps in die bestmöglichen Produkte umzuwandeln.

    Zu den Hauptfunktionen von GLIDR gehören:

    • Produktwerbeanzeigen
    • Öffentliche Straßenkartierung
    • Optionen für Forschung und Experimente
    • Trendergebnisse zur Einstufung von Ideen
    • Priorisierung von Funktionen
    • Aktivitäts-Feeds
    • Fortschrittsverfolgung und Überwachung
    • Benutzerfreundliche Dashboards
    • Berichte, die Sie im PDF-Format exportieren können

    Du kannst GLIDR 14 Tage lang kostenlos testen. Dann kostet die günstigste Option etwa 8 USD pro Person und Monat für ein Team von fünf Personen. GLIDR stellt jährlich Rechnungen ab und bietet drei weitere Tarifoptionen, mit denen Sie auf weitere Funktionen zugreifen können.

    Verbessern Sie Ihr Spiel mit Easy Agile

    Eine Möglichkeit, Ihre Produktmanagement-Software zu verbessern, besteht darin, die Ressourcen von Easy Agile zu nutzen. Sie können entweder unsere Jira-Apps verwenden, um sie in bestehende Produktmanagement-Plattformen zu integrieren, oder Ihrem bestehenden System einen Schub geben.

    Wählen Sie aus Apps für Kanban-Arbeitsablauf für Jira oder steigern Sie die Leistung der Produktentwicklung mit Story-Maps von Benutzern für Jira.

    Verbessern Sie Ihr Spiel mit Easy Agile Straßenkarten für Jira, um dein Team zum Produkterfolg zu führen, oder nutze unsere Programme für Jira für Program Increment Planning.

    Welche Apps du auch wählst (alle?) , können Sie das Produktteammanagement mit der besten verfügbaren Produktmanagementsoftware verbessern.