Workflow

Bei Agile geht es darum, Teams zu befähigen, Verantwortung zu übernehmen, sich wirklich engagiert zu fühlen und eine Kultur der Zusammenarbeit zu fördern. Mehr denn je müssen Teams ihre Aufgaben mit größerer Anpassungsfähigkeit, Geschwindigkeit und Engagement erfüllen. Die Zukunft ist vieldeutiger und komplexer, und agile Teams müssen wissen, wie sie am besten auf diese sich ändernden Bedingungen reagieren können.

Die Agile-Experten John Walpole, Dean MacNeil und Nick Muldoon teilen ihre Erfolgsformel hinter den hochfunktionellen Agile-Teams von Lyft, Valiantys und Easy Agile. Sie werden lernen:

• Wie man ein überzeugendes „Warum“ schafft, hinter dem das gesamte Team stehen kann
• So stärken Sie Ihre Teams
• Die Eigenschaften leistungsstarker Agile-Teams

JETZT ANSEHEN

Schaffen Sie ein überzeugendes „Warum“, hinter dem das gesamte Team stehen kann

‍

Ich denke, Agile ist keine Wunderwaffe. Wir haben Leute, die sich Agile ansehen und sagen: „Oh, nun, das wird all unsere Probleme lösen.“ Und das ist es nicht; es ist sicherlich keine schlüsselfertige Sache.

Nick Muldoon, Co-CEO bei Easy Agile

Agile ist keine Wunderwaffe. Es ist keine Methode, die die Probleme von Führungskräften, Teams und Einzelpersonen löst. Agile bedeutet „in der Evolutionstheorie eine kontinuierliche Verbesserung der Anpassungsfähigkeit; es geht darum, entweder auf eine neue Umgebung oder Veränderungen in der eigenen Umgebung zu reagieren, um nicht nur zu überleben, sondern zu gedeihen“, so Dean.

Bereiten Sie Ihre Agile-Teams auf Erfolgskurs, indem Sie ihnen beibringen, erfolgreich zu sein, indem Sie sie befähigen, Veränderungen anzuführen, Fehler zu machen, eine solide Grundlage aufzubauen und offen dafür zu sein, zu lernen, sich zu verändern und das aussagekräftige „Warum“ hinter ihrer Arbeit zu kommunizieren. Sie werden eine explosionsartige Steigerung des Erfolgs agiler Teams erleben, wenn Sie ein „kohärentes Team haben, das auf eine gemeinsame Mission ausgerichtet ist und eine wachstumsorientierte Denkweise verfolgt“.

Motivieren Sie Ihre Agile-Teams, indem Sie ihre Arbeit mit einem aussagekräftigen „Warum“ verknüpfen. Vereinbaren Sie ein Meeting, um sicherzustellen, dass Sie den tieferen Zweck ihrer Arbeit ständig besprechen. Bringen Sie ein Kundenbeispiel aus der Praxis vor. John erzählte: „Bei Lyft tauschen wir in einem vierzehntägigen Meeting Geschichten aus. Wir bieten kostenlose, barrierefreie Fahrten für Rollstuhlfahrer oder Personen an, die Schwierigkeiten haben, eine Fahrt zu bezahlen, aber Zugang zu öffentlichen Verkehrsmitteln benötigen, um zur Arbeit oder zur Schule zu gelangen.

„Erwecken Sie Ihre Personas mit diesen Beispielen aus der Praxis zum Leben, sodass sie in den Köpfen Ihrer Mitarbeiter im Mittelpunkt stehen“, sagte John.

‍

Stärken Sie Ihre Teams

Kultur isst — Strategie fürs Frühstück

Pieter Drucker

Ihre Mitarbeiter müssen den Wandel leiten. „Wenn Sie sich großartige Führungskräfte der jüngsten Agile-Transformation ansehen, sollten Sie sich vielleicht ein Unternehmen wie Porsche ansehen“, sagte Dean. Dean erzählt, wie Porsche Valiantys inspiriert hat, weil „jeder Mitarbeiter bei Porsche den Wandel anführt. Sie sind also alle davon überzeugt; sie alle haben diesen Sinn für Führung, um ihn voranzutreiben.“. Die Mitarbeiter von Porsche führen den Wandel an, weil ihre Führung das „Warum“ gut kommuniziert. „Spaß steht an erster Stelle, wenn ihr CIO die drei wichtigsten Gründe auflistet, warum alle so begeistert von der Agile-Transformation sind. Weil Sie bei der Arbeit Spaß haben können, sollte Ihr Job keine harte Pflicht sein. Es sollte etwas sein, auf das du dich freust.“

„Ermöglichen Sie Ihren Teams, Fehler zu machen“, sagte John.

Ermöglichen Sie Ihren Agile-Teams mithilfe aussagekräftiger Fragen, zu scheitern und Fehler zu machen. Führungskräfte müssen ihren Umgangston von „Oh nein, wen feuere ich?“ ändern zu „Was ist die Herausforderung? Was kann ich tun, um zu helfen?“ Erklären Sie Ihrem Team, dass Sie auf einer Reise sind, um genauso viel zu lernen wie sie. Auf diese Weise humanisiert sich der Anführer selbst und wird anfälliger.

Führung gibt den Ton an. Wenn ein Unternehmen skaliert, fallen die Verantwortung für die Schaffung der Unternehmenskultur und die Risikobereitschaft immer mehr auf die Führung.

Eigenschaften leistungsstarker, agiler Teams

1. Schaffen Sie ein solides Fundament

Bringen Sie Ihr Agile-Team mit einer stabilen Teameinheit auf Erfolgskurs. Verschieben Sie Teams nicht ständig, sondern stellen Sie langfristige agile Teams zusammen, damit sich die einzelnen Personen kennenlernen und sich gegenseitig humanisieren können. „Ich denke, Stabilität ist der Schlüssel dazu, dass das implizite Wissen zusammenhält, und diese offene Denkweise, in der sie bereit sind zu lernen. Das finde ich toll“, sagte Nick.

2. Offen für Lernen und Anpassung

Damit sich agile Teams kontinuierlich verbessern können, müssen sie ständig lernen und sich anpassen. „Man kann dieses Lernen und die Anpassung nicht erreichen, wenn man ständig umrührt. Weil Sie dieses Wissen immer weiter streuen werden, wollen Sie es in die Hand nehmen, und dann wollen Sie das Wissen natürlich an die Organisation weitergeben „, sagte Dean.

3. Teilen Sie Feedback mit und machen Sie einen Rückblick

Stellen Sie sicher, dass Ihre Agile-Teams regelmäßig funktionierende Produkte vorführen. Wenn Sie Scrum praktizieren, stellen Sie sicher, dass Sie den wöchentlichen Sprint-Review durchführen. Auf diese Weise kann das Team Feedback von den Stakeholdern erhalten und ständig wiederholen und vorankommen, um sicherzustellen, dass sie in Bewegung bleiben. „Machen Sie Ihren Rückblick“, sagte Dean.“ Wir schauen uns an, was wir geliefert haben, und jetzt schauen wir uns an, wie wir es geliefert haben.“ Es ist unerlässlich, dass sich die Scrum-Teams am Ende jedes Sprints treffen, um zu besprechen, was gut gelaufen ist, was nicht so gut gelaufen ist und was beim nächsten Mal verbessert werden kann. Andernfalls laden Sie Selbstgefälligkeit und Stagnation in Ihren Scrum-Prozess ein — das Gegenteil von Agile.

Verwenden Sie Easy Agile, um Ihre Agile-Teams auf Erfolgskurs zu bringen

Einfacher agiler Teamrhythmus unterstützt die Agile-Praktiken deines Teams in Jira. Das User-Story-Map-Format in TeamRhythm verwandelt Ihre flachen Produktlandkarten in eine dynamische und flexible visuelle Darstellung der Arbeit. Schauen Sie sich das an Höhepunkttour um zu sehen, wie Easy Agile TeamRhythm die Sprint-Planung, die Verwaltung Ihres Backlogs und Team-Retrospektiven einfacher macht. Besuche den Atlassian Marketplace und starte dein kostenloses, 30-Tage-Testversion heute.

‍

„Die Leute, die die Arbeit planen, machen die Arbeit“ ist der ungeschriebene Regel des Scaled Agile Framework.

Dies kann jedoch leichter gesagt als getan sein, wenn wir es mit mehreren Teams von Personen zu tun haben, die gemeinsam planen müssen.

Rechnet man die Komplexität großer Unternehmen hinzu, die vor ihren ganz eigenen Herausforderungen stehen — von der Produktentwicklung über das Budget bis hin zur Umsetzung des Feedbacks bis hin zur endgültigen Auslieferung —, kann sich plötzlich die Idee, Teams für die Planung zusammenzubringen, wieder schwieriger anfühlen.

Wenn Sie mit dem Scaled Agile Framework vertraut sind, wissen Sie bereits, dass SAFe darauf ausgelegt ist, eine bessere Zusammenarbeit und Kommunikation zwischen mehreren funktionsübergreifenden Gruppen zu ermöglichen. Die zentrale Methode, dies mit SAFe zu tun, ist Program Increment oder PI Planning (Planning Interval Planning in SAFe 6.0)

Ein Plan kann so viele verschiedene Formen annehmen — auch nur zwischen Teams —, aber mit SAFe ist es einfacher zu erkennen, wie „gut“ aussieht, wenn es um effiziente PI-Planung geht.

Das SAFe-Programmboard oder ART-Planungstafel (SAFe 6.0), ist ein wichtiges Tool und Ergebnis von PI Planning. Es ist ein visuelle Zusammenfassung von Funktionen oder Zielen, teamübergreifenden Abhängigkeiten und anderen Faktoren, die sich auf deren Bereitstellung auswirken. Dies trägt nicht nur zur Transparenz bei, sondern erhöht auch die Flexibilität, was wiederum dazu beiträgt, Verzögerungen und schädliche Abhängigkeiten zu minimieren.

Was oft übersehen wird, ist, dass PI Planning eine entscheidende Rolle dabei spielt, Teams oder das gesamte Programm auf Erfolgskurs zu bringen — einschließlich der Durchführung anderer SAFe-Zeremonien oder -Veranstaltungen.

In diesem Artikel besprechen wir alles, was Sie über Programmboards wissen müssen, einschließlich der Gründe, warum sie im Planungsprozess wichtig sind und wie größere Teams sie in PI Planning und darüber hinaus verwenden können.

Wir werden auch genau untersuchen, wie Easy Agile Programs das SAFe-Programmboard digitalisiert. So können nicht nur die Leute, die die Arbeit planen, die Arbeit erledigen, sondern Sie können die Arbeit auch in der Umgebung planen, in der die Arbeit erledigt wird — in Jira.

Hinweis: Während das Programmboard in der aktualisierten 6.0-Version des Scaled Agile Framework als „ART Planning Board“ bezeichnet wird, ist es dasselbe Artefakt und spielt dieselbe Rolle in PI Planning und darüber hinaus.

Was ist ein Programmboard?

Wie sieht der Plan oder der Zeitplan Ihres Teams in der Regel aus?

Würde es Ihnen zeigen, welche Arbeit geleistet wurde? Wer hat es gemacht? Vielleicht sogar ein Hinweis darauf, wann und auf welche wichtigen Termine diese Teams hinarbeiten?

Die Überschrift hier ist, dass ein Programmboard all das ist, aber auch mehr.

Die Programmtafel visualisiert die Arbeit, die während des Program Increment/Planning Interval (PI) geleistet wird. Es ist gleichzeitig der Vermittler der Planung und des Plans selbst.

Eine typische Vorstellung von einer Programmplatine — insbesondere für gemeinsame PI-Planungssitzungen — ist buchstäblich eine physische Platine an einer Wand.
Es würde zeigen:

• Spalten: Markierung der Wiederholungen für das Inkrement
• Zeilen: stehen für verschiedene Teams innerhalb dieses Zuwachses
• Haftnotizen: Beschreibung der Eigenschaften an dem die Teams arbeiten oder an denen sie angezeigt werden Meilensteine auf die sie hinarbeiten
• Zeichenketten: zwischen diesen Merkmalen, um anzuzeigen, ob es welche gibt Abhängigkeiten

Aber wie unterstützt ein Programmboard den Planungsprozess?

Ein Programmboard ermöglicht eine bessere Teamzusammenarbeit, da es die Projektkommunikation und -planung optimiert und gleichzeitig eine bessere Kommunikation zwischen den beteiligten Teams gewährleistet.

Darüber hinaus helfen Programmausschüsse dabei, die Verantwortung jedes Teams zu definieren, das an der Umsetzung der Idee beteiligt ist, was wiederum dazu beiträgt, den gesamten Prozess zu rationalisieren.

Während der PI-Planung unterstützt das Programmboard die Teams dabei, Abhängigkeiten innerhalb des PI zu visualisieren und zu verwalten. So erhalten sie mehr Klarheit über die Arbeit im Detail, wie die Arbeit mit dem, was das Unternehmen zu erreichen versucht, und zueinander, welche Aufgaben erledigt werden müssen und vor allem, ob es irgendwelche Probleme gibt, die zu Verzögerungen führen können.

Ein Programmausschuss ist gleichzeitig der Moderator der Planung und des Plans selbst.

Um zu verstehen, wie Programmtafeln beim Planungsprozess helfen, schauen wir uns die verschiedenen Komponenten an, die auf ihnen zu finden sind.

So richten Sie Ihr SAFe-Programmboard für eine erfolgreiche PI-Planung ein

Laut Agiles Skalieren, es gibt zwei Hauptausgaben von PI Planning:

1. Engagiert PI-Ziele
2. Programmtafel - mit Lieferterminen für neue Funktionen, Abhängigkeiten zwischen Teams und relevanten Meilensteinen

Wenn Sie also SAFe folgen und PI Planning durchführen, sollten Sie PI Planning mit einer Programmplatine beenden.

Während der PI-Planung besprechen und definieren die Teams nicht nur die Funktionen und Abhängigkeiten, sondern sie legen auch Meilensteine für den gesamten PI fest.

Hier ist ein digitalisiertes PI-Planungstool kann wirklich profitieren Remote- oder Hybrid-Teams, die PI-Planung durchführen - Die gleichen Informationen sind am selben Ort geplant.

Hier sind ein paar Tipps, die Ihnen bei der Erstellung eines SAFe-Programmboards helfen sollen.

1. Das Board selbst einrichten

Nicht zu unterschätzen, das Grundgerüst des Programmboards muss eingerichtet werden.

Hier gibt es zwei wichtige Elemente:

• Spalten für Sprint oder Iteration:
  • Die richtige Zahl hängt davon ab, wie viele Iterationen/Sprints in Ihrem PI enthalten sein werden, einschließlich einer letzten für Iterationsplanung
• Reihen oder Schwimmbahnen:
  • Einer für Meilensteine/Ereignisse — in der Regel der erste
  • Eine für jedes Team
  • Kann auch eine Swimlane für gemeinsam genutzte Dienste, Lieferanten oder andere Teams haben, die nicht in der Agile Release Train (ART)

So könnte das aussehen:

Wenn Sie sich in dieser Phase Ihres Programms befanden, sollten Sie Einfache agile Programme, dein Board würde so aussehen:

In Easy Agile-Programmen steht jedes Team, das in einer eigenen Swimlane vertreten ist, für ein agiles Board in Jira. Die Probleme, die du während der PI-Planung und darüber hinaus in Sprints für dieses Team einplanst, spiegeln sich also auf dem Agile Board wider und umgekehrt.

Das Start- und Enddatum für den PI sowie die Anzahl und Länge deiner Sprints können alle bearbeitet werden um zu den Arbeitsabläufen Ihres Unternehmens zu passen.

Wenn Sie sich im Bearbeitungsmodus befinden und Features planen möchten, wird die Swimlane für gemeinsam genutzte Teamfunktionen ebenfalls oben angezeigt, um visuell anzuzeigen, ob Arbeiten für mehrere Teams geplant werden müssen.

2. Beginnen Sie mit Funktionen und Meilensteinen

Während der PI-Planung teilt das Produktmanagement die Produkt-/Lösungsvision mit. Dies bedeutet in der Regel auch die nächsten 10 bevorstehenden Funktionen, die die Teams aus dem Backlog in die PI aufnehmen müssen. (Wir wissen von unseren Kunden, dass das manchmal viel mehr sein kann!)

Wir möchten auch zunächst wissen, auf welche Meilensteine wir hinarbeiten. Oft können dies Produktveröffentlichungstermine, externe Leistungen oder Termine wie die Vorbereitung einer Demo oder Präsentation für eine Messe, Marketingeinführungen oder Veranstaltungen sein. Wenn diese auf der Programmtafel visualisiert sind, können die Teams leicht erkennen, worauf sie hinarbeiten, aber auch, um die Priorisierung der spezifischen Funktionen zu unterstützen, die zur Erreichung dieses Meilensteins erforderlich sind.

Wenn Sie mit einer physischen oder einfachen digitalen Programmtafel arbeiten, werden Funktionen und Meilensteine durch „Haftnotizen“ dargestellt, die in der entsprechenden Swimlane und/oder Farbe platziert sind, um diese Informationen sowie das dafür verantwortliche Team und den Zeitrahmen anzugeben:

Wie sieht das in Easy Agile Programs derzeit aus?

Meilensteine sind sehr visuell

• Meilensteine kann individuell angepasst werden, um Start-/Enddatum und Farbe anzuzeigen. Sie erstrecken sich über alle Team-Swimlanes, sodass die Teams leicht erkennen können, wie ihre Arbeit mit einem bevorstehenden Ergebnis oder einer bevorstehenden Veranstaltung zusammenhängt.
• Meilensteine habe immer noch einen eigenen Platz oben auf der Programmtafel, aber dieser kann auf Wunsch zusammengeklappt werden

Funktionen sind native Jira-Probleme

• Funktionen in Easy Agile-Programmen sind native Jira-Probleme, in der Regel epische. Sie können ganz einfach auf der Programmpinnwand auf den Problemschlüssel klicken, um in der Problemansicht weitere Informationen zu erhalten.
• Funktionen können einfach geplant werden aus dem Backlog per Drag & Drop in eine Swimlane oder über das Programmboard erstellt. Um anzugeben, wann ein Feature gestartet und abgeschlossen werden soll, ziehen Sie einfach den Rand des Vorgangs per Drag-and-Drop:

Nehmen Sie an einer Produkttour teil und lernen Sie die Easy Agile-Programme kennen

Du möchtest dein Program Board in Jira integrieren?

Nehmen Sie an einer Demo teil

3. Identifizieren Sie Abhängigkeiten

Nachdem die Funktionen fertig sind, sollten Teams als Nächstes nach Abhängigkeiten suchen. Erinnerst du dich an die Zeichenketten, die wir zuvor erwähnt haben?

Abhängigkeiten zwischen Features und Teams werden mit einer Schnur auf einer Programmtafel dargestellt, wenn sie sich an einer Wand befindet, oder mit Linien zwischen diesen Funktionen in einem digitalen Tool.

Haftnotizen in einer anderen Farbe, wie Rot, weisen auf eine signifikante Abhängigkeit hin. Beispielsweise kann es für diese Funktion mehrere Funktionen geben, auf die sie angewiesen ist, um den Zeitplan einzuhalten.

Um dies zu erklären, betrachten wir ein Beispiel.

Stellen Sie sich vor, Team X erkennt, dass es ein Feature erst entwickeln kann, wenn Team Y dank des Programmboards eine API entwickelt. Was also beide Teams tun können, ist miteinander zu sprechen und eine Lösung zu finden, die für alle funktioniert und zu einer besseren Zusammenarbeit zwischen den Teams führt.

Nachdem eine Einigung erzielt wurde, wird eine Abhängigkeit in den Vorstand aufgenommen, sodass alle das gleiche Verständnis über die Abhängigkeit haben und wie sie gelöst werden kann. Um dies zu demonstrieren, wird an jeder Karte ein Stück Schnur befestigt:

Die Natur der Abhängigkeiten bedeutet, dass etwas abgeschlossen werden muss, damit etwas anderes getan werden kann.

Um leichter erkennen zu können, wann Abhängigkeiten geplant sind, verfügt Easy Agile Programs über ein Ampelsystem mit roten, orangefarbenen und grünen Abhängigkeiten, um den Zustand der Abhängigkeiten anzuzeigen.

Die Gesundheit der Abhängigkeit wird wie folgt dargestellt:

• EIN rot Zeile gibt an, dass das abhängige Problem in einem Sprint nach der Abhängigkeit geplant ist (Konflikt)
• Ein orange Eine Zeile gibt an, dass die Abhängigkeit und die Abhängigkeit im selben Sprint geplant sind (ein Risiko)
• EIN grün Die Zeile gibt an, dass das abhängige Problem in einem Sprint vor seiner Abhängigkeit geplant ist (fehlerfrei)
• EIN schwarz Eine Zeile gibt an, dass die Abhängigkeit mit Problemen außerhalb der aktuellen Ansicht besteht. Unabhängig davon, ob es sich um das aktuelle Agile Release Train /-Programm handelt oder ob es sich um eine zukünftige oder vergangene Erhöhung handelt.

Dies zeigt einem Release Train Engineer oder einem Program Manager leicht, worauf sie sich konzentrieren sollten, um alle Planungsprobleme während der Planung lösen zu können.

Mit Easy Agile Programs können Sie auch Abhängigkeiten zwischen Problemen innerhalb und zwischen Teams aus den Teamplanungstafel. Dies bietet einen wirklich fokussierten Überblick über die Arbeit eines bestimmten Teams für den PI und wie diese Arbeit mit anderen Teams zusammenhängt:

Für eine bessere Zusammenarbeit werden Programmboards benötigt

Die Stärke des Programmausschusses liegt darin, einen einheitlichen Überblick darüber zu haben, wofür sich eine Gruppe von Teams — gemeinsam — verpflichtet hat und wie genau diese Arbeit miteinander zusammenhängt. Es hilft bei der Organisation von Planungssitzungen, indem es zukünftige Abhängigkeiten aller Teams und Sprints zusammenfasst. Auf diese Weise können Scrum Master, Release Train-Techniker, Produktmanager und Geschäftsinhaber die wichtigsten teamübergreifenden Konversationen leicht identifizieren und priorisieren.

Eine groß angelegte Planungssitzung oder eine PI-Planungszeremonie durchzuführen, insbesondere zum ersten Mal, kann entmutigend sein.

Wenn es Ihnen jedoch gelingt, im Rahmen Ihres PI-Planungsprozesses ein solides Programmboard zu entwickeln, müssen Sie sich keine Gedanken darüber machen, Ihren Kollegen oder Teammitglied zu verfolgen, um Termine einzuhalten. Das Wichtigste dabei ist, sicherzustellen, dass Sie die wichtigsten Funktionen für den PI geplant, teamübergreifende Abhängigkeiten identifiziert und alle Meilensteine oder Termine visualisiert haben, um sicherzustellen, dass sie realistisch erreicht werden können.

Das Programmboard kann jedoch wirkungsvoller werden, wenn es mehr als nur ein Plan ist. Das Erstellen einer Programmtafel in einem Online-Tool mit der zusätzlichen Funktion, dass sie die tatsächliche Arbeit darstellt, die zu erledigen ist, bedeutet, dass es ein Leben hat, das über PI Planning hinausgeht. Es wird zum lebendigen Dokument der Fortschritte des Teams und ein Mittel, um festzustellen, ob es Hindernisse gibt, die diesen Fortschritt behindern.

Damit agile Teams agil sind und kontinuierlich und iterativ Mehrwert liefern können, müssen sie mit einem Programmboard ausgestattet sein, das ihnen hilft, auf Änderungen zu reagieren, sodass sie den Erfolg planen, aber auch Fortschritte machen können.

Bist du bereit, dein Program Board von der Wand zu nehmen und in Jira zu integrieren?

Mit Easy Agile Programs ist das möglich

VERSUCHE ES JETZT

‍

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu vermitteln, sind persönliche Gespräche.

Agiles Manifest, 2001

So wahr diese Aussage auch war, als sie verfasst wurde, die Covid-19-Pandemie hat die Art und Weise, wie wir arbeiten, leben und kommunizieren, unwiderruflich verändert.

Als Organisationen und Einzelpersonen mussten wir uns schnell an ein sich ständig veränderndes Umfeld anpassen. Jetzt, wo wir überlebt haben, müssen wir uns an diese neue Art und Weise gewöhnen, Dinge am Arbeitsplatz zu erledigen, damit wir erfolgreich sein können.

Aber was ist mit unseren agilen Zeremonien?

Einer der Hauptgründe, warum Unternehmen auf Agile umsteigen, ist die effizientere Gestaltung von Geschäftsprozessen und Ergebnissen. Wie können wir also diese Prinzipien und Praktiken nutzen und ihre Integrität in einer entfernten Umgebung bewahren?

Wenn Sie mit dem vertraut sind Skaliertes Agile-Framework, das wirst du wissen PI-Planung ist eine agile Zeremonie, die im Mittelpunkt der Implementierung von SAFe steht.

Bei PI Planning handelt es sich traditionell um eine teamübergreifende Planungszeremonie, die darauf abzielt, mehrere Teams zur Planung zusammenzubringen und sie auf eine gemeinsame Mission und Vision für das kommende Quartal oder Inkrement auszurichten.

SAFe weist immer noch darauf hin, dass PI Planning nach Möglichkeit weiterhin gemeinsam genutzt wird, und das hat seine Vorteile.

Viele Teams nutzten jedoch schon vor der Pandemie die PI Planning-Software, um ihren Planungsprozess durchzuführen und ihn für verteilte PI-Planungen effizienter und zugänglicher zu machen. Aber wie bei den meisten Dingen, die wir seit Covid online gestellt haben, sind wir den Tools ausgeliefert, mit denen wir feststellen, wie effektiv wir sein können.

Die Wahrheit ist, es sei denn, Sie können alle Mitglieder innerhalb einer Agiler Release-Zug - Geschäftsinhaber, Stakeholder, Produktmanagement, Release Train Engineers, Scrum Master und Teams — physisch in einem Raum zur gleichen Zeit, wobei Alternativen in Betracht gezogen werden müssen.

Es ist wichtig, dass alle während der PI-Planung anwesend sind, aber das bedeutet nicht, dass sie physisch anwesend sein müssen, um PI Planning zum Erfolg zu führen.

PI-Planung aus der Ferne mit einfachen Agile-Programmen

Wir haben jetzt die Zeit überschritten, in der wir uns an die Telearbeit anpassen mussten. Unsere eigene geschäftliche Agilität wurde auf die Probe gestellt und wir mussten uns weiterentwickeln.

Seit der Einführung der Easy Agile-Programme haben wir die vorhandenen Funktionen kontinuierlich ausgebaut, um Teams und Organisationen auf der ganzen Welt zu helfen, in einer Remote-Umgebung erfolgreich zu sein.

Mit einem einfaches, aber leistungsstarkes Tool, das nahtlos in Jira integriert ist, die neueste Version von Einfache agile Programme hat eine Reihe von Funktionen, die darauf abzielen, verteilten Teams bei der PI-Planungszeremonie zu helfen und ein langlebiges, aber flexibles digitales Programmboard in Jira aufzubauen.

Die Umstellung auf Remote- oder Hybrid-PI-Planung muss Ihren Erfolg oder den Ihrer Kunden nicht gefährden. Mit dem richtigen Tool kann das Unternehmen es sogar verbessern, indem es Zeit beim Kontextwechsel, komplexen Konfigurationen und doppelter Bearbeitung spart.

Die PI-Planungsagenda

Unabhängig davon, ob Sie einem weiteren folgen traditionelle 2-Tage-PI-Planung Agenda, oder müssen Platz für ein geteilte Agenda in einer verteilten Umgebung, die wichtigsten Tagesordnungspunkte sind dieselben. Wir werden Sie durch die einzelnen Funktionen führen und erläutern, wie Easy Agile Programs diese wichtigen Funktionen unterstützt.

Quelle: Scaled Agile

Festlegung des Geschäftskontextes

PI Planning beginnt damit, dass der oder die Geschäftsinhaber oder Führungskräfte eine Präsentation halten, in der sie „den aktuellen Stand des Unternehmens beschreiben, die Portfolio-Vision teilen und ihre Sichtweise darlegen, wie effektiv bestehende Lösungen die Kundenbedürfnisse erfüllen“ (Scaled Agile — PI-Planung).

Im Abschnitt Programmdetails der Easy Agile-Programme können Geschäftsinhaber eine aufgezeichnete Videopräsentation mit allen Mitgliedern des ART oder einen Zoom- oder Videokonferenzlink teilen.

Daher ist die Präsentation nicht darauf beschränkt, dass Teammitglieder zu diesem Tagesordnungspunkt physisch anwesend sind, sondern kann während der gesamten PI Planning-Sitzung und darüber hinaus abgerufen werden.

Festlegung der Produkt-/Lösungsvision

Als Nächstes wird das Produktmanagement die aktuelle Vision vorstellen, in der Regel in Form der 10 wichtigsten kommenden Funktionen.

Anstatt die 10 wichtigsten Funktionen in einer Liste auf einer Folie oder einem Dokument zu präsentieren, können Programmmanager direkt in Easy Agile Programs auf Jira Features (Epics) zugreifen und sie für die Dauer des Program Increment (PI) auf einer visuellen Zeitleiste planen.

Die Programm-Roadmap stellt sicher, dass sich alle Teams über die zugesagten Funktionen für einen PI einig sind, und bietet allen Beteiligten Einblick in die Richtung des Programms.

An diesem Punkt der PI-Planungszeremonie können die Produktmanager auch alle bevorstehenden Meilensteine bekannt geben.

Laut Agiles Skalieren, „Meilensteine markieren bestimmte Punkte auf dem Entwicklungszeitplan und können für die Messung und Überwachung der Produktentwicklung und des Risikos von unschätzbarem Wert sein.“

Einfache Agile-Programme ermöglichen es Ihnen erstellen Sie gut sichtbare Meilensteine auf der Programm-Roadmap, um wichtige Liefertermine, externe Ereignisse oder geschäftliche Meilensteine hervorzuheben. Diese können auch im Programmboard oder auf Teamebene im Teamplanungsboard erstellt werden. Sie werden durch farbige Flaggen oben auf der Roadmap dargestellt, die sich über die Team-Swimlanes erstreckt, aus denen das Programm besteht.

Team-Breakout-Sitzungen

Beim Team-Breakout arbeiten die Teams individuell daran, die Kapazität für jeden Sprint im PI abzuschätzen. Die Teams erstellen neue Probleme oder identifizieren bestehende Probleme aus ihrem Backlog, die dazu beitragen, die festgelegten Funktionen zu erreichen. Die Entwürfe der Teampläne sind für alle Mitglieder des ART sichtbar.

Um dies zu vereinfachen, hat Easy Agile Programs spezielle Teamplanungstafeln zugänglich für alle, die Zugriff auf das Programm haben. Wenn du einfach auf den Namen eines Teams klickst, gelangst du zu dessen Teamplanungstafel, wo das Team die Kapazität für jeden Sprint innerhalb des PI festlegen kann:

Teams haben den Kontext ihrer festgelegten Funktionen ganz oben in ihrer Teamplanungstafel, sowohl diejenigen, die von mehreren Teams im ART gemeinsam genutzt werden, als auch diejenigen, die spezifisch für ihr Team sind.

Um die Arbeit zu planen, die für die Umsetzung dieser Funktionen erforderlich ist, können Teams bestehende Probleme per Drag & Drop aus ihrem Backlog ziehen oder direkt in der Plantafel schnell neue Probleme erstellen.

Während dieser Sitzung erstellen die Teams auch einen Entwurf PI-Ziele. Diese sind ein wichtiger Bestandteil der Verknüpfung dessen, woran das Team gerade arbeitet, mit umfassenderen Geschäftszielen, und Sie müssen den Teamplanungsausschuss nicht verlassen, um sie zu erstellen.

In Easy Agile Programs können Sie angeben, ob das Ziel festgeschrieben ist oder nicht, eine Beschreibung bereitstellen und die zur Erreichung dieses Ziels geplanten Jira-Probleme direkt mit dem Ziel selbst verknüpfen:

Während der PI-Planung werden die Geschäftsinhaber mit den Teams über ihre PI-Ziele diskutieren, was eine unschätzbare Gelegenheit zur Abstimmung bietet. Die Teamplanung bietet das Artefakt, um diese Gespräche zu erleichtern, und ermöglicht es Geschäftsinhabern oder Interessenvertretern, direkt im Tool einen Geschäftswert zuzuweisen.

Ein wichtiger Teil der Team-Breakout-Sessions ist Identifizierung von Abhängigkeiten oder potenziellen Risiken zur Arbeitsplanung. Per Drag-and-Drop oder im Modus „Abhängigkeiten erstellen“ ist es sehr einfach, teamübergreifende Abhängigkeiten im Teamplanungsboard zu erstellen und zu visualisieren.

Abgesehen von deutlich sichtbaren Abhängigkeitslinien schätzen unsere Kunden auch die Möglichkeit, Sehen Sie sich den Zustand dieser Abhängigkeiten an. Wenn eine Abhängigkeitslinie grün ist, bedeutet das, dass die Abhängigkeit gesund ist, wenn sie orange ist, ist sie gefährdet, und wenn sie rot ist, bedeutet das, dass wir blockiert sind, d. h. die Arbeit, die erledigt werden muss, um eine frühere Arbeit zu erledigen, wird danach eingeplant.

Und das Beste von allem? Das ist für alle in der KUNST sichtbar in einem digitalisiertes SAFe-Programmboard.

Im Program Board haben wir die Möglichkeit, eine detaillierte Ansicht mit sichtbaren Problemen auf Teamebene anzuzeigen oder sie auszublenden, sodass wir nur Funktionen sehen können.

Sie fragen sich, ob Easy Agile Programs die PI-Planung Ihres Unternehmens unterstützen könnten? Mit einer nahtlosen Jira-Integration dauert die Einrichtung nur wenige Minuten.

Kostenlose Testversion von Easy Agile Programs

Versuche es jetzt

Risiken des Programms

Während der PI-Planung müssen wir in der Lage sein, Risiken und Abhängigkeiten zu identifizieren, um beurteilen zu können, ob die Teams im Agile Release Train auf Erfolgskurs sind, um ihre PI-Ziele zu erreichen.

EIN digitale Programmtafel bietet allen Mitgliedern der ART während der PI-Planung Transparenz und dient während und nach der Planung als zentrale Informationsquelle. Ein digitales Artefakt ermöglicht es dem Programmboard, mehr als nur ein Plan zu sein, und es hält länger als die Schnüre und Haftnotizen an einer physischen Wand.

Das wissen wir Visualisieren von Abhängigkeiten auf Featureebene ist entscheidend, um den Zustand oder Status eines PI nicht nur zu verstehen, sondern auch um Fehler zu beheben. Nicht nur während der PI-Planung selbst, sondern auch während der gesamten PI während der Ausführung.

Das Program Board in Easy Agile Programs ist sehr visuell und auch filterbar. Farbige Linien, die den Zustand der Abhängigkeit anzeigen, stellen sicher, dass wir auf einen Blick alle wichtigen Abhängigkeiten sehen können, die ein Risiko für unseren PI darstellen.

Zusätzlich ist unser Funktion „Planungskonflikte“ Oberflächen, wenn Arbeiten außerhalb des zugehörigen Elements geplant sind, um sofort und deutlich anzuzeigen, wo ein Risiko besteht.

Die Möglichkeit, in Easy Agile Programs nach Abhängigkeit, Zustand und Team zu filtern, hilft dabei, die Diskussionen während der PI-Planung auf Risiken zu konzentrieren.

Überarbeitung planen

Nach der Vorstellung der Pläne beim ART und der Erörterung des Umfangs, der teamübergreifenden Abhängigkeiten, der erforderlichen Ressourcen und der Risiken nehmen die Teams dann an einer Vertrauensabstimmung teil.

Bei Bedarf besteht ein abschließender Teil der Planung darin, alle Pläne zu überarbeiten, damit alle Teams innerhalb des Agile Release Train sicher sind, wozu sie sich verpflichten.

Dies kann eine Neuplanung zur Behebung von Abhängigkeiten, eine weitere Aufschlüsselung der Arbeit, eine Anpassung der Schätzungen usw. beinhalten.

Die Überarbeitung ist in Easy Agile Programs einfach und rationalisiert. Die Fähigkeit Bearbeiten Sie Problemschätzungen und Zusammenfassungen direkt in Echtzeit macht jede Nachbearbeitung schnell und einfach. Wenn Sie ein Problem per Drag-and-Drop verschieben, können Sie es ganz einfach verschieben, und alle Auswirkungen auf die damit verbundenen Abhängigkeiten können auf einmal gesehen werden.

Alle Änderungen, die an Problemen in Easy Agile-Programmen vorgenommen werden, werden automatisch in Jira wiedergegeben.

Finden Sie heraus, wie Easy Agile Programs PI Planning für Ihre Teams, Hybrid-Teams oder Remote-Teams vereinfachen können.

Nehmen Sie an einer Produkttour teil und lernen Sie die Easy Agile-Programme kennen

Nehmen Sie an einer Demo teil

Was ist mit Beyond Planning?

Wir haben die Vorzüge der Remote-PI-Planung mit einem digitalen Tool wie Easy Agile Programs untersucht, aber etwas, das so oft übersehen wird, ist — was passiert nach Planung?

Ein Plan bleibt genau das, wenn er nicht in die Tat umgesetzt wird. Ein Plan ist nicht darauf ausgelegt, nicht erfüllt zu werden, und genau hier kann eine verteilte oder hybride Umgebung eine Herausforderung darstellen.

Ihr Programmausschuss bereitet Sie vielleicht auf Erfolg vor, aber fragen Sie sich: Woher wissen Sie, ob Sie auf dem richtigen Weg sind, ihn zu erreichen?

Hier hilft ein digitales, benutzerfreundliches Tool, das native Jira-Probleme verwendet. Am Ende von PI Planning haben die Teams einen Plan in Form eines Program Boards in Jira erstellt, aber sie sind auch bereit für den ersten Sprint, sobald PI Planning abgeschlossen ist.

Von dort aus ist das Program Board eingerichtet und kann weiterentwickelt werden, es muss nicht zusammengerollt und verstaut werden. Genau dafür wurde Easy Agile Programs konzipiert — um Transparenz, aber auch Flexibilität zu bieten, sodass sich der Plan zwangsläufig anpassen und agil sein kann, während gleichzeitig die Dynamik in Richtung Fortschritt erhalten bleibt.

Also was kommt als nächstes für einfache Agile-Programme? Kannst du uns helfen, es zu verbessern? Schauen Sie sich unsere an Produkt-Roadmap und wenn etwas fehlt, lass es uns wissen.

‍

Sollten Sie funktionsübergreifende agile Teams bilden?

In großen, konventionellen Organisationen verwalten mehrere Abteilungen bestimmte Funktionen. Marketing-, Finanz-, Personal- und Vertriebsteams arbeiten in Silos und konzentrieren sich oft auf ihre eigenen Ergebnisse, anstatt sich in erster Linie vom Kunden und dem Markt leiten zu lassen.

Doch schon vor dem Ausbruch der Pandemie erkannten Unternehmen die Notwendigkeit, Veränderungen zu bewältigen und Entscheidungen schneller als je zuvor zu treffen, um mit der Konkurrenz Schritt zu halten. Dann kam Covid, und diese Bedürfnisse haben sich erheblich verschärft.

Um in einer unsicheren, komplexen und vieldeutigen Welt erfolgreich zu sein, entfernen sich viele Unternehmen von Silos und streben nach Unternehmensagilität. Sie bilden Netzwerke von befähigten Personen. funktionsübergreifende agile Teams.

Aber der Wechsel von isolierten Abteilungen zu agilen Teams bedeutet Veränderung, und Veränderungen können schwierig sein.

In diesem Artikel wägen wir die Vor- und Nachteile der einzelnen Betriebsmodelle ab.

Die wichtigsten Punkte

• Kommunikation, Zusammenarbeit und Mitarbeiterengagement sind in funktionsübergreifenden Teams oft besser.
• Durch schnelles iteratives Testen von Lösungen können funktionsübergreifende Teams die Produktivität steigern, Kosten senken und bessere Ergebnisse erzielen.
• Es mag Hindernisse geben, bis ein neu gebildetes funktionsübergreifendes Team reift und sein Potenzial ausschöpft, aber Sie können Maßnahmen ergreifen, um dem Team zum Erfolg zu verhelfen.

„Die beiden dringendsten Gründe für die Einführung von Agile sind die Geschwindigkeit und Flexibilität, die in Arbeitsumgebungen erforderlich sind, die nach wie vor unberechenbar und volatil sind.“ Bericht zum Stand von Agile

Was sind funktionsübergreifende agile Teams?

Funktionsübergreifende agile Teams (manchmal auch als funktionsübergreifende Scrum-Teams bekannt) sind ein Schlüsselelement in der agilen Entwicklung eines Unternehmens.

Das Team bringt Mitarbeiter aus dem gesamten Unternehmen mit unterschiedlichen Fachkenntnissen und Fähigkeiten zusammen. Gemeinsam arbeitet das Team auf ein gemeinsames Ziel hin.

Das Team besteht in der Regel aus 5 bis 11 Personen und definiert, baut, testet und liefert Projekte in Sprints oder Wiederholungen.

„Die Fähigkeit des Teams, sich gegenseitig zu unterstützen, zusammenzuarbeiten und sich auf das Ziel auszurichten, sind wunderbare Möglichkeiten, Agilität zu messen.“

William Rojas, Adaptavist

Was sind die Vorteile funktionsübergreifender agiler Teams?

Es gibt viele Vorteile, funktionsübergreifende agile Teams in Ihrem Unternehmen zu haben. Hier sind unsere fünf besten.

1. Funktionsübergreifende Teams kommunizieren und arbeiten besser zusammen

Isolierte Teams können viele Stunden pro Woche in unproduktiven Besprechungen verbringen, während sie Ressourcen aushandeln und widersprüchliche Prioritäten verwalten. Auf der anderen Seite stimmen sich Agile-Teams von Beginn jedes Projekts an Ziele und Vorgaben ab. Dies trägt dazu bei, dass die nachfolgenden Besprechungen kurz, produktiv und transparent sind. Jede Person ist rechenschaftspflichtig und befugt, Fortschritte zu teilen und Probleme zu lösen. Infolgedessen sind agile Teams oft engagierter und leidenschaftlicher bei ihrer Arbeit.

2. Funktionsübergreifende Teams reagieren schnell

In Silos ist jedes Team für einen Aspekt eines Projekts verantwortlich und hat nur einen begrenzten Überblick darüber, was andere Teams tun. Dies kann zu Blockaden oder widersprüchlichen Prioritäten führen, was zu Nacharbeiten und Verzögerungen führen kann. Im Laufe des Projekts können sie auch feststellen, dass ihnen spezifische Fähigkeiten fehlen, sodass die Teams sich beeilen, die Lücken zu schließen, was zu weiteren Verzögerungen führt. Der Wechsel zu agilen Teams bedeutet, über die notwendigen Fähigkeiten und Ressourcen zu verfügen und widersprüchliche Prioritäten und Hindernisse frühzeitig zu erkennen. Dies hilft agilen Teams, schnell zu iterieren, sich kontinuierlich zu verbessern und Ergebnisse zu erzielen.

3. Funktionsübergreifende Teams sind innovativ

In isolierten Organisationen können sich Mitarbeiter in ihrem abteilungsinternen Gruppendenken verfangen. Durch den begrenzten Kontakt mit anderen Teams ist es weniger wahrscheinlich, dass Mitarbeiter etablierte Praktiken in Frage stellen oder Verbesserungen vorschlagen. In funktionsübergreifenden agilen Teams werden die Sichtweisen von Mitarbeitern aus mehreren Teams von Anfang an geteilt. Da Menschen mit unterschiedlichen Fähigkeiten Probleme auf unterschiedliche Weise angehen, kann dies zu großartigen Ideen und Geschäftsinnovationen führen.

4. Funktionsübergreifende Teams helfen dem Unternehmen, sich an Veränderungen anzupassen

Mit ihrem iterativen Ansatz und ihrer häufigen Kommunikation können funktionsübergreifende agile Teams schnell Probleme lösen und die Richtung ändern. Sie müssen sich nicht mit Neuverhandlungen, Neupriorisierungen und Verzögerungen auseinandersetzen, die isolierte Teams aufhalten könnten. Stattdessen können Unternehmen mit funktionsübergreifenden Teams besser auf sich ändernde Markt- und Kundenbedürfnisse reagieren.

5. Funktionsübergreifende Teams konzentrieren sich konsequent auf das große Ganze

Funktionsübergreifende agile Teams verstehen das „Warum“ hinter ihrer Arbeit, und sie kommen zusammen, wobei das Kundenerlebnis im Mittelpunkt steht. Dieser gemeinsame Fokus löst die Barrieren zwischen den verschiedenen Funktionen innerhalb des Teams auf. Die Ergebnisse werden übergeordneten Geschäftszielen zugeordnet, die dem Endbenutzer einen größeren Mehrwert bieten.

Was sind die Nachteile funktionsübergreifender agiler Teams?

Wenn funktionsübergreifende Teams richtig eingesetzt werden, gibt es wirklich keine Nachteile. Welches Unternehmen wünscht sich nicht eine verstärkte Zusammenarbeit, Innovation, Kundenorientierung und schnellere Lieferung?

Allerdings kann es zu Problemen und Konflikten kommen, wenn Mitarbeiter lernen, sich an die agile Denkweise anzupassen — und genau hier können funktionsübergreifende Teams scheitern. Hier sind einige der häufigsten Herausforderungen, mit denen große Unternehmen konfrontiert sind, wenn sie zu funktionsübergreifenden agilen Teams wechseln:

• Kultureller Widerstand mit Menschen, die nicht bereit sind, die alte Art, Dinge zu tun, loszulassen.
• Keine klare Rechenschaftspflicht, sodass Teams keine schnellen Entscheidungen treffen können und die Mitarbeiter an einem Gefühl der Eigenverantwortung für ihre Arbeit festhalten.
• Mangelnde Ausrichtung auf Ziele, was zu Missverständnissen, Nacharbeiten und potenziellen Konflikten führen kann.

Vor diesem Hintergrund kann es ein wenig Zeit und Unterstützung in Anspruch nehmen, bis ein neu gebildetes agiles Team seine Flügel findet.

„Oft werden Teams agil, indem sie es einfach tun, ausprobieren und sich weiterentwickeln und sich diesem Ansatz verpflichten. Also, wenn Sie noch nicht angefangen haben, fangen Sie einfach an. Das ist oft der größte Kampf.“

William Rojas, Adaptavist

Der erste Schritt ist, einfach loszulegen

Agil zu sein bedeutet, die Prozesse und die Personalstruktur einer Organisation zu ändern, und das kann wie eine Menge harter Arbeit erscheinen. Wenn Unternehmen sich jedoch nicht so verändern, dass sie die Vorteile von Produktivität, Geschwindigkeit, Kunden und Mitarbeiterengagement nutzen können, laufen sie Gefahr, den Anschluss zu verlieren.

Funktionsübergreifende agile Teams können Ihr Schlüssel sein, sich schnell anzupassen und voranzukommen. Es besteht kein Zweifel, dass sie herausragende Ergebnisse liefern können — wenn Sie die richtigen Schritte unternehmen, um sie auf Erfolgskurs zu bringen.

Für konkrete Ratschläge, wie man erfolgreiche funktionsübergreifende agile Teams vorantreibt und Misserfolge vermeidet, melden Sie sich für unser kostenloses On-Demand-Webinar an — „Vor- und Nachteile agiler Teams mit Adaptavist“.

Das Webinar wird zusammen mit unserem Partner und SAFe-Experten Adaptavist einen tiefen Einblick in das SAFe Agile-Team geben.

Sie möchten agil skalieren und erfolgreiche funktionsübergreifende Teams bilden?

Besuchen Sie ein kostenloses, 40-minütiges On-Demand-Webinar, um herauszufinden, wie

‍

Der Erfolg agiler Softwareteams hängt von Zusammenarbeit, Flexibilität und Effizienz ab. Egal, ob Sie ein Coach oder Release Train Engineer sind, der mehrere Teams unterstützt, oder ein Scrum Master oder Ingenieur, der nach Verbesserungen in Ihrem Team strebt, die Verbesserung Ihrer Fähigkeiten im Bereich des Abhängigkeitsmanagements wird Effizienz und Produktivität steigern.

Abhängigkeiten wirken zwar oft wie Hürden, aber hier ist eine Erkenntnis: Sie können ein mächtiges strategisches Instrument sein, um die Leistung Ihres agilen Teams zu verbessern. In diesem Beitrag werden wir untersuchen, wie Sie Abhängigkeiten nutzen können, um Ihr Team zu mehr Effizienz und Erfolg zu führen.

Agile Teamautonomie

Im Mittelpunkt von Agile steht das Konzept der Autonomie und des Selbstmanagements. Es geht darum, Teams in die Lage zu versetzen, die gesamte Durchführung ihrer Arbeit mit minimalen Abhängigkeiten selbst in die Hand zu nehmen. Das bedeutet, ihren Arbeitsablauf zu optimieren, anstatt sich darauf zu verlassen, dass andere Teams den Benutzern einen Mehrwert bieten. Wenn Teams auf andere angewiesen sind, wird der Arbeitsfluss weniger vorhersehbar.

In größeren, komplexeren Unternehmen sind Abhängigkeiten aufgrund der Größe und Komplexität der Systeme oft unvermeidlich. Die eigentliche Herausforderung besteht darin, diese Abhängigkeiten in Verbesserungsmöglichkeiten und nicht in Hindernisse umzuwandeln. Durch die Verbesserung der Sichtbarkeit dieser Abhängigkeiten können Teams sie besser verstehen, die Arbeit effektiver priorisieren und in eine Reihenfolge bringen und die Lieferplanung und -ausführung effizienter verwalten.

Mehr als ein Drittel der agilen Teams gibt an, dass Teamsilos und die daraus resultierenden Verzögerungen ein Problem darstellen

17. Bericht zum Stand von Agile, Digital.AI

Visualisierung von Abhängigkeiten

Die Verbesserung der Sichtbarkeit von Abhängigkeiten beginnt mit offener Kommunikation und Transparenz. Wenn Teammitglieder ihre Aufgaben und Herausforderungen gerne mit anderen teilen, schaffen Sie eine Kultur des Vertrauens und der Zusammenarbeit. Diese Transparenz ist entscheidend, um Abhängigkeiten frühzeitig zu erkennen und effektiv zu verwalten.

Software, die es Teams ermöglicht, Abhängigkeiten klar abzubilden, kann ein hervorragendes Tool sein, um die Sichtbarkeit der Arbeit zu verbessern und es einfacher zu machen, ihren Status zu verfolgen und entsprechend zu planen. Durch die regelmäßige Aktualisierung und Überprüfung der von Ihnen abgebildeten Abhängigkeiten bleiben alle auf dem Laufenden und Sie können potenzielle Engpässe vorhersehen, bevor sie auftreten.

Easy Agile TeamRhythm ist eine benutzerfreundliche App, die sich nahtlos in Jira integrieren lässt, um die Teamplanung zu unterstützen, einschließlich der Visualisierung von Abhängigkeiten. Du kannst Abhängigkeiten nach Typ und Risiko anzeigen und dir Abhängigkeiten sowohl innerhalb deines Teams als auch mit anderen Teams anzeigen lassen.

Abhängigkeitsmuster

Sobald Sie in der Lage sind, Abhängigkeiten klar zu erkennen, erkennen Sie möglicherweise, dass sich Muster bilden. Diese Abhängigkeitsmuster können zeigen, wo sich ein Team bei der Erledigung der Arbeit zu stark oder zu stark von einem anderen Team abhängig macht.

Ständige Engpässe heben Verbesserungsmöglichkeiten hervor, beispielsweise eine Änderung der Teamzusammensetzung. Wenn Sie diese Muster feststellen, ist es unerlässlich, Strategien zu überdenken und umzusetzen, um eigenständiger zu werden und einen reibungsloseren Arbeitsablauf und kürzere Lieferfristen zu gewährleisten.

Priorisierung und Sequenzierung der Arbeit

Sobald Abhängigkeiten identifiziert und sichtbar gemacht wurden, können Sie den Arbeitsablauf verbessern, indem Sie Aufgaben in einer Reihenfolge organisieren, die verhindert, dass die Arbeit durch andere Aufgaben verzögert wird. Nicht alle Aufgaben haben das gleiche Gewicht oder die gleiche Dringlichkeit. Wenn Sie den kritischen Pfad — die Reihenfolge der Aufgaben, die den schnellsten Zeitpunkt für die Bereitstellung von Nutzen bestimmen — kennen, können Sie sich auf die Bereiche konzentrieren, in denen sie am dringendsten benötigt werden.

Eine durchdachte Arbeitsreihenfolge stellt sicher, dass abhängige Aufgaben in der richtigen Reihenfolge angegangen werden, wodurch Verzögerungen und Nacharbeiten minimiert werden. Dieser strategische Ansatz für das Aufgabenmanagement verbessert nicht nur die Effizienz des Teams, sondern unterstützt auch einen reibungsloseren Arbeitsablauf und verhindert, dass die Lieferung in letzter Minute zum Scheitern verurteilt wird.

Bessere Zusammenarbeit

Durch die Identifizierung und Visualisierung von Abhängigkeiten erkennen Sie Engpässe frühzeitig, priorisieren Aufgaben neu und verwalten Lieferpläne effektiv. Noch wichtiger ist, dass Ihr Team so die volle Verantwortung für seine Aufgaben übernehmen und gleichzeitig seine Arbeitsabläufe ständig verbessern kann.

Denken Sie daran, dass jede Abhängigkeit ein Teil eines größeren Puzzles ist, das das Potenzial hat, die Effizienz Ihres Teams zu steigern. Indem Sie diese Abhängigkeiten verstehen und proaktiv verwalten, können Sie reibungslosere Arbeitsabläufe, weniger Hindernisse und ein hocheffizientes agiles Team sicherstellen.

‍

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

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

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

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

Warum Story Mapping

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

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

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

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

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

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

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

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

So erstellen Sie eine User Story Map

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

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

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

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

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

Warum User Story Mapping besser ist als ein flaches Backlog

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

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

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

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

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

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

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

Personen, die Sie einladen könnten, sind:

Der Product Owner für das Team

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

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

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

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

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

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

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

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

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

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

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

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

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

Hier kommt das User Story Mapping ins Spiel.

Was ist User Story Mapping?

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

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

Was ist eine User Story Mapping-Sitzung?

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

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

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

Was ist eine User Story Map?

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

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

Was ist eine User Story?

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

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

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

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

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

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

Wie sieht eine User Story Map aus?

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

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

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

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

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

Was beinhaltet eine User Story Mapping-Sitzung?

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

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

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

Was ist der Sinn von User Story Mapping?

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

Kunden erhalten schneller einen höheren Mehrwert

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

Teams priorisieren und arbeiten besser zusammen

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

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

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

Was ist die Alternative zum User Story Mapping?

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

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

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

Was User Story Mapping für Teams leisten kann

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

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

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

- Chris Heritage, Das Atlassian-Team @NextEra Energy

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

Wie User Story Mapping dein flaches Backlog aufwerten kann

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

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

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

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

Probiere User Story Mapping in Jira aus

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

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

Also, probiere es aus!

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

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

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

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

Versuche es jetzt

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

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

- Michael Doolittle, Produktdirektor @Priceline

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

- Casey Flynn, Analyst für Vertriebsprognosen @adidas

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

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

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

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

Erfahren Sie mehr über User Story Mapping

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

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

Wie organisiert sind deine Jira-Boards? Auf der Skala von „gut durchdachten Anwendergeschichten — wunderschön nach Kundennutzen priorisiert“ bis hin zum „digitalen Äquivalent eines 90er-Jahre-Laminatschreibtisches, der von Haftnotizen und alten Kaffeetassen überladen ist“ — wo stehen Ihre?

Vielleicht ist es an der Zeit, ein Tool zu finden, mit dem Sie Ihre Jira-Probleme auf Vordermann bringen können. Und der beste Weg, die Dinge in Form zu halten, besteht darin, die Arbeit an einem Ort zu visualisieren.

Lesen Sie weiter, um Tipps zu erhalten und zu erfahren, wie Easy Agile TeamRhythm Ihnen hilft, Ihre Arbeit effektiv zu priorisieren.

Visuelles Aufgabenmanagement

Einfach ausgedrückt, wenn Sie etwas klar sehen können, ist es einfacher zu verstehen und zu verwalten. Geben Sie ein: visuelles Aufgabenmanagement.

Das visuelle Aufgabenmanagement verwendet Boards zur Anzeige und Nachverfolgung der Arbeit. Dadurch erhalten Sie einen Überblick über komplexe Projektaufgaben, sodass sie leichter zu verstehen sind.

Für diejenigen von uns, die in Jira arbeiten, nun ja, wir können unsere Epen, Geschichten und Aufgaben auf dem Bildschirm sehen, aber es ist nicht immer klar, wie sie zueinander in Beziehung stehen.

Hier bietet ein Tool wie eine User Story Map, wie das in Easy Agile TeamRhythm, so viel Wert.

Nutzen Sie die Vorteile

Wenn Sie sich die Möglichkeit geben, Ihre Arbeit zu visualisieren, gibt es eine lange Liste von Vorteilen. Wenn Ihr gesamtes Team die vor ihnen liegende Arbeit sehen kann, ist die Kommunikation einfacher und die Teamarbeit kann verbessert werden.

1. Konsistente Kommunikation

Lokale und externe Teams können von jedem Standort aus dieselbe Ansicht der Arbeit sehen. Epische Bilder auf der ganzen Seite mit miteinander verbundenen Problemen, die darunter aufgereiht sind. Wenn Arbeit hinzugefügt oder geändert wird, haben Sie immer noch eine zentrale Informationsquelle, die von allen geteilt wird, unabhängig davon, wo sie sich befinden.

2. Ein zeitsparendes Tool

Die Sprint- oder Versionsplanung ist schnell und einfach, wenn die Teammitglieder alle benötigten Informationen in einer einzigen Ansicht haben. Die Planung ist viel einfacher, wenn Initiativen, Epen, Anwenderberichte und Unteraufgaben zusammen mit Storypoints und Zielen an einem Ort zu sehen sind.

Easy Agile TeamRhythm bietet diese All-in-One-Ansicht sowie die Möglichkeit, neue Probleme auf der Storymap zu erstellen, abzuschätzen und sie per Drag-and-Drop zu sequenzieren. Einfach.

3. Vermeiden Sie unerwartete Straßensperren

Ist schon einmal eine Veröffentlichung durch eine unerwartete Abhängigkeit zum Scheitern gebracht worden? Für eine reibungslose und zuverlässige Veröffentlichung benötigen Sie einen Überblick über Probleme, die von anderen abhängen.

Wir haben es einfach gemacht, die Abhängigkeiten zwischen Problemen auf der TeamRhythm User Story Map zu visualisieren, damit Sie unerwartete Verzögerungen vermeiden und Ihren Kunden weiterhin einen Mehrwert bieten können.

Sie können wählen, ob Abhängigkeiten zwischen Problemen angezeigt werden, die sich auf demselben Board befinden (interne Abhängigkeiten), und ob sich ein Problem auf einem anderen Board befindet (externe Abhängigkeiten). Auf diese Weise erhalten Sie ein klares Bild davon, wie die Arbeit priorisiert werden sollte, sodass Sie Hindernisse vermeiden und Verzögerungen bewältigen können, bevor sie zu einem Problem werden.

Lesen Sie mehr: Abhängigkeitslinien auf der TeamRhythm User Story Map >>

4. Die Produktivität steigt

Das Arbeitsleben ist besser, wenn Sie sehen können, wie Ihr Beitrag einen Unterschied macht. Wenn jeder im Team sieht, wie wichtig seine Arbeit ist, und Ideen, wie man Dinge besser machen kann, in Fluss kommen, dann fängt man an, seine Ziele zu übertreffen.

Wir haben Easy Agile TeamRhythm entwickelt, um Teams dabei zu unterstützen, sich auf kontinuierliche Verbesserungen zu konzentrieren. Das ist etwas, worüber sich alle freuen können, denn das Team geht mit seinen Ideen voran, wie es sein Arbeitsleben verbessern kann. Verwandeln Sie diese Ideen mit nur wenigen Klicks in Jira-Probleme, damit Sie die Dinge im nächsten Sprint in die Tat umsetzen können.

TeamRhythm hilft dir zu sehen, was zuerst zu tun ist

TeamRhythm ist übersichtlich im User-Story-Map-Format angelegt und bietet die Möglichkeit, eine Karte mit Abhängigkeitslinien zu überlagern. So wird deutlich, welche Probleme zuerst angegangen werden müssen, um sicherzustellen, dass Sie Ihre Kunden weiterhin beliefern können.

Jeder im Team hat sofort einen Überblick über seine Prioritäten. Die Kommunikation ist optimiert. Die Zusammenarbeit wird vereinfacht und die Produktivität steigt. Klingt das nicht großartig?!

Sehen Sie sich eine Demo an, erfahren Sie mehr über die Preisgestaltung und probieren Sie es selbst in unserer Sandbox aus. Weitere Informationen finden Sie auf der Seite mit Funktionen und Preisen von Easy Agile TeamRhythm.

Einfacher agiler Teamrhythmus

HAUPTMERKMALE

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

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

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

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

Was ist die User Journey Map?

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

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

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

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

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

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

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

Die Hierarchie der Customer Journey Mapping

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

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

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

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

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

1. Nutzer-Personas oder Buyer-Personas verstehen

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

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

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

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

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

2. Entwickeln Sie Themen und Epen, um Kontaktpunkte anzusprechen

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

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

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

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

Die Epen sollten mehrere grundlegende Anforderungen erfüllen:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fazit: Die Customer Journey Map

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

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

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

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

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

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

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

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

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

„Bottleneck“ ist ein Schlagwort, das Sie nicht hören möchten. Wenn es um Ihren Produktionsprozess geht, geht es bei der Maximierung Ihrer Zeit und Ihres Budgets vor allem darum, die Effizienz hoch zu halten. Wenn Sie jedoch nur die Schritte in Ihrem Prozess verkürzen, werden Ihre Kunden möglicherweise nicht glücklicher. Wenn Sie eine hohe Kapitalrendite und eine höhere Kundenzufriedenheit erzielen möchten, ist die Wertstromanalyse eine ideale Methode, um Ihr Team auf Kurs zu halten.

Was ist Wertstromanalyse?

Value Stream Mapping (VSM) ist eine Technik der Methode der Lean-Prinzipien das hilft Ihnen, die Schritte zu visualisieren, die Sie unternehmen müssen, um ein fertiges Produkt oder eine Dienstleistung zu liefern. Wertstromansichten beschreiben den Informationsfluss und die materiellen Materialien, um zu erkennen, wo für den Kunden ein Mehrwert entsteht. Der Zweck von VSM besteht darin, die Effizienz zu steigern, indem die Verschwendung im Produktionsprozess reduziert wird.

Weithin bekannt als die schlanke Fertigungsmethode, die in der Toyota-Produktionssystem, VSM wird heute häufig zur Beseitigung von Engpässen in anderen Branchen wie Softwareentwicklung, Lieferkette und Gesundheitswesen eingesetzt. Es ist eine vielseitige Technik, die vielen Organisationen helfen kann, zu glänzen. 🌟

Optimieren Sie die Sichtbarkeit und sorgen Sie für Transparenz Ihres Programms für alle Teams

Einfache agile Programme

Nehmen Sie an einer Demo teil

Warum Wertstromanalyse wichtig ist

Wenn Unternehmen Effizienz anstreben, konzentrieren sie sich häufig darauf, die Gesamtzahl der erforderlichen Produktionsschritte zu reduzieren. Kunden sehen jedoch nicht immer, was hinter den Kulissen passiert. Die Verkürzung Ihrer Workflows kommt in erster Linie Ihrem Prozess zugute, ohne dass sich die Erfahrung für sie verändert. Auf der anderen Seite sorgt der Prozess der Wertstromanalyse dafür, dass Ihre Teammitglieder stets über die Bedürfnisse Ihrer Kunden informiert sind, sodass sich Ihr Unternehmen von anderen abheben kann.

Für Teams, die Wertstromanalysen verwenden, geht es bei der Reduzierung von Ineffizienzen vor allem darum, Produktionsprozessschritte zu reduzieren, die keinen Mehrwert bieten. Wertstromansichten visualisieren, wo Sie Mühe verschwenden. Sie zeigen Ihrem Team, dass es in Ordnung ist, Schritte innerhalb Ihres Prozesses beizubehalten — aber jeder dieser Schritte sollte den Kunden in gewisser Weise helfen. Infolgedessen verhindert VSM eine Überproduktion und stellt gleichzeitig sicher, dass Ihre Kunden mit Ihrem Endprodukt oder Ihrer Dienstleistung zufrieden sind.

Du kannst es besser erreichen schlank, agil Workflows mit Wertstromanalyse, um effektiv mit der Kundennachfrage Schritt zu halten. 💪

Begriffe zur Wertstromanalyse

Eine typische Wertstromansicht ist in drei Hauptabschnitte unterteilt — Informationsfluss, Materialfluss und Durchlaufzeitleiter —, anhand derer Sie erkennen können, wo Prozessverbesserungen möglich sind. Um Ihnen zu helfen, jeden Teil einer Wertstromansicht einfacher zu vervollständigen, erklären wir Ihnen eine Handvoll gängiger Begriffe, auf die Sie in den einzelnen Abschnitten stoßen werden.

Wenn Sie sich mit diesen Begriffen vertraut machen, können Sie sich auf diese Microsoft-Vorlage um ein paar VSM-Symbole zu sehen, die Sie häufig verwenden werden.

Informationsfluss

Am Anfang einer Standardwertstromansicht befindet sich ein Abschnitt zum Informationsfluss, der zeigt, wie Daten zwischen Ihren Teammitgliedern, Kunden und anderen Stakeholdern übertragen werden. Zu den allgemeinen Begriffen, die Sie kennen müssen, um diesen Abschnitt auszufüllen, gehören:

• Kunde: Dies ist der Verbraucher, der Ihr Endprodukt erhält. Ihr Kunde wird in der oberen rechten Ecke Ihrer Karte dargestellt.
• Lieferant: Das ist Ihre Organisation. Lieferanten werden in der oberen linken Seite der Wertstromansichten angezeigt.
• Dedizierter Prozessablauf: Dies ist ein Prozess oder eine Abteilung (wie die „Produktionskontrolle“), durch die Informationen fließen.

Materialfluss

In der Mitte einer Wertstromansicht befindet sich ein Abschnitt zum Materialfluss, der Schritt für Schritt zeigt, wie Sie Ihr Produkt oder Ihre Dienstleistung zur Auslieferung bringen. Jedes Feld steht für eine einzigartige Aufgabe, die nach einer Materialübergabe von demselben oder einem anderen Team ausgeführt werden kann.

Um den Abschnitt Materialfluss abzuschließen, müssen Sie die folgenden Begriffe kennen:

• Lieferungen: Auf Wertstromansichten zeigen „Versand“ -Pfeile vom Lieferanten zum ersten Schritt im Materialfluss oder vom letzten Schritt zum Kunden. Sie zeigen, wie Ihr Informationsfluss mit dem Beginn und Ende Ihres Produktionsprozesses zusammenhängt. Ein Pfeil kann beispielsweise zeigen, wie sich Rohstoffe zwischen dem Lieferanten und der Fabrik bewegen oder wie der Softwarezugriff an einen Benutzer „gesendet“ wird.
• Zykluszeit (C/T): Diese Kennzahl gibt die Zeit an, die zwischen den Lieferungen benötigt wird.
• Inventar: Inventar ist das, was zwischen den einzelnen Phasen des Produktionsprozesses produziert wird. Ihr Inventar steht normalerweise unter einem Dreieck mit einem „I“ darin. 🔺

Vorlaufzeitleiter

Am Ende einer Wertstromanalyse befindet sich in der Regel eine Zeitleiter, anhand derer Sie Ihre Durchlaufzeit visualisieren können. Dabei handelt es sich um die durchschnittliche Zeit, die Sie für jeden Schritt Ihres Materialflusses aufgewendet haben.

Kaizen-Burst

In deiner Wertstromkarte kannst du Kaizen-Bursts einbeziehen. Diese stellen Aktivitätsschübe dar (wie ein Sprint), in dem sich Ihr Team darauf konzentriert, ein bestimmtes Problem zu lösen — z. B. die Bearbeitung von Kundenretouren —, um potenzielle Engpässe schnell zu beheben. Die Symbole für Kaizen-Bursts sehen aus wie Explosionen in Comics, um deine Aufmerksamkeit zu erregen. 💥

So erstellen Sie eine Wertstromkarte

Wenn Sie bereit sind, mit der Wertstromanalyse zu beginnen, wählen Sie das spezifische Produkt oder die Dienstleistung aus, für die Sie eine Karte erstellen möchten. Obwohl alle Produktionsprozesse von einer kontinuierlichen Verbesserung profitieren können, sollten Sie idealerweise mit einem Produkt oder einer Dienstleistung beginnen, die am meisten von VSM profitieren könnte. Sobald Sie Ihre Auswahl getroffen haben, gehen Sie mit Ihrem VSM-Team wie folgt vor:

1. Definiere dein Ziel: Identifizieren Sie, was Sie als Ergebnis der Wertstromanalyse für den Kunden ändern möchten. Beispielsweise möchten Sie vielleicht die Qualität eines Produkts oder die Geschwindigkeit, mit der Sie eine Dienstleistung erbringen, verbessern.
2. Klären Sie Ihren Anwendungsbereich ab: Definieren Sie den Anfang und das Ende Ihrer Wertstromkarte. Sie können eine Übersicht erstellen, die alle Schritte zwischen Konzept und Umsetzung umfasst. Sie können mit einem ineffizienten Teil Ihres Wertstroms beginnen oder mit einer Vertragsvereinbarung statt einer herkömmlichen Lieferung enden.
3. Beschreiben Sie Ihren Prozess: Listen Sie jeden Schritt Ihres Produktionsprozesses auf. Sprechen Sie zunächst mit Teammitgliedern aus allen am Prozess beteiligten Abteilungen, um alle erforderlichen Erkenntnisse zu sammeln. Ihre Liste sollte Schritte enthalten, die keinen Mehrwert generieren. Sammeln Sie Daten über Zykluszeiten, Durchlaufzeiten, Inventar und mehr, um jeden Schritt noch besser zu verstehen.
4. Erstellen und evaluieren Sie Ihre aktuelle Zustandskarte: Erstellen Sie anhand der gesammelten Informationen eine Karte, die den aktuellen Stand Ihres Prozesses widerspiegelt. Ermitteln Sie gemeinsam mit Ihrem Team, welche Schritte produktiv sind und wo Verbesserungen erforderlich sind. Mithilfe dieser Karte können Sie Bereiche identifizieren, in denen Probleme auftreten, z. B. lange Prozesszeiten oder Softwareausfälle.
5. Entwickeln Sie eine zukünftige Wertstromkarte des Bundesstaates: Erstellen Sie eine zweite Karte, die einen verbesserten Prozess veranschaulicht, bei dem unwichtige Schritte vermieden werden. Dies wird die Karte sein, der Sie letztendlich folgen werden, um Ihre Ziele zu erreichen.
6. Erstellen Sie einen Implementierungsplan: Legen Sie fest, wie Ihr Team den neuen Prozess umsetzen wird, um sich Ihrem zukünftigen Status zuzuwenden. Geben Sie an, welche Kennzahlen Sie im Auge behalten werden, um sicherzustellen, dass Sie auf dem richtigen Weg sind, Ihre Ziele zu erreichen. Sie können auch festlegen, wie oft Sie Ihre Fortschritte überprüfen und Ihre zukünftige Zustandskarte (falls erforderlich) während der Implementierungsphase anpassen.

📣 Erreichen Sie eine skalierbare Teamausrichtung mit Einfache agile Programme

Nehmen Sie an einer Demo teil

Bieten Sie Ihren Kunden weiterhin einen Mehrwert

Zu lernen, aus der Perspektive Ihrer Kunden zu sehen, ist entscheidend, um sicherzustellen, dass Sie sich von Ihren Mitbewerbern abheben. Wenn Sie den Wertstromanalyseprozess verfolgen, können Sie sich ein Bild davon machen, wo Ihr Team Mehrwert generiert und wo Sie zusätzliche Arbeit leisten, die leicht vermieden werden kann.

Erfahren Sie, wie Sie Ihren Kunden weiterhin einen Mehrwert bieten Einfache agile Programme kann Ihnen helfen, tiefer in die Kundenreise Ihres Produkts einzutauchen.

Testen Sie Easy Agile Programs für Jira

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

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

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

Was ist der Unterschied zwischen Use Cases und User Stories?

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

Anwendungsfall vs. User Story: Vergangenheit und Gegenwart

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

Was ist ein Anwendungsfall?

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

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

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

Zu diesen Angaben gehören:

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

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

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

Was ist eine User Story?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Anwendungsfälle im Vergleich zu Anwenderberichten: Fazit

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

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

Verwenden von Easy Agile TeamRhythm

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

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

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

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

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

Was sind User Story Points?

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

Wann sollten Storypoints geschätzt werden?

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

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

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

Wie schätzt man User Story Points ein

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

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

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

Was ist ein Storypoint wert?

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

So funktioniert das:

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

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

Zum ersten Mal Storypoints einschätzen

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

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

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

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

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

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

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

Vereinfachen Sie die Schätzung

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

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

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

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

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

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

Verwendung von Story Points zur Schätzung der Geschwindigkeit

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

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

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

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

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

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

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

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

Verwendung von Story Points in Scrum, Kanban und Extreme Programming

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

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

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

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

Zeremonien sind regelmäßige Veranstaltungen, die von Scrum-Teams abgehalten werden. „Agile“ ist ein weit gefasstes Wort, das eine andere Arbeitsweise mit kürzeren, zeitlich begrenzten Release-Zyklen beschreibt.

Unter dem breiten Dach von Agile ist Scrum einer der beliebtesten Ansätze, mit denen Teams ihre Arbeit und Veröffentlichungen organisieren.

Jede kurze Iteration der Arbeit in Scrum wird als Sprint bezeichnet. Ein Sprint ist normalerweise ein Zeitraum von 2 Wochen, in dem sich das Team auf einen kleinen Teil der Arbeit konzentriert.

Die Idee ist, dass sich jeder auf einen Teil der Arbeit konzentriert. Und dieser Teil muss innerhalb desselben Sprints fertiggestellt und an den Kunden versendet werden.

Scrum kann in einige wichtige Elemente unterteilt werden:

1. Rollen
2. Artefakte
3. Zeremonien

Dieser Beitrag konzentriert sich auf die Scrum-Zeremonien.

Alle 4 Scrum-Zeremonien tragen dazu bei, dass sich das Scrum-Team auf den Teil der Arbeit konzentriert, auf den es sich in diesem Sprint geeinigt hat.

Es hilft dem Team, den Fortschritt der Arbeit, zu deren Abschluss es sich verpflichtet hat, transparent zu machen und Probleme frühzeitig anzusprechen, bevor sie zu Blockern werden.

Schauen wir uns jede der vier agilen Zeremonien in Scrum an:

1. Steh auf (oder tägliches Scrum)

Ziel des Stand-Up: ein kurzer Check-in, bei dem das Team Probleme ansprechen oder mit dem gesamten Team von Angesicht zu Angesicht kommunizieren kann.

Wer tritt dem bei täglich aufstehen: Entwickler, Scrum Master, Product Owner

Ergebnis des täglichen Aufstehens: Das Team erhöht alle Blocker, muss sie aber nicht lösen. Stellen Sie sicher, dass jedes Teammitglied sich darüber im Klaren ist, woran es gerade arbeitet. Jedes Teammitglied sollte in der Lage sein, diese drei Fragen zu beantworten:

• Was habe ich gestern abgeschlossen?
• Woran werde ich heute arbeiten?
• Bin ich durch irgendetwas blockiert?

Wann sollte man einen Stand halten: täglich

Tipp: Stand-ups können von Geschäftsteams durchgeführt werden und müssen nicht immer von Angesicht zu Angesicht stattfinden. Hier ist ein Foto vom Stand up der Geschäftsleitung der australischen Bank ANZ in Aktion:

Und noch ein Bild von InsideIt's Stand Up:

2. Sprint-Planung

Ziel der Sprint-Planung: Die Sprint-Planung hilft dem Team, sich auf die nächsten Aufgaben vorzubereiten. Das Team bespricht jedes Arbeitsthema, das vom Product Owner priorisiert wurde.

Wer macht Sprint-Planung: Entwickler, Product Owner, Scrum Master

Ergebnis der Sprint-Planung: dass jeder weiß, was das Sprintziel ist und wie er es erreichen wird. Stellen Sie sicher, dass jeder versteht, was die allgemeine Vision oder das Ziel der Arbeit ist.

Das Team wird sich damit auskennen, welche Arbeit im nächsten Sprint zur Verfügung steht. Das Team wird alle Hindernisse oder Möglichkeiten besprechen und herausfinden, wie es die Art und Weise, wie die Arbeit abgeschlossen wird, optimieren kann.

Das Team schätzt auch die Arbeit ab und zieht eine Grenze, wenn geschätzt wird, dass der Aufwand zur Fertigstellung der Arbeit die Kapazität oder die historische Geschwindigkeit des Teams übersteigt.

Wann sollte die Sprint-Planung abgehalten werden: am Ende eines Sprints oder ganz am Anfang eines neuen Sprints.

Bonus: Manchmal findest du bei der Sprint-Planung Dinge, die du nicht tun würdest, und das ist auch wertvoll.

3. Bewertung im Sprint

Ziel des Sprint Reviews: Präsentieren Sie die abgeschlossenen Arbeiten und erhalten Sie Feedback vom Product Owner und den relevanten Stakeholdern.

Wer nimmt am Sprint Review teil: Ausführende Sponsoren, Entwickler, Scrum Master, Product Owner

Ergebnis des Sprint Reviews: Jedes Teammitglied fühlt sich gestärkt, wenn es dem Team seine Arbeit präsentiert. Das Team kann seine Erfolge feiern. Das Führungsteam kann Fragen stellen. Der Product Owner kann Feedback geben und überprüfen, ob die Arbeit von hoher Qualität ist und der Benutzererfahrung entspricht. Passt am besten zu Getränken und Kuchen.

Wann sollte ein Sprint Review abgehalten werden: am Ende jedes Sprints.

4. Rückblick

Ziel der Retrospektive: ehrliche Diskussion darüber, was gut funktioniert hat und was nicht. Fördern Sie Selbstverbesserung und Transparenz.

Wer nimmt an der Retrospektive teil: Entwickler, Scrum Master, Product Owner

Ergebnis einer Retrospektive: erhalte Feedback vom Team und versuche, dich im nächsten Sprint zu verbessern. Das Schöne an Agile und Scrum ist die schnelle Feedback-Schleife.

Wenn etwas nicht gut funktioniert, tut das dem Team nur maximal 2 Wochen weh. Es kann dann im Nachhinein behoben werden, und es können Maßnahmen ergriffen werden, um das Problem zu beheben, bevor es aus dem Ruder läuft.

Das Ergebnis sollte die Zusage des Teams sein, sich auf Bereiche zu konzentrieren, die verbessert werden müssen, oder das Verhalten fortzusetzen, das der Gesundheit und/oder der Geschwindigkeit des Teams zugute kommt.

Wann sollte eine Retrospektive abgehalten werden: zu Beginn eines neuen Sprints, wenn ich über einen Sprint nachdenke, der gerade zu Ende gegangen ist.

---

Das gemeinsame Thema dieser Scrum-Zeremonien ist, dass sie die Teamzusammenarbeit, Transparenz und Kommunikation fördern.

Meiner Erfahrung nach ist es genau das, was Agile wirklich zu einer besseren Arbeitsweise macht.

Es sind nicht die Storypoints oder gar die Art und Weise, wie der Backlog priorisiert wird, die den Unterschied machen. Der wahre Wendepunkt von Agile ist, dass es Teams mit offener und ehrlicher Kommunikation hilft.

Diese Agile/Scrum-Zeremonien werden nicht immer für jedes Team gleich funktionieren.

Sie sind jedoch eine großartige Möglichkeit, Gespräche zu erleichtern und eine kontinuierliche Verbesserung zu fördern.

Vielleicht stehen Sie gerade erst am Anfang, oder Sie haben vielleicht eine Weile mit agilen Methoden gearbeitet, aber wir sind uns sicher, dass Sie zustimmen können, dass die Agile-Skalierung in einem großen Unternehmen entmutigend sein kann. PI Planning ist der Schlüssel zur agilen Skalierung. Deshalb haben wir diesen Leitfaden zusammen mit einer praktischen Checkliste entwickelt, um Sie bei der Durchführung erfolgreicher Planungssitzungen zu unterstützen und Ihr Selbstvertrauen für Ihre nächste skalierte Planungsveranstaltung zu stärken.

Die kostenlose Checkliste finden Sie am Ende dieses Handbuchs.

Dieser Leitfaden deckt alles ab, von grundlegenden Konzepten bis hin zu fortgeschrittenen Implementierungsstrategien. Wir werden die wesentlichen Elemente einer erfolgreichen PI-Planung erläutern, einschließlich der Vorbereitungsschritte, der Rollen der Teilnehmer, der Agendastruktur und der bewährten Verfahren für Teams, die an einem Standort oder an einem anderen Standort arbeiten. Du lernst, wie du häufig auftretende Herausforderungen bewältigst, Tools wie Jira effektiv nutzt und sicherstellst, dass deine PI Planning-Sitzungen den größtmöglichen Nutzen für dein Unternehmen bringen.

Fangen wir mit den Grundlagen an.

Was ist PI Planning?

PI Planning steht für Program Increment Planning.

PI-Planungs-Sitzungen sind regelmäßig geplante Veranstaltungen, bei denen sich Teams innerhalb desselben Agile Release Trains (ART) treffen, um sich abzustimmen und zu vereinbaren, was als Nächstes kommt. Die Teams werden versuchen, sich auf Ziele und Prioritäten zu einigen, Funktionen zu besprechen, die Roadmap zu planen und teamübergreifende Abhängigkeiten zu identifizieren.

Ziel ist es, die Teams auf die Mission und aufeinander auszurichten. Hier sind die wesentlichen Elemente von PI Planning:

• 2 ganztägige Veranstaltungen finden alle 8-12 Wochen statt (abhängig von der Länge Ihrer Inkremente)
• Produktmanager arbeiten im Voraus daran, die geplanten Funktionen für das Inkrement zu priorisieren
• Eigene Planung und Schätzung der User Story durch Entwicklungsteams
• Ingenieure und UX-Teams arbeiten daran, die Planung zu validieren

Warum PI-Planung?

PI Planning ist für große agile Organisationen unglaublich vorteilhaft. PI Planning ermöglicht:

• Kommunikation
• Sichtbarkeit
• Zusammenarbeit

Um die Auswirkungen zu verstehen, schauen wir uns ein Beispiel für eine große Organisation an, die PI Planning noch nicht implementiert hat. Diese Organisation hat 250 Teams und 6.500 Teammitglieder. Diese Teams sprechen selten miteinander, es sei denn, sie befassen sich mit einem kritischen Problem, das sie zur Zusammenarbeit gezwungen hat.

Die Abstimmung zwischen diesen Teams erfolgt auf der Ebene des Führungsteams, und dazwischen gibt es mehrere Ebenen von Managern, die Informationen mit unterschiedlichem Erfolg weitergeben. Es gibt einen ständigen Kampf um Ressourcen, Budget und Möglichkeiten, an den aufregendsten Projekten zu arbeiten.

Ihre Projekte haben die Angewohnheit, widersprüchlich zu sein — ein Team würde etwas veröffentlichen und dann würde etwas im Projekt eines anderen Teams kaputt gehen.

PI Planning ist das erste Mal, dass viele große Unternehmen ihre Teams in einem Raum oder in derselben Telefonkonferenz zusammenbringen, um miteinander zu sprechen. Dies ist eine Gelegenheit, wichtige Gespräche darüber zu führen, wer woran arbeitet.

Warum ist das wichtig?

1. Wenn du ein System oder ein Code-Repository berührst, musst du wissen, wie sich das auf ein anderes Team auswirken wird.
2. Möglicherweise müssen Sie etwas arbeiten, damit ein anderes Team zuerst an seinem Feature arbeiten kann (und umgekehrt)

Mit der richtigen Planung und Zusammenarbeit können Teams ihre Aufgaben effektiver erledigen, Veröffentlichungen vorhersehbarer machen und das Budget einhalten.

Geschäftsvorteile von PI Planning

Wir haben zwar die grundlegenden Gründe für die Durchführung von PI Planning behandelt, lassen Sie uns jedoch näher auf die spezifischen Geschäftsvorteile eingehen, die Unternehmen aus einer effektiven Implementierung von PI Planning ziehen:

Bessere Ressourcenauslastung

• PI Planning bietet einen klaren Überblick über die Teamkapazitäten und -fähigkeiten im gesamten Agile Release Train
• Unternehmen können die Ressourcenallokation optimieren, indem sie Qualifikationslücken frühzeitig erkennen und beheben
• Teams können die Arbeitslast zwischen den Iterationen besser verteilen und Überlastung vermeiden
• Teamübergreifende Abhängigkeiten werden im Voraus identifiziert, wodurch Ressourcenkonflikte vermieden werden
• Gemeinsam genutzte Ressourcen können effektiver für mehrere Teams geplant werden

Verbessertes Risikomanagement

• Früherkennung potenzieller Risiken durch gemeinsame Planungssitzungen
• Die Einrichtung eines umfassenden Risk Boards während der PI-Planung hilft dabei, potenzielle Probleme zu verfolgen und zu überwachen
• Teams können Strategien zur Schadensbegrenzung entwickeln, bevor sich Probleme auf die Umsetzung auswirken
• Abhängigkeiten zwischen Teams werden proaktiv abgebildet und verwaltet
• Regelmäßige Risikoüberprüfungen während des PI gewährleisten eine kontinuierliche Überwachung und Anpassung

Strategische Ausrichtung und Entscheidungsfindung

• Die Präsentation des Geschäftskontextes stellt sicher, dass alle Teams die Unternehmensziele verstehen
• In Sessions zur Produkt- und Lösungsvision werden die Teams an den Kundenbedürfnissen und der Marktrichtung ausgerichtet
• Besprechungs- und Problemlösungssitzungen durch das Management ermöglichen fundierte Entscheidungen
• Teams können bessere Kompromissentscheidungen treffen, wenn sie eine klare Sicht auf die Prioritäten haben
• Wertströme werden unternehmensweit visualisiert und optimiert

Messbare Geschäftsergebnisse

• Bessere Vorhersagbarkeit bei der Lieferung durch strukturierte Planung
• Bessere Kundenzufriedenheit durch abgestimmte Bereitstellung von Funktionen
• Weniger Verschwendung und Redundanz bei den Entwicklungsbemühungen
• Schnellere Markteinführung neuer Funktionen und Produkte
• Effektivere Nutzung organisatorischer Ressourcen und Budgets

Eine Quelle der Wahrheit

• PI Planning schafft ein gemeinsames Verständnis für alle Teams
• Visualisierungsfunktionen helfen Teams, das Gesamtbild zu sehen
• Alle Beteiligten arbeiten nach derselben Roadmap und denselben Prioritäten
• Abhängigkeiten und Verpflichtungen sind klar dokumentiert
• Der Fortschritt kann teamübergreifend konsistent verfolgt werden

Durch die Implementierung einer effektiven PI-Planung können Unternehmen diese Vorteile nutzen und gleichzeitig eine kollaborativere und effizientere Entwicklungsumgebung schaffen. Regelmäßige Wiederholungstreffen und Zeremonien tragen dazu bei, diese Ausrichtung während der gesamten Programmphase aufrechtzuerhalten, während die vierteljährliche Steuerung die kontinuierliche strategische Ausrichtung gewährleistet.

Alles sehr gute Gründe, PI Planning zu machen.

Was ist das Ziel von PI Planning?

PI-Planung ist ein wesentlicher Bestandteil der Skaliertes Agile-Framework, ein Framework, das darauf ausgelegt ist, großen Unternehmen mit mehreren Teams Agilität zu ermöglichen.

SAFe PI Planning hilft Teams im Agile Release Train (ART) dabei, Workflows, Ziele, Releases und mehr zu synchronisieren, zusammenzuarbeiten und aufeinander abzustimmen.

Ohne PI Planning haben Teams keine strukturierte Kommunikation. Sie wissen möglicherweise nicht, woran die anderen Teams gerade arbeiten, was zu vielen Problemen führen kann. Zum Beispiel könnten zwei Teams an verschiedenen Funktionen arbeiten, ohne zu wissen, dass eine Abhängigkeit besteht, was die Veröffentlichung verzögern oder eine erhebliche Überarbeitung des Codes erfordern könnte.

Das Ziel von PI Planning ist es, alle Ihre Teams strategisch auszurichten und eine teamübergreifende Zusammenarbeit zu ermöglichen, um diese potenziellen Probleme zu vermeiden.

Nachdem wir das „Warum“ geklärt haben, wollen wir uns etwas eingehender mit dem „Was“ befassen. Der beste Weg, sich ein Bild davon zu machen, was während der PI-Planung passiert, besteht darin, einen Blick auf eine Agenda zu werfen.

Was ist ein Programm?

Bei einem Programm werden agile Teams zu einer größeren Gruppe zusammengefasst. Dies wird oft als „Team-of-Teams“ -Ebene bezeichnet. Einfach ausgedrückt ist ein Programm eine Gruppe agiler Teams.

Wenn Leute von „Team-of-Teams“ oder „skalierter Agilität“ sprechen, meinen sie, Agile über ein einzelnes Team hinaus zu integrieren und mehr Teams zu bitten, mitzumachen.

Zum Beispiel könnten 4 Teams an einer NASA-Raumschiffmission zum Mars arbeiten.

Die NASA entscheidet, dass sie herausfinden wollen, ob Agile diesen Teams helfen kann, besser zu arbeiten. Zunächst wechselt das Oxygen-Team also von der Arbeit mit den traditionellen Waterfall-Projektmanagementmethoden zur Anwendung agiler Prinzipien.

1. Team starten
2. Food-Team
3. Sauerstoffteam (agil)
4. Landeteam

Nach einigen Monaten entscheidet die NASA, dass die Arbeitsweise des Sauerstoffteams gut läuft, weshalb die verbleibenden drei Teams ebenfalls agilere Methoden anwenden:

1. Startteam (Agile)
2. Lebensmittelteam (Agile)
3. Sauerstoffteam (agil)
4. Landeteam (Agile)

Jedes dieser 4 Teams organisiert sich selbst, was bedeutet, dass sie für ihre eigene Arbeit verantwortlich sind.

Jetzt, da diese Teams jedoch alle auf die gleiche Weise arbeiten, können sie zu einem Programm zusammengefasst werden.

Sobald Sie die Geschäftsinhaber, das Produktmanagementteam, den Systemarchitekten/Ingenieur und den Release Train Engineer hinzugefügt haben, haben Sie alle Rollen, die Sie benötigen, um kontinuierlich Systeme oder Lösungen über den Agile Release Train (ART) bereitzustellen.

Was ist ein Programmboard?

Program Boards sind ein wichtiges Ergebnis von PI Planning.

Traditionell handelt es sich dabei um ein physisches Brett, das an der Wand befestigt ist und auf dem Säulen angeordnet sind, um die Wiederholungen für das Inkrement zu markieren, und eine Reihe für jedes Team. Die Teams fügen Haftnotizen hinzu, in denen die Funktionen beschrieben werden, an denen sie arbeiten werden.

• Merkmal 1
• Merkmal 2
• Merkmal 3

Sobald alle Funktionen hinzugefügt wurden, identifizieren sie Abhängigkeiten (Funktionen, die sich auf andere Funktionen auswirken) und markieren dies, indem sie sie mit einer roten Zeichenfolge verbinden.

SAFe-Programmboards müssen jedoch nicht physisch sein. Die Verwendung einer digitalen Programmtafel bietet viele Vorteile wie Einfache agile Programme, das direkt in Jira integriert ist. Gegen Ende dieses Handbuchs erfahren Sie mehr darüber, wie Sie Jira für PI Planning verwenden können.

‍

Rüsten Sie Ihre dezentralen, verteilten oder am selben Standort tätigen Teams mit einem digitalen Tool für PI Planning auf Erfolgskurs aus.

Einfache agile Programme

Kostenlose Testversion

Wer ist an PI Planning beteiligt?

Der Erfolg von PI Planning hängt in hohem Maße davon ab, dass die richtigen Teilnehmer während der gesamten Veranstaltung aktiv eingebunden sind. Obwohl es in jeder Organisation geringfügige Abweichungen geben kann, gibt es mehrere Schlüsselrollen, die für eine effektive Planung unerlässlich sind.

Mitglieder des Kernteams und ihre Verantwortlichkeiten

Release Train Engineer (RTE)

Der Release Train Engineer fungiert als primärer Moderator und stellvertretender Leiter für den Agile Release Train (ART). Stellen Sie sich den Dirigenten eines Orchesters vor und stellen Sie sicher, dass alle Teile harmonisch funktionieren. Die Aufgaben des RTE gehen über die bloße Durchführung der Veranstaltung hinaus — sie arbeiten daran, Hindernisse zu beseitigen, Risiken zu managen und die Abstimmung zwischen den Teams sicherzustellen. Vor der PI-Planung stimmen sie sich mit den Interessengruppen ab, um die Veranstaltung vorzubereiten. Während der Planung moderieren sie wichtige Zeremonien und helfen den Teams, Abhängigkeiten zu überwinden. Nach der Veranstaltung verfolgen sie den Fortschritt und helfen den Teams, auf Kurs zu bleiben, um ihre Ziele zu erreichen.

Sie helfen:

• Erstellung und Kommunikation der Jahreskalender
• Bereite alles vor (einschließlich Besprechungen vor und nach der PI-Planung)
• Managen Sie Risiken und Abhängigkeiten
• Erstellen Sie Program PI Objectives aus Team PI Objectives und veröffentlichen Sie sie
• Verfolgen Sie den Fortschritt bei der Erreichung der erwarteten Ziele
• Stellen Sie sicher, dass Strategie und Ausführung aufeinander abgestimmt sind
• Ermöglichen Sie Systemdemos

Als Moderator der zweitägigen Veranstaltung präsentiert der Release Train Engineer auch den Planungsprozess und die erwarteten Ergebnisse der Veranstaltung. Außerdem moderiert er die Management Review and Problem Solving Session und die Retrospektive.

Produktmanager

Die Aufgabe eines Produktmanagers besteht darin, die Bedürfnisse der Kunden zu verstehen und Lösungen zu validieren und gleichzeitig die Portfolioarbeit zu verstehen und zu unterstützen.

Bevor PI Planning stattfindet, nehmen Produktmanager am Pre-PI Planning Meeting teil, in dem sie Inputs, Ziele und Meilensteine für ihre nächsten PI Planning-Veranstaltungen besprechen und definieren.

In PI Planning stellen die Produktmanager die Vision des Programms und die bevorstehenden Meilensteine vor. Damit sie den Arbeitsablauf verwalten und priorisieren können, überprüfen sie den Planentwurf und beschreiben alle Änderungen an der Planung und dem Umfang auf der Grundlage der Sitzung Management Review & Problem Solving. Sobald die PI Planning-Veranstaltung vorbei ist, verwenden sie die Programmziele des Release Train Engineers, um die Roadmap zu aktualisieren.

Nach der PI-Planung spielen Produktmanager eine entscheidende Rolle bei der Kommunikation der Ergebnisse und der Erstellung von PI-Zielen für Lösungen.

Inhaber des Produkts

Die Product Owner sind für die Pflege und Priorisierung des Team-Backlogs sowie für die Iterationsplanung verantwortlich. Sie sind inhaltlich befugt, während der Breakout-Sitzungen des PI Planning Teams Entscheidungen auf User-Story-Ebene zu treffen.

Product Owner helfen dem Team bei der Definition von Geschichten, Schätzungen und Sequenzierung sowie bei der Ausarbeitung der PI-Ziele des Teams und der Teilnahme an der Team-Vertrauensabstimmung. Sie sind auch dafür verantwortlich, Visionen und Ziele vom oberen Management an das Team zu vermitteln, sowie für:

• Berichterstattung über wichtige Leistungskennzahlen
• Bewertung der Fortschritte und
• Mitteilung des Status an die Interessengruppen

Scrum Master

Der Scrum Master ist ein stellvertretender Leiter des Product Owners und des Entwicklungsteams, was bedeutet, dass er Prozesse verwaltet und leitet und gleichzeitig dem Team auf praktische Weise hilft, Dinge zu erledigen.

Sie erleichtern die Vorbereitung von Veranstaltungen (einschließlich PI Planning) und bereiten Systemdemos vor. Sie helfen dem Team dabei, seine Kapazität für Iterationen abzuschätzen, die PI-Ziele des Teams festzulegen und den Zeitrahmen, Abhängigkeiten und Unklarheiten während der Team-Breakout-Sitzungen zu verwalten. Der Scrum Master nimmt auch an der Vertrauensabstimmung teil, um dem Team zu helfen, einen Konsens zu erzielen.

Systemarchitekten und technische Leiter

Diese technischen Führungskräfte bieten wichtige Einblicke in die architektonische Ausrichtung und die technischen Einschränkungen. Während der PI-Planung stellen sie die architektonische Vision vor und arbeiten mit Teams zusammen, um die technische Abstimmung sicherzustellen. Sie helfen den Teams dabei, zu verstehen, wie sich ihre Arbeit in die breitere technische Landschaft einfügt, und potenzielle technische Abhängigkeiten oder Risiken zu identifizieren, bevor sie zu Problemen werden.

Mitglieder des Entwicklungsteams

Entwickler, Tester und andere Mitglieder des technischen Teams sind für die Erforschung, das Design, die Implementierung, das Testen, die Wartung und Verwaltung von Softwaresystemen verantwortlich und nehmen aktiv an der gesamten PI-Planung teil.

Während der PI-Planung nehmen sie an Breakout-Sitzungen teil, um User Stories und Akzeptanzkriterien (zusammen mit ihrem Product Owner) zu erstellen und zu verfeinern und den Arbeitsplan anzupassen. Entwickler helfen dabei, Risiken und Abhängigkeiten zu identifizieren und das Team bei der Ausarbeitung und Finalisierung der PI-Ziele des Teams zu unterstützen, bevor sie an der Team-Vertrauensabstimmung teilnehmen. Ihre praktische Erfahrung ist entscheidend für die Erstellung realisierbarer Pläne und die Identifizierung potenzieller Risiken oder Herausforderungen.

Geschäftsinhaber und leitende Angestellte

Geschäftsinhaber und Führungskräfte spielen eine wichtige Rolle bei der Verknüpfung von Teamaktivitäten mit Geschäftszielen. In der Regel beginnen sie die Veranstaltung mit einer Präsentation zum Geschäftskontext und helfen den Teams dabei, die Marktbedingungen, den Wettbewerbsdruck und die strategischen Prioritäten zu verstehen. Während der gesamten Planung geben sie bei der Überprüfung von Planentwürfen wertvolles Feedback und helfen bei Bedarf, wichtige Kompromissentscheidungen zu treffen.

Unterstützende Rollen und Interessengruppen

Einige andere Rollen sind zwar nicht immer während der gesamten Veranstaltung anwesend, bieten aber während der PI-Planung wertvolle Anregungen:

Kunden und Endverbraucher

Wenn möglich, kann die Teilnahme von tatsächlichen Kunden ein unschätzbares direktes Feedback geben und den Teams helfen, die Bedürfnisse der Benutzer besser zu verstehen. Sie nehmen möglicherweise an bestimmten Sitzungen statt an der gesamten Veranstaltung teil.

Fachexperten

Je nach Fachgebiet werden möglicherweise verschiedene Experten benötigt, um bei der Planung Fachwissen bereitzustellen. Dazu können Sicherheitsexperten, Compliance-Spezialisten oder Fachexperten aus bestimmten Geschäftsbereichen gehören.

Unterstützungsteams

Vertreter von Shared Services oder Support-Teams nehmen häufig teil, um sicherzustellen, dass ihre Fähigkeiten und Einschränkungen im Planungsprozess berücksichtigt werden. Dazu können UX-Designer, DevOps-Teams oder andere spezialisierte Gruppen gehören, die mehrere Teams unterstützen.

Der Schlüssel zu einer erfolgreichen Teilnahme liegt darin, sicherzustellen, dass jede Rolle ihre Verantwortung versteht und bereit ist, ihren Beitrag zu leisten. Organisationen sollten klare Leitlinien zu den Erwartungen und den erforderlichen Vorbereitungsarbeiten bereitstellen, damit alle Teilnehmer ihre Zeit während der PI-Planung optimal nutzen können.

Wann findet PI Planning statt?

Viele Unternehmen sind der Meinung, dass 8-12 Wochen (das sind 4-6 x 2-wöchige Iterationen) die richtige Zeit für eine Erhöhung sind.

Einige Unternehmen führen vierteljährliche PI-Planungen durch, zum Beispiel:

• PI-Planung für das erste Quartal: Dezember
• PI-Planung für das zweite Quartal: März
• PI-Planung für das dritte Quartal: Juni
• PI-Planung für das vierte Quartal: September

Der Zeitpunkt und die Häufigkeit hängen jedoch davon ab, wie lange die einzelnen Programminkremente geplant sind, und müssen möglicherweise an Feiertagen berücksichtigt werden.

Das Gute an Veranstaltungen von PI Planning ist, dass sie regelmäßig nach einem festen Zeitplan stattfinden, sodass Sie sie weit im Voraus planen können. Das bedeutet, dass Teams und Geschäftsinhaber rechtzeitig informiert sind, um sicherzustellen, dass sie zu der Veranstaltung erscheinen können.

Das bedeutet, dass das, was zur Vorbereitung von PI Planning passiert, genauso wichtig sein kann wie die Veranstaltung selbst.

Was ist eine Pre-PI Planning-Veranstaltung und wann wird sie benötigt?

Eine Vorplanungsveranstaltung — getrennt von PI Planning — soll sicherstellen, dass die ART innerhalb des umfassenderen Solution Trains abgestimmt ist, bevor sie PI Planning durchführen. Es geht vor allem um die Synchronisation mit den anderen ARTs, um sicherzustellen, dass Lösung und Organisation gemeinsam in die richtige Richtung gehen.

Sie müssen eine Pre-PI Planning-Veranstaltung organisieren, wenn Sie auf den Stufen Large Solution, Portfolio oder Full SAFe tätig sind. Essential SAFe ist einfacher und hat keinen Solution Train. Wenn Sie also auf dieser Ebene arbeiten, brauchen Sie Pre-PI Planning nicht so formell.

Hier sind einige der Rollen, die zur Vorplanungsveranstaltung eingeladen werden sollten:

• Solution Train Engineer
• Verwaltung der Lösung
• Lösungsarchitekt/Ingenieurwesen
• Team für Lösungssysteme
• Lose Train Engineers
• Produktmanagement
• Systemarchitekten/Ingenieure
• Kunden

Sie werden sich die wichtigsten Funktionen aus dem Solution Backlog, der Solution Intent, der Vision und der Solution Roadmap ansehen. Es ist PI Planning sehr ähnlich, aber auf einer höheren Ebene, für die Gesamtlösung und nicht nur für die einzelne ART.

Die Veranstaltung beginnt damit, dass jede ART ihre bisherigen Programminhalte und Erfolge zusammenfasst, um den Kontext festzulegen. Als Nächstes wird ein leitender Angestellter die Teilnehmer über die aktuelle Situation informieren, bevor das Lösungsmanagement die aktuelle Lösungsvision und alle Änderungen gegenüber den zuvor veröffentlichten Informationen erörtert. Andere Dinge, die häufig besprochen oder abgeschlossen werden, sind unter anderem:

• Straßenkarten
• Meilensteine
• Lösungsrückstände
• Kommende PI-Funktionen aus dem Program Backlog

Wie bereite ich mich auf die PI-Planung vor?

Erfolg bei PI Planning beginnt mit einer gründlichen Vorbereitung. Lange vor der Veranstaltung müssen sich Unternehmen sowohl auf die organisatorische als auch auf die inhaltliche Vorbereitung konzentrieren. In der Regel leitet der Release Train Engineer diese Vorbereitung und arbeitet mit verschiedenen Beteiligten zusammen, um sicherzustellen, dass alles an seinem Platz ist.

Organisatorische Bereitschaft bedeutet, sicherzustellen, dass die richtigen Personen effektiv teilnehmen können. Das bedeutet:

• Festlegung klarer Erwartungen an alle Teilnehmer in Bezug auf ihre Rollen und Verantwortlichkeiten während der Veranstaltung. Geschäftsinhaber und Interessenvertreter müssen ihre Kalender blockieren und ihre Beiträge vorbereiten. Die Teams müssen verstehen, was von ihnen während der Sitzungen erwartet wird.
• Organisation geeigneter Einrichtungen oder technischer Infrastruktur für die Veranstaltung. Bei Veranstaltungen, die gleichzeitig stattfinden, bedeutet dies, ausreichend Platz für die Planung großer Räume und Teamzusammenbrüche zu sichern. Bei Veranstaltungen an entfernten Orten bedeutet das, Tools für die Zusammenarbeit zu testen und sicherzustellen, dass jeder den richtigen Zugriff hat. Stellen Sie sicher, dass die Tools, die Sie zur Erleichterung der Planung benötigen, verfügbar sind und ordnungsgemäß funktionieren. Testen Sie alle Technologien, auf die Sie sich verlassen, im Voraus (einschließlich Audio, Video, Internetverbindung und Zugriff auf PI Planning-Anwendungen), um sicherzustellen, dass Ihre verteilten Teams an der PI Planning-Veranstaltung teilnehmen können. Vergessen Sie nicht, auch genug Essen für alle einzuplanen (Planung ist harte Arbeit).

Die Bereitschaft zum Inhalt ist ebenso wichtig. So müssen sich alle wichtigen Interessengruppen vorbereiten:

• Das Produktmanagement arbeitet daran, die Vision des Programms und die Prioritäten der Funktionen zu verfeinern und sicherzustellen, dass es klar kommunizieren kann, was gebaut werden muss und warum.
• Systemarchitekten bereiten sich darauf vor, ihre technische Vision und alle architektonischen Überlegungen, die sich auf die Planung auswirken, mit Ihnen zu teilen.
• Geschäftsinhaber sammeln relevante Markt- und Kundeneinblicke, die sie während der Präsentation zum Geschäftskontext teilen können.
• Die Teams überprüfen ihre aktuelle Arbeit und ihre Kapazitäten, um sich auf Planungsgespräche vorzubereiten.

Alle Moderatoren müssen auch die Inhalte für ihre Präsentationen vorbereiten.

Was sollte in die PI-Planungsagenda aufgenommen werden?

Hier ist eine Standardvorlage für die Agenda von PI Planning:

‍

Der Erfolg von PI Planning hängt in hohem Maße von einer sorgfältigen Planung und einer gut strukturierten Agenda ab. Das standardmäßige zweitägige Format bietet zwar einen Rahmen, aber das Verständnis des Zwecks und Ablaufs jeder Sitzung hilft den Teams, ihre Planungseffektivität zu maximieren.

Erster Tag: Kontext setzen und erste Planung

Der erste Tag beginnt mit der Präsentation des Geschäftskontextes, die in der Regel von der Geschäftsleitung gehalten wird. Diese wichtige Sitzung gibt den Ton für die gesamte Veranstaltung an und bietet den Teams Einblicke in die Marktbedingungen, Kundenfeedback und organisatorische Prioritäten, die ihre Planungsentscheidungen beeinflussen werden.

Im Anschluss daran steht die Präsentation der Produktvision im Mittelpunkt. Das Produktmanagement teilt seine Roadmap und Vision mit und hebt die wichtigsten Funktionen und Prioritäten für die bevorstehende Programmerweiterung hervor. Diese Sitzung hilft den Teams nicht nur zu verstehen, was sie entwickeln werden, sondern auch, warum dies für Kunden und das Unternehmen wichtig ist.

Als nächstes folgt die Architekturvision, in der technische Leiter alle wesentlichen architektonischen Änderungen oder Überlegungen skizzieren, die Teams bei ihrer Planung berücksichtigen müssen. Dazu können Plattformaktualisierungen, Sicherheitsanforderungen oder technische Abhängigkeiten gehören, die sich auf die Entwicklungsarbeit auswirken könnten.

Der Nachmittag konzentriert sich auf Team-Breakouts, bei denen die einzelnen Teams mit ihrer detaillierten Planungsarbeit beginnen. Während dieser Sitzungen gehen die Teams wie folgt vor:

• Überprüfen Sie ihre Kapazitäten und Fähigkeiten
• Fangen Sie an, Features in Geschichten zu unterteilen
• Identifizieren Sie anfängliche Abhängigkeiten mit anderen Teams
• Fangen Sie an, ihre Pläne für den Zuwachs auszuarbeiten

Der Tag endet mit einer Überprüfung des Planentwurfs, bei der die Teams ihre ersten Überlegungen der breiteren Gruppe vorstellen. Dieser erste Blick hilft dabei, wichtige Konflikte oder Bedenken frühzeitig im Prozess zu erkennen.

Tag zwei: Raffinesse und Engagement

Der zweite Tag beginnt mit der Planung von Anpassungen auf der Grundlage des Feedbacks vom ersten Tag der Entwurfsprüfung. Die Teams nutzen diese Zeit, um festgestellte Konflikte zu lösen und ihre Pläne auf der Grundlage neu entdeckter Abhängigkeiten oder Einschränkungen zu verfeinern.

Während der morgendlichen Team-Breakouts:

• Finalisieren Sie ihre Feature-Schätzungen
• Verbleibende Abhängigkeiten lösen
• Erfülle ihre Teamziele
• Gehen Sie auf alle identifizierten Risiken ein

Der Nachmittag konzentriert sich auf die endgültige Überprüfung des Plans und die Risikobewertung. Jedes Team präsentiert seine fertigen Pläne, jetzt mit mehr Details und Zuversicht. Die Gruppe überprüft gemeinsam den Programmausschuss und untersucht teamübergreifende Abhängigkeiten und potenzielle Risiken bei der Umsetzung.

Der Tag gipfelt in der Vertrauensabstimmung, bei der die Teams ihr Vertrauen in die Erreichung der geplanten Ziele angeben. Wenn die Zuversicht gering ist, benötigen die Teams möglicherweise zusätzliche Zeit, um die Pläne anzupassen, bevor die Verpflichtungen endgültig festgelegt werden.

Schlüssel zu erfolgreichem Agenda-Management

Eine effektive PI-Planung erfordert eine sorgfältige Einhaltung des Zeitplans und der Vorbereitung. Organisationen sollten:

• Planen Sie die Veranstaltung rechtzeitig, um sicherzustellen, dass wichtige Interessengruppen teilnehmen können. Dies ist besonders wichtig für verteilte Teams, die möglicherweise Reisen organisieren oder sich über Zeitzonen hinweg koordinieren müssen.
• Teilen Sie die Agenda und die Erwartungen vor der Veranstaltung mit, damit sich die Teams vorbereiten können. Dazu gehört auch die Verteilung aller Materialien oder Daten, auf die die Teams bei der Planung zurückgreifen müssen.
• Planen Sie Pufferzeit für unerwartete Diskussionen oder Problemlösungssitzungen ein. Es ist zwar wichtig, den Zeitplan einzuhalten, aber eine gewisse Flexibilität hilft Teams, kritische Probleme zu lösen, sobald sie auftreten.
• Planen Sie regelmäßige Pausen ein, um die Energie und Konzentration während der beiden Tage aufrechtzuerhalten. Die Planung großer Räume kann anstrengend sein, und Teams benötigen Zeit, um Informationen zu verarbeiten und neue Energie zu tanken.

Denken Sie daran, dass diese Agenda zwar einen Rahmen bietet, Sie sie jedoch möglicherweise an die spezifischen Bedürfnisse Ihres Unternehmens anpassen müssen. Verteilte Teams, sehr große ARTs und andere Faktoren erfordern möglicherweise eine kreative Planung. Einige Sitzungen benötigen möglicherweise mehr Zeit, während andere verkürzt werden können. Wenn Sie Teams in mehreren Zeitzonen haben, muss Ihre PI Planning-Agenda möglicherweise über 3-4 Tage dauern. Wenn es Ihre erste PI Planning-Veranstaltung ist, probieren Sie die Standardagenda aus, holen Sie sich Feedback von Ihren Teams und experimentieren Sie beim nächsten Mal mit verschiedenen Formaten.

Was passiert im ersten Teil des PI Planning Meetings?

Der erste Teil des PI Planning-Meetings dient dazu, den Kontext für die nächste Planung festzulegen.

Tag 1 beginnt normalerweise mit einer Präsentation eines leitenden Angestellten oder Geschäftsinhabers. Die Tagesordnung sieht eine Stunde vor, um über den aktuellen Stand des Unternehmens zu sprechen. Sie heben spezifische Kundenbedürfnisse hervor, wie die aktuellen Produkte diese Bedürfnisse erfüllen, und mögliche Lücken.

Danach teilt das Produktmanagement-Team die aktuelle Vision für Ihr Produkt oder Ihre Lösung mit. Sie werden über alle Änderungen sprechen, die seit der letzten PI Planning-Sitzung (normalerweise etwa 3 Monate zuvor) vorgenommen wurden. Sie beschreiben, was ansteht, einschließlich Meilensteine und die nächsten 10 geplanten Funktionen. Diese Sitzung sollte etwa 1,5 Stunden dauern.

Warum findet am Ende von PI Planning eine Vertrauensabstimmung statt?

Das Vertrauensvotum ist ein scheinbar kleiner, aber sehr wichtiger Teil von PI Planning gegen Ende der Veranstaltung.

Es ist wichtig, dass das Team zuversichtlich ist, sich den Zielen und der geplanten Arbeit zu verpflichten. Der Release Train Engineer wird die Teams bitten, darüber abzustimmen.

Jeder, der an der Planung beteiligt ist, muss wählen. Dies kann durch Anheben der Hände (und Finger) geschehen oder es könnte über das von Ihnen verwendete Tool geschehen. Zum Beispiel das Das Teamplanungsboard in Easy Agile Programs ermöglicht es jedem Teammitglied, an seiner Vertrauensabstimmung teilzunehmen.

Wenn die durchschnittliche Stimmenzahl im ganzen Raum mindestens drei von fünf Stimmen beträgt, ist der Plan genehmigt. Wenn es weniger ist, muss er überarbeitet werden (bis er ein hohes Konfidenzniveau erreicht hat). Wenn jemand nur eine oder zwei Stimmen abgibt, hat er die Möglichkeit, seine Argumentation mitzuteilen.

Bei der Vertrauensabstimmung geht es darum, sicherzustellen, dass sich die Teilnehmer einig sind und dass sie sich einig sind, dass der Plan in seiner aktuellen Form innerhalb des vorgegebenen Zeitrahmens möglich ist. Apropos Timing: Lassen Sie uns darüber sprechen, wie und wo PI Planning tatsächlich in Ihren Unternehmenskalender passt.

Was passiert nach der PI-Planung?

Nach der Intensität der PI-Planung beginnt die eigentliche Arbeit der Umsetzung und Verfeinerung der Pläne. Der Zeitraum unmittelbar nach der PI-Planung ist entscheidend, um die Dynamik aufrechtzuerhalten und sicherzustellen, dass die Pläne in wirksame Maßnahmen umgesetzt werden.

Rückblick auf die Planung

So wie Teams nach Sprints Retrospektiven veranstalten, hilft die Durchführung einer gründlichen Retrospektive nach PI Planning dabei, zukünftige Planungsereignisse zu verbessern. In der Regel moderiert der Release Train Engineer diese Sitzung und bringt wichtige Teilnehmer zusammen, um über den Planungsprozess nachzudenken. Die Teams diskutieren über:

• Was ist gut gelaufen
• Was lief nicht so gut
• Was könnte besser sein für das nächste Mal

Dies kann Einblicke in die Vorbereitungsarbeit, die Effektivität von Team-Breakouts oder die technische Einrichtung von Teilnehmern an entfernten Standorten beinhalten.

Es wird auch eine Diskussion darüber geben, was als Nächstes passiert, was Dinge beinhalten kann wie:

• Transkribieren Sie die Ziele, Benutzerberichte und das Programmboard in Ihr Work-Management-Tool (wie Jira)
• Vereinbarung von Besprechungszeiten und -orten für tägliche Stand-ups und Iterationsplanung

Das RTE erfasst diese Erkenntnisse und arbeitet mit den Teams zusammen, um Verbesserungen für die nächste PI Planning-Veranstaltung umzusetzen.

Verfeinerung und Fertigstellung der Pläne

Die Teams verlassen PI Planning zwar mit festen Zielen, aber oft bleibt noch etwas Feinarbeit übrig. Die Teams nutzen die Tage, die auf PI Planning folgen, um:

• Passen Sie ihre Story-Backlogs auf der Grundlage der endgültigen Vereinbarungen an, die während der Planung getroffen wurden. Product Owner arbeiten mit ihren Teams zusammen, um sicherzustellen, dass die Storys richtig vorbereitet sind und für die erste Iteration bereit sind.
• Informieren Sie den Programmausschuss, um alle letzten Anpassungen zu berücksichtigen, die während der Vertrauensabstimmung und der Abschlussdiskussionen vorgenommen wurden. Das RTE stellt sicher, dass alle Abhängigkeiten ordnungsgemäß dokumentiert und für die betroffenen Teams sichtbar sind.
• Dokumentieren und kommunizieren Sie alle Risiken oder Probleme, die während der Planung festgestellt wurden und die einer kontinuierlichen Überwachung oder Minderung bedürfen.

Integration und Ausrichtung

Die Planungsphase nach dem PI ist entscheidend, um sicherzustellen, dass alle Teile kohärent zusammenpassen. Die Teams konzentrieren sich auf:

• Synchronisieren Sie ihre Iterationspläne mit anderen Teams, zu denen sie Abhängigkeiten haben, und stellen Sie sicher, dass ihre Lieferpläne mit den Bedürfnissen anderer Teams übereinstimmen.
• Einrichtung regelmäßiger Integrationspunkte und Kooperationsmechanismen, um die Abstimmung im gesamten PI aufrechtzuerhalten.
• Einrichtung klarer Kommunikationskanäle für die Verwaltung von Abhängigkeiten und den Austausch von Fortschrittsmeldungen.

Umsetzung des Aktionspunkts

Der Erfolg von PI Planning hängt letztlich davon ab, wie gut die Teams ihre Verpflichtungen einhalten. Zu den wichtigsten Aktivitäten gehören:

• Zuweisung von Eigentümern zu den während der Planung identifizierten Aktionselementen und Festlegung von Zeitplänen für die Fertigstellung.
• Einrichtung von Tracking-Mechanismen für teamübergreifende Abhängigkeiten und Risiken, die während der Planung identifiziert wurden.
• Erstellung oder Aktualisierung von Teamarbeitsvereinbarungen zur Unterstützung der neuen PI-Ziele.

Kontinuierliche Zusammenarbeit

Wenn Teams mit der Umsetzung ihrer Pläne beginnen, tragen mehrere Mechanismen dazu bei, die Abstimmung aufrechtzuerhalten:

• Regelmäßige Sync-Meetings: Teams mit Abhängigkeiten richten regelmäßige Kontaktpunkte ein, um auf dem Laufenden zu bleiben und alle aufkommenden Herausforderungen zu bewältigen.
• Bewertungen des Programmausschusses: Die RTE ermöglicht regelmäßige Überprüfungen des Programmvorstands, um sicherzustellen, dass die Abhängigkeiten eingehalten werden, und um alle erforderlichen Anpassungen zu identifizieren.
• Ereignisse untersuchen und anpassen: Während des gesamten PI nehmen die Teams an strukturierten Veranstaltungen teil, um die Fortschritte zu überprüfen, Hindernisse zu beheben und die notwendigen Anpassungen an ihren Plänen vorzunehmen.

Kommunikation und Sichtbarkeit

Die Aufrechterhaltung klarer Kommunikationskanäle nach der PI-Planung ist von entscheidender Bedeutung. Teams sollten:

• Teilen Sie die endgültigen Pläne und Ziele mit allen Beteiligten und stellen Sie sicher, dass jeder seine Verpflichtungen und Abhängigkeiten versteht.
• Richten Sie regelmäßige Berichtsmechanismen ein, um die Interessengruppen über die Fortschritte und alle wesentlichen Änderungen der Pläne auf dem Laufenden zu halten.
• Sorgen Sie für einen Überblick über wichtige Meilensteine und Integrationspunkte, damit sich Teams auf ihre Verpflichtungen konzentrieren können.

Die Planungsphase nach dem PI gibt den Ton für das gesamte Programminkrement an. Wenn Unternehmen diesen Aktivitäten besondere Aufmerksamkeit schenken, können sie den Wert ihrer PI-Planung maximieren und ihre Wahrscheinlichkeit erhöhen, ihre Ziele zu erreichen.

Die andere Sache, die normalerweise nach PI-Planing-Ereignissen passiert, ist ein Ereignis nach dem PI-Planning-Ereignis.

Was ist eine Post-PI Planning-Veranstaltung?

Diese ähneln den Pre-PI Planning-Ereignissen, die wir uns zuvor angesehen haben. Eine Veranstaltung nach der PI-Planung bringt Interessenvertreter aus allen ARTs des Solution Trains zusammen, um sicherzustellen, dass sie synchronisiert und aufeinander abgestimmt sind.

Die Post-PI-Planung erfolgt, nachdem alle ARTs ihre PI-Planung für das nächste Inkrement abgeschlossen haben. Sie stellen die Pläne vor, erläutern ihre Ziele und teilen Meilensteine und erwartete Zeitpläne mit.

Wie bei Veranstaltungen von PI Planning wird auch bei Post-PI Planning eine Plantafel verwendet, aber anstelle von Funktionen werden hier Funktionen, Abhängigkeiten und Meilensteine für jede Iteration und ART beschrieben. Potenzielle Probleme und Risiken werden identifiziert, besprochen und entweder aufgegriffen, gelöst, akzeptiert oder gemindert. Und ähnlich wie bei den regulären Veranstaltungen von PI Planning werden die Pläne einer Vertrauensabstimmung unterzogen, um sicherzustellen, dass sie die Ziele der Lösung erfüllen. Sie werden überarbeitet, bis die Teilnehmer im Durchschnitt 3 oder mehr Stimmen erhalten.

PI-Planung in SAFe

Wenn Sie SAFe zum ersten Mal anwenden, wird es wahrscheinlich mit PI Planning beginnen. Das liegt daran, dass es die Grundlage des Scaled Agile Framework bildet.

Als Agiles Skalieren sagt: „Wenn du es nicht tust, machst du kein SAFe.“

SAFe oder das Scaled Agile Framework™ ist eine Reihe von Richtlinien und Praktiken, die dazu beitragen sollen, größere Organisationen über alle Teams und Unternehmensebenen hinweg agiler zu machen. Das Framework ist auf die Verbesserung der Sichtbarkeit, Abstimmung und Zusammenarbeit ausgerichtet und sollte zu einer höheren Produktivität, besseren Ergebnissen und einer schnelleren Umsetzung führen.

Egal, ob Sie alle 5 Stufen oder nur das essentielle SAFe anwenden, die Grundlage Ihrer Transformation und der Motor für alles ist die PI Planning-Zeremonie.

Scrum und Kanban sind ebenfalls agile Frameworks (mit denen Sie vielleicht besser vertraut sind), und diese waren in der Vergangenheit auf der Ebene der einzelnen Teams sehr effektiv. SAFe hilft dabei, Agilität teamübergreifend zu skalieren; mehrere Teams kommen zusammen, um an denselben Produkten, Zielen und Ergebnissen zu arbeiten. Es geht über die Teamebene hinaus und bezieht alle Stakeholder mit ein. Es beschreibt, was auf den einzelnen Ebenen der Organisation geschehen sollte, um sicherzustellen, dass eine skalierte Planung erfolgreich ist.

Der Zweck von SAFe besteht darin, die Sichtbarkeit der Arbeit und die Abstimmung zwischen den Teams zu verbessern, was zu vorhersehbareren Geschäftsergebnissen führt.

Dies wird für Unternehmen immer wichtiger, da sie auf sich ändernde Umstände und Kundenerwartungen reagieren. Die traditionellen Wasserfallansätze greifen zu kurz, weil sie langsam und ineffizient sind.

Größere Unternehmen (oft mit Tausenden von Entwicklern) können mit der Innovation kleinerer, agilerer Startups nicht Schritt halten. Neben größeren Teams haben auch größere Unternehmen oft strengere Anforderungen in Bezug auf Governance und Compliance, was es komplexer macht, eine neue Funktion einzuführen und den Kunden einen neuen Mehrwert zu bieten.

Diese Unternehmen suchen nach neuen Möglichkeiten, Mitarbeiter in Projekten zu organisieren und effektivere Arbeitsweisen einzuführen, die Ressourcen effektiver nutzen und eine vorhersehbarere Umsetzung ermöglichen. Wenn sie das nicht tun, überleben sie möglicherweise nicht.

SAFe ist eine Möglichkeit für diese Unternehmen, sich in eine agilere Richtung zu bewegen.

PI Planning ist ein wichtiges Element von SAFe. Es handelt sich um eine Zeremonie, bei der Vertreter aller Teams zusammenkommen, um ihnen bei der Zusammenarbeit zu helfen, die wichtigsten Funktionen auszuwählen, an denen sie als Nächstes arbeiten möchten, Abhängigkeiten zu identifizieren und einen Plan für das nächste Programminkrement zu erstellen. Dadurch sind alle Teams besser sichtbar, Änderungen werden häufiger vorgenommen und die Teams arbeiten miteinander — nicht gegeneinander. Von dort aus können diese großen Unternehmen ihre Prozesse beschleunigen, effizienter arbeiten, mit neueren und flexibleren Unternehmen konkurrieren und ihre Rentabilität aufrechterhalten.

SAFe und PI Planning sind leistungsstarke Wegbereiter für organisatorische Agilität.

SAFe ist zwar ein Framework, das für größere Organisationen entwickelt wurde, aber es gibt keinen Grund, kleinere Unternehmen davon abzuhalten, auch eine Version von PI Planning zu verwenden. Alles, was Sie brauchen, ist mehr als ein agiles Team, damit es sich lohnt.

PI-Planung in Scrum

Sie können PI Planning auch als Teil eines einfachen Scrum-Ansatzes verwenden.

Das Scrum Framework-Diagramm zeigt, wann und wie Scrum-Teams PI Planning implementieren können

Quelle: Scrum.org

Scrum ist ein agiles Framework, das Teams hilft, Dinge zu erledigen. Es ist eine Möglichkeit für Teams, ihre eigene Arbeit zu planen und zu organisieren und Benutzergeschichten und Aufgaben in kleineren Zeitfenstern anzugehen. Dies wird oft als Sprint bezeichnet.

Wenn mehrere Scrum-Teams besser zusammenarbeiten möchten (aber nicht unbedingt innerhalb von SAFe arbeiten), könnten sie eine Version von PI Planning übernehmen.

Diese Scrum-Teams könnten zum Beispiel:

• Treffen Sie sich alle 10 Wochen und besprechen Sie die Funktionen, an denen sie arbeiten möchten
• Lassen Sie Produktmanager Backlogs kombinieren und gemeinsam Prioritäten setzen
• Teilen Sie Ressourcen nach Bedarf zwischen den Teams
• Ordnen Sie Abhängigkeiten zu und koordinieren Sie gemeinsame Veröffentlichungen

Die gute Nachricht dabei ist, dass es für PI Planning keinen Universalansatz gibt. Denken Sie also darüber nach, wie Sie die Ideen und Prinzipien übernehmen und für Ihr Unternehmen und Ihren Kontext nutzbar machen können.

Was ist der Unterschied zwischen einer PI-Roadmap und einer Solution Roadmap?

In SAFe gibt es verschiedene Arten von Roadmaps. Daher ist es wichtig, die Unterschiede zu verstehen und zu verstehen, wofür jede Roadmap gedacht ist.

PI-Roadmap

Eine PI-Roadmap wird vor Ihrer PI Planning-Veranstaltung erstellt und auch nach Abschluss der Veranstaltung vom Produktmanagement überprüft und aktualisiert. Sie umfasst in der Regel drei Programminkremente:

1. Die aktuelle Erhöhung (geleistete Arbeit)
2. Die nächste prognostizierte Erhöhung (geplante Arbeit auf der Grundlage der prognostizierten Ziele)
3. Der Anstieg danach (weitere geplante Arbeiten auf der Grundlage der prognostizierten Ziele)

Die vierteljährliche PI-Planung wird einen Arbeitsaufwand von rund 9 Monaten vorsehen. Die zweite und dritte Stufe Ihrer PI-Roadmap werden sich wahrscheinlich ändern, wenn sich die Prioritäten ändern, aber sie sind immer noch ein wichtiger Teil der Roadmap, da sie vorhersagen, wohin sich das Produkt als Nächstes entwickeln wird.

Lösungs-Roadmap

Die Solution Roadmap ist ein längerfristiges Prognose- und Planungstool für ein bestimmtes Produkt oder eine bestimmte Dienstleistung.

Es deckt in der Regel mehrere Jahre am Stück ab, wobei für das erste Jahr spezifischere Details (wie vierteljährliche Funktionen und Funktionen) und allgemeinere Informationen (wie Ziele) für das zweite Jahr und darüber hinaus verfügbar sind.

‍

Haben Sie eine Schlüsselrolle bei PI Planning? Erfahren Sie, wie das richtige Tool Ihnen helfen kann, Ihren Release-Train oder Ihr Programm besser zu verwalten.

Sehen Sie sich eine Produktdemo von Easy Agile Programs an

‍

Fern- oder hybride PI-Planung

Persönliche PI-Planung war früher Standard, aber da die Wahrscheinlichkeit, dass Teams verteilt sind, höher ist, ist es nicht immer möglich, alle im Büro zu versammeln. Das muss kein Hindernis sein.

Das wichtigste Prinzip besteht darin, sicherzustellen, dass die Teams, die die Arbeit erledigen, in Echtzeit, wenn nicht sogar persönlich, in der Planung „anwesend“ sein können.

Dies kann einige Anpassungen der Agenda und des Zeitplans Ihrer Planung erfordern, aber mit Voraussicht und Unterstützung durch die richtige Technologie wird Ihre PI-Planung immer noch effektiv sein.

Tipps für die PI-Planung aus der Ferne

Remote PI Planning ist ideal für Organisationen mit verteilten Teams oder flexiblen Arbeitsregelungen. Es ist auch viel billiger und weniger störend, als alle paar Monate Leute hereinzubringen, um PI-Planung durchzuführen. Wenn Sie über die richtigen Tools und Technologien verfügen, können Sie PI Planning ausführen und allen die Teilnahme ermöglichen, unabhängig davon, ob sie sich im selben Raum oder am anderen Ende der Welt befinden.

Hier sind ein paar Tipps für die Remote-PI-Planung:

Nutzen Sie die Cloud

Verwenden Sie gemeinsam genutzte Online-Planungstools, damit Ihr Team so schnell wie möglich auf Informationen zugreifen und mit ihnen interagieren kann — idealerweise in Echtzeit. Wenn Sie sicherstellen, dass alle Beteiligten sofortigen Zugriff auf die Informationen haben, können Sie Abhängigkeiten leichter identifizieren und einen zentralen Bezugspunkt für Ihre Planung beibehalten. Auf diese Weise können Fehler vermieden werden, die durch die Arbeit mit verschiedenen Versionen und die Übertragung von Daten zwischen Quellen entstehen.

Die Veranstaltung im Livestream streamen

Das Live-Streaming von Audio und Video von der PI Planning-Veranstaltung ist eine praktikable Alternative zur persönlichen Planung. Ermutigen Sie Ihre Teammitglieder an entfernten Standorten aktiv, ihre Kameras und Mikrofone während der Veranstaltung zu benutzen. Auch wenn es die Erfahrung, sie physisch anwesend zu haben, vielleicht nicht vollständig wiedergibt, kommt es doch erstaunlich nah.

Nehmen Sie das PI Planning-Ereignis auf

Im Idealfall nehmen alle live an der PI-Planung teil. Wenn Ihre Teams jedoch auf mehrere Zeitzonen verteilt sind oder einige Teammitglieder krank sind, ist es eine gute Idee, das Ereignis aufzuzeichnen. Eine Aufzeichnung zum Nachschlagen zu haben, kann auch für Teilnehmer nützlich sein, die sich über alles, was besprochen wurde, auffrischen möchten.

Sei bereit, dich anzupassen

Einige Teams ändern die standardmäßige PI-Planungsagenda, um sie an mehrere Zeitzonen anzupassen, was für einige bedeuten kann, dass die Veranstaltung früher oder später beginnt oder sie sogar über 3 statt 2 Tage läuft.

Erwartungen setzen

Ein häufiges Problem, das entstehen kann, wenn sich verteilte Teams aus der Ferne einschalten, sind zu viel Lärm und Interferenzen. Kommunizieren Sie vor Beginn Ihrer ersten Sitzung darüber, wann ein Gespräch zulässig ist und wann die Teams die Stummschalttaste verwenden müssen. Auf diese Weise vermeiden Ihre Teams, abgelenkt zu werden, und stellen gleichzeitig sicher, dass alle teilnehmen können.

Weitere Tipps finden Sie in unserem Blog unter wie bereite ich mich auf die verteilte PI-Planung vor?.

Ob verteilt oder persönlich, wenn Ihr Team die PI-Planung richtig macht, macht das alles in den kommenden Schritten um einiges einfacher.

📣 Erfahren Sie, wie PNI Media die virtuelle PI-Planung eingeführt hat

Häufige PI-Planungsfehler

PI Planning läuft nicht immer reibungslos, besonders beim ersten Mal. Und das Framework selbst kann für einige Organisationen eine Herausforderung darstellen. Hier sind einige häufige Fehler und Herausforderungen, die es zu beachten (und zu vermeiden) gilt:

Lange, langweilige Sessions

Vermeiden Sie es, Ihre PI Planning-Veranstaltung mit langen Sitzungen mit dichtem Inhalt zu beginnen. Überlegen Sie sich kreative Möglichkeiten, um diese Sitzungen ansprechender zu gestalten, oder teilen Sie sie in kürzere Sitzungen auf. Erwägen Sie verschiedene Formate, die dazu beitragen, die Teilnehmer einzubeziehen und einzubeziehen. Und achten Sie darauf, Platz für Teamplanung und Zusammenarbeit zu schaffen.

Technische Probleme

Jede Veranstaltung ist anfällig für technische Pannen, aber wenn Sie Audio und Video an ein verteiltes Team streamen, kann dies den Ablauf der Veranstaltung erheblich beeinträchtigen. Es ist eine gute Idee, alle Geräte und Verbindungen im Voraus sorgfältig zu testen, um potenzielle Probleme zu minimieren.

Vertrauensvotum

Einige Teilnehmer von PI Planning haben Probleme mit dem Konzept der Vertrauensabstimmung. Es kann sein, dass die Teilnehmer den Druck aus dem Saal verspüren, für einen Plan zu stimmen, der umgesetzt werden soll, anstatt ihre Bedenken zu äußern. Wenn Probleme nicht frühzeitig angegangen werden, erhöht sich nur das Risiko, dass während der Erhöhung etwas schief geht.

Zeitliche Einschränkungen

Wenn Sie ein großes ART mit 10 oder mehr Teams haben, müssen Sie viele Planentwürfe präsentieren und überprüfen, sodass jedem Team weniger Zeit zur Verfügung steht. Es besteht die Möglichkeit, dass das Feedback von schlechterer Qualität ist als bei einem kleineren ART mit 8 Teams.

Ich verpflichte mich nicht zu dem Prozess

PI Planning ist nicht perfekt und SAFe auch nicht. Es hat sich jedoch gezeigt, dass der Prozess für viele Organisationen funktioniert, wenn die Organisation engagiert ist. Beginnen Sie wie empfohlen mit dem vollständigen Framework. Sie können das Framework und Ihre PI Planning-Veranstaltung an Ihre Organisation anpassen, aber achten Sie darauf, dass Sie sich auf den nachfolgenden Prozess festlegen. Alles, was zur Hälfte abgeschlossen ist, liefert keine vollständigen Ergebnisse.

Ich bleibe bei den gleichen alten Werkzeugen

Wenn etwas nicht funktioniert, repariere es. Zum Beispiel bleiben zu viele Teams bei herkömmlichen SAFe-Programmboards, obwohl diese nicht immer praktisch sind. Wenn die Haftnotizen immer wieder verschwinden, die in Jira eingegebenen Daten falsch zu sein scheinen oder Sie ein verteiltes Team haben, das auf digitale Weise Teil Ihrer PI Planning-Veranstaltung sein möchte... ist es an der Zeit, auf eine digitale Programmtafel umzusteigen wie Einfache agile Programme.

Sind Sie bereit, PI Planning in Ihrem Unternehmen zu implementieren? Wir haben eine Checkliste erstellt, um Ihnen den Einstieg zu erleichtern.

Kostenlose Checkliste für die PI-Planung

Eine effektive PI-Planung erfordert eine sorgfältige Koordination. Diese Checkliste beschreibt die wichtigsten Schritte, von der Planung der Aktivitäten vor der Veranstaltung bis hin zur Nachbereitung der Veranstaltung, um sicherzustellen, dass nichts übersehen wird.

KOSTENLOSER DOWNLOAD

Es beinhaltet:

• Vorbereitung der Veranstaltung — Logistik, Tools und Inhaltseinrichtung
• Pre-PI-Planung — Wichtige Aktivitäten zur Abstimmung der Interessengruppen
• Tagesordnungen für Tag 1 und Tag 2 — Eine strukturierte Aufschlüsselung der Sitzungen
• Rollenspezifische Verantwortlichkeiten — Klare Richtlinien für jeden Teilnehmer
• Überlegungen zu Remote-/Hybridanwendungen — Tipps für verteilte Teams
• Planungsmaßnahmen nach dem PI — Schritte, um die Dynamik aufrechtzuerhalten

Laden Sie Ihre PI-Planungs-Checkliste kostenlos herunter.

Sobald Sie Ihre Checkliste und Ihren Prozess eingerichtet haben, sollten Sie die richtigen Tools zur Unterstützung Ihrer PI-Planungssitzungen in Betracht ziehen. Wir sind vielleicht voreingenommen, denken aber, dass Easy Agile Programs + Jira die beste Wahl ist.

Jira für PI-Planung verwenden

Jira ist das beliebteste Projektmanagement-Tool für agile Teams. Wahrscheinlich verwenden Sie es bereits auf Teamebene.

Wenn du die Agilität des Teams im Rahmen einer ART skalieren musst, kann es schwierig sein, die Arbeit mehrerer Teams in Jira richtig zu visualisieren. Die einzige Möglichkeit, dies in der nativen App zu tun, besteht darin, ein Board für mehrere Projekte zu erstellen, was ziemlich umständlich ist.

Traditionelle PI-Planung auf einer physischen Tafel mit Haftnotizen und Schnüren kann die Planungsziele für Teams am gleichen Standort erreichen, aber was passiert als Nächstes? Nachdem die Sitzung beendet ist, müssen die Notizen und die Zeichenfolge in Jira für das gesamte Team neu erstellt werden, damit die Arbeit während des gesamten Inkrements nachverfolgt werden kann. Dies ist ein umständlicher und zeitaufwändiger Prozess, bei dem Fehler auftreten können, da Haftnotizen falsch transkribiert werden oder verloren gehen.

Der beste Weg, Jira für PI Planning zu verwenden, ist die Verwendung einer App wie Einfache agile Programme um Ihnen bei der Durchführung Ihrer PI Planning-Sitzungen zu helfen. Dank der integrierten Funktionen können Sie:

• Richte eine digitale Programmtafel ein (keine Schnüre und Haftnotizen mehr!)
• Führen Sie teamübergreifende Planung durch
• Visualisieren und verwalten Sie teamübergreifende Abhängigkeiten, erstellen Sie Meilensteine
• Identifizieren Sie Planungskonflikte, um Risiken zu minimieren
• Stimmen Sie sich auf feste Ziele für den Programminkrement ab
• Visualisieren Sie eine Roadmap für inkrementelle Funktionen
• Vertrauensabstimmung durchführen
• Verwandle Jira von einem Tool auf Teamebene in etwas, das für die gesamte ART nützlich ist

Schließe dich Unternehmen wie Bell, Cisco und der Deutschen Bahn an, die Jira für PI Planning mit verwenden Einfache agile Programme (aus dem Atlassian Marketplace).

Sie suchen ein PI-Planungstool für Jira?

Wir werden uns diesen Leitfaden auch in Zukunft noch einmal ansehen. Wenn Sie Fragen zu PI Planning haben oder feststellen, dass es einen Aspekt gibt, den wir noch nicht behandelt haben, schick uns eine E-Mail 📫

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

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

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

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

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

Was ist User Story Mapping?

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

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

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

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

Nicholas Muldoon, Mitbegründer @Easy Agile

Was ist kein User Story Mapping?

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

User Story Mapping im Vergleich zu Journey Mapping

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

User Story Mapping im Vergleich zu Event Storming

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

User Story Mapping für agile Teams

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

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

Das passt genau zum Agilen Manifest.

Und vergessen wir nicht das Agile-Prinzip Nummer eins:

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

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

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

Die Anatomie einer User Story Map

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

Geschichten von Nutzern

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

User Stories folgen normalerweise der Struktur:

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

Zum Beispiel:

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

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

Epen

Geschichten können mit Epen in Verbindung gebracht werden.

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

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

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

Das Rückgrat

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

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

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

Mehr zu: Die Anatomie einer User Story Map

Warum User Story Mapping durchführen?

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

Du wirst die Antwort kennen auf:

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

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

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

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

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

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

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

Lesen ➡️ Warum User Story Mapping

Vorteile von User Story Mapping

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

Nicholas Muldoon, Mitbegründer @Easy Agile

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

Risiko visualisieren

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

Priorisierung und Ressourcenzuweisung

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

Förderung schlanker Alternativen

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

Förderung der kollaborativen Problemlösung

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

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

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

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

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

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

‍

Der flache Backlog im Vergleich zum User Story Mapping

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

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

Was ist ein flacher Backlog?

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

Aber ich mag unseren Backlog!

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

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

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

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

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

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

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

Wann wird das User Story Mapping durchgeführt?

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

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

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

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

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

Das Beste aus User Story Mapping herausholen

Wer sollte am User Story Mapping teilnehmen?

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

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

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

Abbildung der User Stories

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

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

Sequenzierung

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

Linien oder Schwimmbahnen abschneiden

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

Lesen ➡️ Anatomie einer agilen User Story Map.

Tipps für ein erfolgreiches User Story Mapping

Beziehen Sie die richtigen Leute ein

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

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

Mach Schluss

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

Nicholas Muldoon, Mitbegründer @Easy Agile

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

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

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

Ein einziger Moderator

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

Keine Telefone/Laptops

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

Beginnen Sie mit Daten und Beweisen

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

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

Ansätze zur Zuordnung von User Storys

Beispiel für das Mapping von User Storys

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

• Identifizieren Sie das Produkt/das Ergebnis

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

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

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

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

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

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

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

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

Teilen Sie es auf Releases oder Sprints auf

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

Eine User Story Mapping... Story

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

Schritt 1: Kick Off

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

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

Schritt 2: Identifizierung der Person

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

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

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

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

Schritt 3: Die großen Schritte

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

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

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

Schritt 4: Die Geschichten

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

Schritt 5: Linien abschneiden

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

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

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

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

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

Ergebnisse 🏆

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

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

Physisches versus digitales User Story-Mapping

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

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

Es könnte ein bisschen so aussehen:

Dieser Prozess bringt jedoch einige Herausforderungen mit sich:

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

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

Nicholas Muldoon, Mitbegründer @Easy Agile

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

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

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

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

Jira + Einfacher agiler TeamRhythm

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

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

So funktioniert das:

Funktionen zur Zuordnung von User Storys zu Jira hinzufügen

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

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

Richte dein Rückgrat ein

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

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

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

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

Füge das Fleisch hinzu (oder Geschichten!)

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

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

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

Bestelle deine Epen und Geschichten

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

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

Arbeit schätzen

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

Lesen ➡️ Agile Schätzungstechniken

Swimlanes hinzufügen und anordnen (Version/Sprint)

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

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

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

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

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

Probiere verschiedene Ansichten aus

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

An die Arbeit!

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

Erste Schritte mit Easy Agile TeamRhythm

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

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

Kostenlose Testversion von Easy Agile TeamRhythm

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

TeamRhythm Highlights-Tour

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

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

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

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

- Mike Doolittle, Produktdirektor @Priceline

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

- Casey Flynn, Analyst für Vertriebsprognosen @adidas

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

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

Sehen Sie, worum es bei der ganzen Aufregung geht

Starten Sie Ihre kostenlose 30-Tage-Testversion

Einfacher agiler Teamrhythmus

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

6 Möglichkeiten, deine Storymap am Leben zu erhalten

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

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

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

1. Verfolgung des Fortschritts

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

2. Pflege des Backlogs

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

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

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

3. Sprint-/Release-Planung

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

4. Sprint-Bewertungen

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

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

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

5. Straßenkarten

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

6. Rückblicke

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

So erfahren Sie mehr über User Story Mapping

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

Hier sind einige Ressourcen, die einen Blick wert sind:

Bücher zum Mapping von Nutzergeschichten

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

Artikel zum Mapping von User-Storys

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

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

Wie schreibt man gute User Stories in der agilen Softwareentwicklung

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

Anatomie einer agilen User Story Map

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

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

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

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

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

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

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

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

Was ist falsch an flachen User Story Backlogs?

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

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



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



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

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

Mängel eines flachen Produktrückstands

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

Story-Maps von Benutzern

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

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

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

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

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

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

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

Einfacher agiler Teamrhythmus

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

Vor ein paar Wochen hat unser Partner Adaptavist veröffentlichte ihren State of the Atlassian Ecosystem Report, in dem rund 1.000 Nutzer von Atlassian-Tools und -Services befragt wurden. Nachdem ich das über 50-seitige Dokument gelesen hatte, kam ich zu dem Schluss, dass die Erkenntnisse der Berichte äußerst wertvoll und es wert sind, geteilt zu werden.

Sie können auch den vollständigen Bericht herunterladen hier. Es ist eine fantastische Lektüre und unglaublich interessant für jeden, der im Atlassian-Ökosystem arbeitet.

Wichtige Erkenntnisse vom Chief Information Officer bei Adaptavist

• Trotz eines turbulenten Jahres wächst und entwickelt sich das Atlassian-Ökosystem weiter. In diesem Jahr übertraf das Unternehmen zum ersten Mal den Quartalsumsatz von 500 Millionen US-Dollar
• Für diejenigen, die sich auf Atlassian Server verlassen, hat die Entscheidung des Unternehmens, seine Serverprodukte einzustellen, einige Überlegungen angestellt und schwierige Entscheidungen erzwungen
• Atlassian konzentriert sich weiterhin darauf, Verbesserungen in den Bereichen Sicherheit, Anpassung und Funktionsparität voranzutreiben
• Lassen Sie uns die Zusammenarbeit im gesamten Ökosystem eröffnen und neue Wege finden, um die vor uns liegenden Herausforderungen zu bewältigen.

Wichtigste Ergebnisse

• Verbrauch steigt: Die Nutzung von Atlassian ist gestiegen, obwohl die IT-Ausgaben insgesamt gesunken sind. Einschließlich Jira, Access, Trello, Align und Advanced Roadmaps
• Nicht technisch versierter Nutzer: Zunahme der Teams ohne technischen Hintergrund, die Atlassian-Tools wie Operations und Marketing verwenden.
• Herausforderung: Die größte Integrationsherausforderung für Unternehmen besteht darin, Atlassian mit anderen Drittanbieter-Apps wie Zoom, MS Office, Slack, Gitlab, Github und Salesforce zu verbinden.
• Wolke: Die Akzeptanz von Atlassian Cloud nimmt langsam aber sicher zu: 28% 2020 bis 34% 2021. Server machen den Großteil der Bereitstellung aus, gefolgt von DC
• Herausforderung: Anpassung (57% besorgt), App-Integration (48% besorgt), Kosten und Funktionsfunktionen (43% besorgt) sind die wichtigsten Bedenken bei der Migration zu Atlassian Cloud
• Einsatz ändern: 65% der Befragten gehen davon aus, dass sie die Art und Weise, wie sie Atlassian-Produkte einsetzen, in den nächsten drei Jahren ändern werden. Der Ausfall des Servers hat dies vorangetrieben.
• Was die Leute wollen mehr Automatisierung - treibt Geschäftsprozesse voran, senkt die Betriebskosten und verbessert die Integration mit Tools
• DevOps ist da: 27% der Befragten entwickeln in den nächsten 3 Jahren eine DevOps-Strategie. Akzeptanz in allen Branchen. Warum? Automatisiert Arbeitsabläufe, schnellere Entwicklungszyklen, bessere Koordination zwischen Teams, kürzere Markteinführungszeiten. Warum nicht? Mangelnde Fähigkeiten, unzureichende Schulung, unzureichendes Budget (Genau wie die Vorteile, die Organisationen von DevOps erwarten können!)
• Agile Adoption Up, aber Hindernisse für eine Skalierung der Bemühungen: 67% der großen Unternehmen (> 5.000 Mitarbeiter) verfolgen hohe Absichten zur Einführung agiler Methoden. Die Einführung von Agile in großem Maßstab ist von 10% im Jahr 2020 auf 49% im Jahr 2021 gestiegen. Die größten Hindernisse für die Einführung von Agile at Scale: andere Prioritäten, aktuelle Methode funktioniert einwandfrei, unklarer ROI. Warum wollen Organisationen Agile in großem Maßstab einführen? Bessere Teamkoordination, Abstimmung von Strategie und Umsetzung, erhöhte Sichtbarkeit.

Die Stakeholder auf dem Laufenden zu halten, ist eine der Hauptaufgaben eines Product Owners. Hinter den Kulissen wird eine Menge Arbeit geleistet, bevor den Stakeholdern Informationen über die Ergebnisse und den Zeitplan eines Produkts präsentiert werden können. Wenn Sprints Ihr Framework für die Erledigung der Arbeit und die Prognose von Lieferterminen sind, muss das agile Entwicklungsteam sicherstellen, dass es den Produkt-Backlog im richtigen Tempo abarbeitet. Das Sprint-Burndown-Diagramm kann Ihnen den Weg weisen.

In diesem Beitrag werden wir darüber sprechen, wie Sie anhand eines Sprint-Burndown-Diagramms überwachen können, ob Ihr Team auf dem richtigen Weg ist, seine Arbeit abzuschließen, und wie die Einbindung von User Stories in Sprints und Epics mithilfe von User Story Maps zu noch besseren Erkenntnissen führt.

Was ist ein Sprint-Burndown-Diagramm?

Bildquelle: Atlassian

Zuerst eine Bewertung: A Sprint ist ein fester Zeitraum — in der Regel zwischen zwei und vier Wochen —, den ein agiles Softwareentwicklungsteam verwendet, um eine definierte Reihe von Arbeiten abzuschließen.

Ein Sprint-Burndown-Diagramm ist ein visueller Vergleich, wie viel Arbeit während eines Sprints abgeschlossen wurde und wie viel Arbeit insgesamt noch übrig ist. Es hilft dabei, den Fortschritt eines Scrum-Teams zu messen, und es bietet einen einfachen Überblick darüber, ob das Team Anpassungen vornehmen muss, um seine Arbeit für die aktuelle Sprint-Iteration abzuschließen.

Ein Burndown-Diagramm ist ein Graph mit einer Y-Achse und einer X-Achse 📉. Die vertikale Achse misst den Gesamtaufwand an Arbeit, den das Team nach Schätzungen im aktuellen Sprint erledigen wird. Die horizontale Achse zeigt die Anzahl der verbleibenden Tage bis zum Ende des Sprints. Auf dem Diagramm befinden sich zwei Linien: die tatsächliche Arbeitslinie (eine Linie, die den Fortschritt des Teams darstellt) und die ideale Arbeitslinie (eine gerade Linie vom oberen Ende der Y-Achse bis zum Ende der X-Achse).

Sie möchten, dass Ihre tatsächliche Arbeitslinie Ihrer idealen Arbeitslinie so genau wie möglich folgt. Das würde bedeuten, dass die Arbeit schrittweise und mit einer solchen Geschwindigkeit abgeschlossen wird, dass sie bis zum Ende des Sprints abgeschlossen werden kann. Sprintziel erreicht. 👍

Für den Product Owner eines Teams empfiehlt es sich, das Burndown-Diagramm täglich zu überprüfen. Auf diese Weise können Sie feststellen, ob während des Sprints Fortschrittsprobleme auftreten. Wenn Ihre tatsächliche Arbeitslinie beispielsweise tendenziell über der idealen Arbeitslinie liegt, bleibt zu viel Arbeit übrig, um bis zum Ende des Sprints im aktuellen Tempo erledigt zu werden. Wir werden später in diesem Beitrag einige Gründe aufschlüsseln, warum das passieren könnte. 😉

Das Sprint-Burndown-Diagramm ist auch ein großartiges Tool für die Verwendung während einer Sprint-Rückblick. Wenn man das als Team betrachtet, kann das helfen, Diskussionspunkte zu den drei wichtigsten Fragen der Sprint-Retrospektive zu generieren: Was lief im Sprint gut? Was lief nicht so gut, wie wir es uns erhofft hatten? Wie können wir im nächsten Sprint besser werden?

Eine Einführung in Schätzmethoden

Um den Kraftaufwand auf der vertikalen Achse zu messen, müssen wir eine Metrik wählen.

In der Vergangenheit nutzten traditionelle Softwareteams Zeit, um den Aufwand abzuschätzen, der für die Fertigstellung einer Aufgabe oder eines Projekts erforderlich war. Zum Beispiel: „Ich denke, ich werde drei Tage brauchen, um diese User Story fertigzustellen.“ Dieser Ansatz kann jedoch riskant sein, weil Menschen neigen dazu, zu unterschätzen die Zeit, die benötigt wird, um ein Projekt abzuschließen.

Die Maßeinheit auf der Y-Achse Ihres Sprint-Burndown-Diagramms hängt von Ihrem ab Schätzungsmetrik nach Wahl. Sehen wir uns zwei gängige Methoden an, die von agilen Sprint-Teams eingesetzt werden.

Ideale Tage

Ein idealer Tag ist eine Schätzung eines Softwareentwicklers, wie viele ununterbrochene Tage es dauern wird, eine Aufgabe zu erledigen. Unter der Annahme, dass ein idealer Arbeitstag aus acht Stunden unterbrechungsfreier Arbeit besteht, könnte die Schätzung wie folgt ausgedrückt werden: „Für diese Benutzergeschichte brauche ich idealerweise zwei Tage.“ Ein Vorteil dieses Ansatzes besteht darin, dass Arbeitsunterbrechungen berücksichtigt werden. Er kann jedoch problematisch sein, da Schätzungen häufig als Best-Case-Szenarien betrachtet werden.

Story-Punkte

Agile Teams nutzen Storypoints als relative Schätzung des Aufwands im Gegensatz zu einem zeitbasierten Ansatz. Anstatt zu sagen: „Ich glaube, ich werde zwei Tage brauchen, um diese Aufgabe zu erledigen“, würden Sie sagen: „Ich denke, diese Aufgabe ist zwei Storypoints wert.“ Bei dieser Schätzmethode sind zwei Storypoints doppelt so viel Aufwand wie ein Storypoint.

Teams können ideale Tage als Grundlage verwenden, um ihre Story-Point-Schätzungen zu kalibrieren. Ein idealer Tag kann beispielsweise einem Story Point entsprechen, zwei ideale Tage zwei Story Points usw.

Ein Hauptvorteil der Verwendung Storypoints Eine Schätzung bedeutet, dass Teams sich so auf den relativen Aufwand konzentrieren können, anstatt darüber nachzudenken, wie lange es dauern wird, eine Aufgabe zu erledigen.

Warum dein Sprint-Burndown aus dem Ruder laufen könnte

Eine perfekte echte Burndown-Linie ist wie Bigfoot — wenn sie beobachtet wurde, ist es wahrscheinlich ein Scherz. 😂

Kein Team kann seine Arbeit perfekt einschätzen und sich genau in dem Tempo entwickeln, das die Ideallinie vorgibt. Wenn Sie jedoch große Unterschiede zwischen Ihrer tatsächlichen Linie und der Ideallinie feststellen (d. h., Ihre tatsächliche Linie ist viel höher oder niedriger als die Ideallinie), können eine Reihe von Dingen passieren:

• Das Team hat sich zu viel oder zu wenig mit dem Arbeitsaufwand bei der Sprint-Planung beschäftigt
• Story Points wurden dem Sprint hinzugefügt oder daraus entfernt, nachdem er gestartet wurde (Scope Creep)
• Der geschätzte Aufwand für einige User Stories ist falsch

Wenn Sie als Product Owner nach Ihrer täglichen Überprüfung Ihres Diagramms feststellen, dass etwas an Ihrer Linie nicht stimmt, sollten Sie dies Ihren Teammitgliedern gegenüber erwähnen. Das tägliche Stand-up ist der perfekte Zeitpunkt dafür.

User Stories und Epen liefern das große Ganze

Geschichten von Nutzern beschreiben, wie ein funktionaler Teil eines Produkts aus der Sicht eines Benutzers funktionieren wird. Das übliche Format einer User Story lautet: „Als [Benutzerrolle] möchte ich [Benutzeraktivität], damit ich [Benutzerziele] erreichen kann.“ Zum Beispiel könnte man lesen: „Als neuer Kunde möchte ich mich für dieses Produkt registrieren, damit ich mein Profil erstellen kann.“

User Stories werden in Sprints platziert, um zu zeigen, welche Arbeiten (aus Nutzersicht) bis wann abgeschlossen sein werden. Sie können auch platziert werden Epen um sie innerhalb eines Produkts nach Themen zu gruppieren. Epics werden häufig von agilen Teams verwendet, um die Aktivitäten auf hohem Niveau darzustellen, die Benutzer bei der Verwendung eines Produkts ausführen.

In unserem Beispiel oben kann ein Epic alle Nutzerberichte erfassen, die sich auf die Benutzerregistrierung beziehen, z. B. die Registrierung, das Hinzufügen von Zahlungsinformationen, das Erstellen eines Benutzerprofils und das Konfigurieren von Benachrichtigungseinstellungen.

Wenn der Sprint-Burndown darauf hindeutet, dass das Team bei einem bestimmten Sprint nicht auf der Strecke ist, kann dir eine kombinierte Ansicht von Sprints und Epen dabei helfen, herauszufinden, welche Auswirkungen das auf das Gesamtbild haben könnte. Und wie wir als Nächstes sehen werden, kann eine interaktive User Story Map das Problem lösen.

User Story Maps: Ein Überblick über Epen und Sprints

Ein Sprint-Burndown-Diagramm ist eines der praktischsten Tools, die ein agiles Softwareentwicklungsteam verwenden kann, um sicherzustellen, dass es in einem soliden Tempo arbeitet und liefert. Das Burndown-Diagramm zeigt, ob Anpassungen an Ihrem Sprint vorgenommen werden müssen.

User-Story-Maps bieten weitere Einblicke in den Teamfortschritt, indem Sie:

• Sprints als vertikale Schwimmbahnen anzeigen
• Anzeige von Epen als Spalten, die die Benutzerreise durch das Produkt darstellen

Diese Kombination aus Swimlanes und Columns verringert deinen Sprint-Backlog. Es visualisiert, was das Team liefern wird und bis wann.

Mit Einfache Agile User Story Maps für Jira, kannst du deine Fähigkeit verbessern, Anpassungen an deinem Sprint vorzunehmen. Es kann dir helfen:

• Neue User Stories erstellen
• Story Points in einer User Story bearbeiten
• Ordne Gegenstände im Backlog einem Epic und einem Sprint zu

Mit diesem Tool können Teams ihre Sprint-Statistiken auf einen Blick einsehen und Maßnahmen ergreifen. Sie können sicherstellen, dass sie sich nicht zu sehr verpflichten und dass sie auf dem richtigen Weg sind, ihre Sprintziele zu erreichen. Es ist die umfassendste User-Story-Map-Lösung der Jira-Marktplatz dafür, dass Sie Maßnahmen ergriffen haben, um Ihre Sprints aus der Sicht des Gesamtbildes anzupassen.

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

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

Ein Überblick über den Scrum-Prozess

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

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

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

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

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

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

Einfache Sprint-Planung:

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

PROBIERE: TEAMRHYTHM SANDBOX DEMO

Was macht ein gutes Sprintziel aus?

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

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

1. Das Ziel ist erreichbar

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

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

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

2. Das Team versteht die Definition von erledigt

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

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

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

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

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

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

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

Einfacher agiler Teamrhythmus

VERSUCHE ES JETZT

4. Das Sprintziel entspricht den allgemeinen Produktzielen

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

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

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

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

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

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

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

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

MACHEN SIE EINE PRODUKTTOUR

Ein kundenorientierter Ansatz

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

✅ Stellen Sie sicher, dass das Ziel erreichbar ist.

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

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

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

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

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

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

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

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

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

Der Zweck der Sprint-Retrospektive

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

Ein Sprint-Rückblick:

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

Wie die Sprint-Retrospektive in den Scrum-Prozess passt

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

Ein Scrum-Team hat drei Arten von Rollen:

• Inhaber des Produkts
• Scrum Master
• Entwicklungsteam

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

Das Scrum besteht aus vier verschiedene Zeremonien oder Veranstaltungen:

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

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

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

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

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

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

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

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

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

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

2. Starten, stoppen, weitermachen

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

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

3. Legen Sie bestimmte Aktionspunkte fest

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

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

4. Rückblick — der Rückblick

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

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

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

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

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

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

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

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

❌ Keine Stärkung leiser Stimmen

❌ Ohne gründliche Diskussion voreilige Schlüsse ziehen

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

❌ Die Aktionspunkte der vorherigen Retrospektive vergessen oder nicht umgesetzt

❌ Überspringen einer Retrospektive aus Zeit- oder Ressourcenmangel

❌ Vergessen der Bedürfnisse von Stakeholdern und Kunden

❌ Es gelingt Ihnen nicht, Ihren retrospektiven Prozess zu verbessern

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

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

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

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

EASY AGILE TEAMRHYTHM KOSTENLOS TESTEN

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

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

Was ist ein Sprint Planning-Meeting?

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

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

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

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

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

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

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

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

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

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

Wie bereitest du dich auf die Sprint-Planung vor?

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

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

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

Wie sollte das Treffen ablaufen?

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

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

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

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

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

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

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

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

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

Wenn wir dir einen Rat geben sollten...

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

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

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

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

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

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

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

Starke Sprint-Planung macht Ihr Projekt stärker

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

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

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

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

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

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