Agile Best Practice

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

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

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

Was sind Produktmanagement-Softwaretools?

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

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

Entwicklungsteams können Roadmapping-Tools verwenden, um:

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

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

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

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

1. Jira

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

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

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

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

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

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

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

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

2. Trello

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

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

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

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

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

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

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

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

3. Wrike

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

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

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

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

Die wichtigsten Funktionen von Wrike sind:

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

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

4. Produktboard

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

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

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

Zu den Hauptfunktionen von Productboard gehören:

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

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

5. ProdPad

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

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

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

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

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

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

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

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

6. Asana

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

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

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

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

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

7. SEGELFLUGZEUG

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

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

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

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

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

Zu den Hauptfunktionen von GLIDR gehören:

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

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

Verbessern Sie Ihr Spiel mit Easy Agile

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

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

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

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

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

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

Ein guter Produktbestand hat vier Merkmale. Es ist:

• Angemessen detailliert
• Geschätzt
• Aufstrebend
• Priorisiert

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

Transformieren Sie Ihr flaches Produkt-Backlog mit

Einfacher agiler Teamrhythmus

Jetzt testen

Was ist ein Produkt-Backlog?

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

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

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

Produkt-Backlogs im Vergleich zu Sprint-Backlogs

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

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

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

Warum muss ein Backlog verfeinert werden?

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

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

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

Die Verfeinerung des Produktbestands umfasst:

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

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

DEEP: Die wichtigsten Eigenschaften eines guten Produkt-Backlogs

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

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

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

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

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

Angemessen detailliert

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

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

Geschätzt

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

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

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

Aufstrebend

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

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

Priorisiert

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

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

Erzielen Sie mit Easy Agile ein TIEFGREIFENDES Produkt-Backlog

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

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

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

Wenn es um SAFe (Scaled Agile Framework) geht, ist die PI-Planung ein wichtiger erster Schritt zur Vorbereitung eines Teams. Das Treffen, das oft vierteljährlich stattfindet, bringt ein Team zusammen, bestehend aus Softwareentwicklern, Teamleitern, Interessenvertretern und allen dazwischen. Zusammen schließen sie die wichtige Planung ab.

Während die meisten PI-Planungen früher in einem großen Raum stattfanden, haben die heutigen Teams an verschiedenen Standorten den Weg für Online- und hybride PI-Planungsveranstaltungen geebnet. Es ist nicht so wichtig, wo die Sitzung stattfindet, solange sie kontinuierlich im Voraus geplant, vom Team unterstützt und die Veranstaltung durchgeführt wird.

Wir haben eine geschaffen ultimativer Leitfaden zur PI-Planung, das wir ständig mit den neuesten Trends, Planungsfragen, Ressourcen und Tools aktualisieren. In diesem Beitrag konzentrieren wir uns jedoch auf einen bestimmten Aspekt der PI-Planung — die Fehler, die Sie vermeiden sollten. ❌

Die komplette PI Planning-Lösung für Jira

Einfache agile Programme

Nehmen Sie an einer Demo teil

Was ist PI Planning und warum ist es so wichtig?

PI Planning ist Program Increment Planning, eine wiederkehrende Sitzung für Teams innerhalb desselben Agiler Release-Zug (ART), um sich zu treffen, abzustimmen und zu planen, was als Nächstes kommt.

Die Planungssitzung bietet Teams und Stakeholdern Zeit, sich auf eine gemeinsame Vision zu einigen, Funktionen zu besprechen, teamübergreifende Abhängigkeiten zu identifizieren und die Roadmap zu planen, die alles voranbringt. Die Einführung von SAFe beginnt mit PI Planning, und dieser solide Ausgangspunkt ist entscheidend für den Erfolg von SAFe.

Veranstaltungen von PI Planning bilden die Grundlage dafür, wie Ihr Team zusammenarbeitet und wie sich ein Produkt/Projekt entwickelt. Es handelt sich um eine Veranstaltung in Echtzeit, bei der in der Regel ein Team unter einem Dach zusammenkommt, weshalb sie auch als Planung großer Räume bezeichnet wird. Es spielt jedoch keine Rolle, ob Ihr Team gemeinsam persönlich plant oder ob Sie Online-Tools für die Durchführung verwenden PI-Planung aus der Ferne. Der wichtige Teil besteht darin, sicherzustellen, dass die Teams in Echtzeit planen können und dass die PI-Planungssitzung zu kritischen PI-Zielen führt, die das Team auf Erfolgskurs bringen.

Wenn Ihr Team den PI-Planungsprozess erfolgreich abgeschlossen hat, werden Sie:

✅ Bauen Sie Vertrauen, Beziehungen und Zusammenarbeit zwischen Teammitgliedern, Produktmanagern, verschiedenen Geschäftsteams und Interessenvertretern auf

✅ Orientieren Sie sich an den wichtigsten Unternehmenswerten, Zielen und Zielen

✅ Erkennen Sie Abhängigkeiten und andere Probleme, bevor sie den Arbeitsablauf stören

✅ Verbessern Sie die Problemlösung und Entscheidungsfindung

✅ Verstehe, was von jedem Teammitglied erwartet wird, wenn es in die nächste Runde geht Sprint

✅ Gewinnen Sie wertvolle Einblicke von wichtigen Stakeholdern und Geschäftsinhabern

✅ Das Team mit Erwartungen, Zeitvorgaben und klaren Zielen in der Realität verankern

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

Nehmen Sie an einer Demo teil

Kostenlose Testversion

PI-Planungsfehler, die es zu vermeiden gilt

Wenn Sie die potenziellen Fallstricke der PI-Planung identifizieren können, haben Sie eine bessere Chance, sie zu vermeiden. Fallen Sie diesen häufigen Fehlern nicht zum Opfer:

1. PI-Planung überspringen oder nicht priorisieren

2. Versäumnis, im Voraus gründlich zu planen

3. Lange oder langweilige Sessions laufen

4. Lassen Sie zu, dass Ihnen ferngesteuerte Fesseln im Weg stehen

5. Verpassen Sie rückblickende Einblicke

1. PI-Planung überspringen oder nicht priorisieren

Scaled Agile, Inc. sagt, dass „PI Planning für SAFe unerlässlich ist: Wenn Sie es nicht tun, machen Sie kein SAFe.“ Das könnte nicht wahrer sein!

Die PI-Planung ist ein absolut wesentlicher Aspekt von SAFe, und es gibt kein Szenario, in dem sie übersprungen oder unterbewertet werden sollte. Wenn ein PI Planning-Meeting nicht effektiv durchgeführt wird, kann dies schwerwiegende Folgen für die Produktentwicklung haben.

Bei der Arbeit ist unweigerlich viel los, und wenn die Produktentwicklung ins Hintertreffen gerät oder Hindernisse auftauchen, muss etwas nachgeben. Doch egal, wie verlockend es auch sein mag, lassen Sie niemals zu, dass Ihre PI-Planung verschoben, verzögert, reduziert oder ganz übersprungen wird.

Legen Sie Ihr PI-Planungstermin weit im Voraus fest und halten Sie sich an dieses Datum, um sicherzustellen, dass alle verfügbar und vorbereitet sind.

2. Versäumnis, im Voraus gründlich zu planen

Die Pre-PI-Planung ist für den Erfolg Ihrer Veranstaltung von entscheidender Bedeutung. Sie haben als Gruppe nur eine begrenzte Zeit, daher ist es wichtig, dass Sie sie zu gegebener Zeit mit Bedacht nutzen.

Planen Sie den Termin weit im Voraus, um sicherzustellen, dass jeder teilnehmen und auf Planungsmaterialien zugreifen kann. Vergewissern Sie sich vor Ihrem bevorstehenden PI, dass Backlog-Elemente werden verfeinert und bereit, damit während des PI-Events keine wertvolle Zeit verschwendet wird.

3. Lange oder langweilige Sessions laufen

Die PI-Planung beinhaltet oft lange und anstrengende Sitzungen, die die Stimmung beeinträchtigen und Kreativität und Problemlösung hemmen können. 😴

Tun Sie alles, was Sie können, um das Team einzubeziehen und die Sitzungen kurz zu halten. Das kann einem Team helfen, mehr teilzunehmen, in die Sitzung zu investieren und Probleme effektiver zu lösen. Halte Ausschau nach kreativen Arten von Trainingseinheiten, die mehr als nur die wenigen, die voller Energie sind, einbeziehen. Denke sorgfältig über Zeitpläne nach und achte darauf, dass keine Trainingseinheit zu lang ist, um Langeweile oder Zeitverschwendung zu vermeiden.

4. Lassen Sie zu, dass Ihnen ferngesteuerte Fesseln im Weg stehen

Bei der Remote-Ausführung von PI Planning können unterschiedliche Herausforderungen auftreten. Aber mit fortschrittlicher Planung und den richtigen Tools können Sie eine erfolgreiche Planungssitzung durchführen, unabhängig davon, wo sich Ihr Team befindet.

Vernachlässigen Sie Ihre PI-Planung nicht, da Ihr Team remote ist oder vorübergehend remote arbeitet. Es gibt zahlreiche Tools, mit denen sich Teams aus der Ferne online austauschen können — bei Teambesprechungen, Videokonferenzen, Online-Haftnotizen und PI-Planungs-Plugins.

Virtuelle Breakout-Sitzungen sind unerlässlich, um sicherzustellen, dass die richtigen Personen jederzeit teilnehmen können und keine Zeit verschwendet wird. Planen Sie Ihre PI-Planung aus der Ferne sorgfältig, um sicherzustellen, dass alle vorbereitet sind und wissen, wo und wann sie online teilnehmen müssen.

5. Verpassen Sie rückblickende Einblicke

Nicht um wie eine kaputte Schallplatte zu klingen, aber Rückblick 👏🏿 Erkenntnisse 👏🏻 sind 👏🏾 wichtig 👏🏽.

Wir wissen, dass für die PI-Planung nur eine begrenzte Zeit zur Verfügung steht und so viel zu erledigen ist, aber Sie müssen sich Zeit für einen kurzen Rückblick nehmen. Andernfalls werden Sie nie wirklich lernen, wie Sie sich verbessern können. In einer Planungssitzung nach dem PI kann Ihr Team das Planungsereignis besprechen, einschließlich dessen, was gut gelaufen ist, was nicht gut gelaufen ist und was beim nächsten Mal verbessert werden könnte.

Stellen Sie sicher, dass Sie rückblickende Erkenntnisse festhalten und wichtige Ideen in das nächste PI-Planungsgespräch umsetzen. Schließlich wäre es nicht agil, wenn Sie nicht kontinuierlich versuchen würden, Ihre Systeme zu verbessern.

Verbessern Sie Ihre PI-Planung mit einfachen Agile-Programmen

Effektive Planung beginnt mit der Verwendung der richtigen Tools, was umso wichtiger ist, da Teams PI Planning aus der Ferne oder mit verteilten Teams durchführen.

Easy Agile entwickelt Produkte, die agilen Teams helfen, effizient und effektiv zu planen. Einfache Agile-Programme für Jira ist ideal, um Teams bei der effektiven Verwaltung von Programmen mit optimierter Transparenz zu unterstützen. Es handelt sich um eine komplette PI Planning-Lösung für alle Arten von Jira-Benutzern — egal ob verteilt, remote oder von Angesicht zu Angesicht.

Was sind die Vorteile von Easy Agile Programs?

Mit Easy Agile Programs können Sie:

• Erstelle ein Programmboard in Jira
• Effektives Management von Programmen mit optimierter Transparenz
• Verstehen Sie den Zustand Ihres Programm-Backlogs/Ihrer Programminkremente
• Iterationen in Echtzeit durchführen
• Überarbeiten Sie Ihre PI-Planung und passen Sie sie an die Bedürfnisse Ihres Teams an.
• Identifizieren Sie Abhängigkeiten auf Featureebene
• Sorgen Sie für Ausrichtung in großem Maßstab
• Erstelle Meilensteine und Team-Swimlanes
• Ordnen Sie Entwicklungsteams oder mehrere verschiedene Teams auf Ziele und Zeitpläne ab

Jetzt testen

Erfahre mehr über die Vorteile von Easy Agile Programs und testen Sie es 30 Tage lang kostenlos. Wir glauben an Transparenz in Bezug auf unsere Produktvision, was bedeutet, dass Sie folge unserer Produktreise, einschließlich neuer Funktionen, woran wir gerade arbeiten und was wir in Zukunft erreichen wollen.

Psychologische Sicherheit ist der Schlüssel zu leistungsstarken Teams. Aber wie entsteht sie?

Agilität ist die Reaktion auf eine komplizierte Situation, in der Unbekanntes das Bekannte außer Kraft setzt. In einem leistungsstarken Team haben alle Mitglieder ihre Meinung zu Wort und es gibt mehrere Entscheidungsträger. Psychologische Sicherheit ist die Überzeugung, dass der Arbeitsplatz sicher ist, um Ideen, Bedenken oder sogar Misserfolge zu äußern.

Aber wo passt Freundlichkeit rein?

Freundlichkeit ist die Grundlage für psychologische Sicherheit.

Freundlichkeit ist in jeder der ersten drei Phasen von unerlässlich Dr. Timothy R. Clark Das Modell der psychologischen Sicherheit in 4 Stufen.

Stufe 1: Inklusion und Sicherheit

Menschen sehnen sich danach, akzeptiert zu werden, bevor sie gehört werden müssen. Als Führungskraft können Sie Inklusion schaffen, indem Sie Freundlichkeit zeigen, sensibel und neugierig auf das Leben eines Mitarbeiters sind. Ein guter Ausgangspunkt ist; wie war dein Wochenende? Wie geht es der Familie diese Woche? Stehen irgendwelche aufregenden Feierlichkeiten an? Du scheinst heute etwas ruhig zu sein, ist alles in Ordnung?

Stufe 2: Sicherheit der Lernenden

Menschen müssen Fragen stellen, Feedback geben und erhalten und Fehler machen, während sie sich sicher fühlen. Freundlichkeit zu zeigen, schafft das Vertrauen dazu.

Stufe 3: Sicherheit der Mitwirkenden

Menschen müssen sich sicher fühlen, um als Teammitglieder teilnehmen zu können. Ein Bekenntnis zur Freundlichkeit sorgt für einen besseren Informationsfluss, bessere Verbindungen bei der Arbeit und eine verstärkte Zusammenarbeit.

Menschen gedeihen in Umgebungen mit psychologischer Sicherheit. Angst löst den Instinkt der Selbstzensur aus und hält uns zurück. Wenn die Umwelt die psychologische Sicherheit fördert, nehmen Selbstvertrauen, Engagement und Leistungsfähigkeit zu.

3 Tipps für die Implementierung von Freundlichkeit in Ihrem Team noch heute

Tipp 1: Modellieren Sie selbst Freundlichkeit. Egal, welche Rolle Sie spielen, Freundlichkeit ist ansteckend. Wenn Sie anfangen, sich freundlich zu verhalten, wird sich das bald auf Ihr gesamtes Team ausbreiten. Du kannst freundlich dienen, indem du zuhörst, mit Vergebung arbeitest, eine helfende Hand anbietest, Sorge zeigst oder wichtige Ereignisse im Leben eines Kollegen feierst.

Um den Tag der zufälligen guten Taten zu feiern und unseren Unternehmenswert Give Back zu leben, spendete unser Team an Kind Hearts Illawarra.

Tipp 2: Integrieren Sie Freundlichkeit in die Zeremonien Ihres Teams. Jedes Teammitglied kann beim morgendlichen Zusammensitzen eine Sache sagen, für die es dankbar ist. Bei jeder Zeremonie kann Platz gelassen werden, um sich bei einem anderen Teammitglied zu bedanken. Bei Easy Agile setzen wir dies in die Praxis um, indem wir alle ermutigen, jeden Tag eine „gute Sache“ mit anderen zu teilen.

Tipp 3: Implementieren Gut, danke in deiner Firma Slack. Die Good Thnx Foundation stellt eine Verbindung zwischen Menschen und Unternehmen, die spenden wollen, und Wohltätigkeitsorganisationen her. Während sich unser Team gegenseitig „dankt“, erhält der Empfänger 50$, um an eine Wohltätigkeitsorganisation seiner Wahl zu spenden. Unser Beitrag über Good Thanx für das Geschäftsjahr 21 betrug 15.201$.

Einfach ausgedrückt, seien Sie noch heute nett; es ist kostenlos und ermöglicht leistungsstarke agile Teams!

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

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

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

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

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

Was ist ein Epos?

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

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

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

Die Bedeutung von Epics in Ihrer agilen Praxis

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

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

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

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

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

Wie Epics der agilen Entwicklung einen Mehrwert verleihen

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

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

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

Wann sollte man kein Epos benutzen

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

Das immergrüne Epos

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

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

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

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

Das Themen-Epos

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

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

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

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

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

Das Release-Epos

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

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

Epics sind mehr als eine große User Story

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

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

Aber was hat das mit Epen zu tun?

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

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

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

Wenn du die Rolle des Entwicklungsmanagers übernimmst, kann es sich so anfühlen, als würdest du von allem ein bisschen machen. Ihre Aufgabe besteht nicht mehr darin, sich ausschließlich auf den Code zu konzentrieren — und Sie leiten kein durchschnittliches Team. In Ihrem Alltag vertreten Sie Ihr Engineering-Team, entwerfen Strategien für es und entwickeln sogar gemeinsam mit ihm.

Bei all den Aufgaben, die Ihre To-Do-Liste füllen, kann es leicht passieren, dass Sie vergessen: Qualitativ hochwertige Ergebnisse zu erzielen, hängt von der Qualität Ihrer Führung ab. Bei der Arbeit geht es nicht nur um Projekte — und Sie sind kein Projektmanager. Gute Entwicklungsmanager sind genauso gut darin, mit Menschen zu arbeiten, Kultur aufzubauen und ihre Teammitglieder zu unterstützen, wie sie darin sind, die Effizienz zu steigern und an allen technischen Dingen zu arbeiten.

Um das Beste aus Ihrem Team herauszuholen, finden Sie hier fünf Tipps, die jeder Entwicklungsmanager kennen muss, um das Beste aus seinem Team herauszuholen.

1. Bieten Sie Beratung an, nicht Mikromanagement

Hast du jemals etwas mit jemandem gemacht, der dir im Nacken sitzt? Es ist nicht bequem und schafft eine Kultur des Misstrauens. In einem agile Umgebung, das widerspricht dem Prinzip, ein sich selbst organisierendes Team zu haben — eines, in dem jedes Teammitglied seine eigenen Verantwortlichkeiten und Zeitpläne selbst in die Hand nimmt.

Ein guter Entwicklungsmanager weiß, dass jedes Teammitglied seine eigene Arbeitserfahrung und sein Wissen in ein Team einbringt. Ihre Stellenbeschreibung besteht nicht darin, die Arbeit anderer Leute für sie zu erledigen oder sie herumzukommandieren. Es geht vielmehr darum, sicherzustellen, dass das Engineering-Team qualitativ hochwertige Produkte rechtzeitig produziert.

Du holst mehr aus deinem Team heraus, indem du sie inspirierst, anstatt ihnen zu sagen, was sie tun sollen. Anstatt Termine zu diktieren, leiten Sie Ihr Team in die richtige Richtung, indem Sie die Bedeutung Ihrer vorrangigen Projekte veranschaulichen.

Wie wird sich der Beitrag jeder Person auf das gesamte Unternehmen auswirken? Wie eröffnet die frühzeitige Erledigung einer Aufgabe dem Team neue Möglichkeiten? Ermutigen Sie Ihre Mitarbeiter zu besseren Entscheidungen, die sie selbst treffen, um ein Team aufzubauen, das von seiner Arbeit begeistert ist.

2. Planen Sie unter Berücksichtigung des Gesamtbildes

Während Mitglieder Ihres Produktentwicklungsteams vielleicht in die Details eintauchen — Code schreiben, kleinere Aufgaben abhaken — besteht Ihre Aufgabe als Entwicklungsleiter darin, in großen Maßstäben zu denken. Entwicklungsmanager spielen eine Schlüsselrolle in der agile Planung Prozess, indem sie herausfinden, welche Projekte ihr Team priorisieren sollte und wie sie am besten abgeschlossen werden können.

Anstatt nur darüber nachzudenken, was für Ihr Team am besten ist, müssen Sie überlegen, welche Projekte und Aufgaben am besten zu den allgemeinen Geschäftszielen Ihres Unternehmens passen. Dies wird Ihnen helfen, ein Entwicklungsteam aufzubauen, das herausragende Ergebnisse für das gesamte Unternehmen erzielt.

Gleichzeitig sollten Sie sich darüber im Klaren sein, was für Ihr Team möglich ist. Wird die Verpflichtung zu einem neuen Produkt die Arbeitsbelastung einer Person weitaus mehr erhöhen als die anderer? Hat Ihr Team überhaupt die Kapazität für mehr Arbeit? Unabhängig davon, wie viele Jahre Erfahrung Ihr Team hat, brauchen sie — als Einzelpersonen und als Ganzes — Raum zum Atmen, damit sie nicht ausbrennen.

3. Halten Sie Ihre technischen Fähigkeiten auf dem neuesten Stand

„Manager“ mag das prahlerische Highlight Ihrer Berufsbezeichnung sein, aber das bedeutet nicht, dass Sie Ihre technischen Fähigkeiten aufgeben können. Die Chancen stehen gut, dass Programmieren immer noch einen Teil Ihres Alltags ausmachen wird — oder zumindest Ihrer Woche für Woche. Auch wenn Sie nicht direkt mit einer Softwareentwicklungsaufgabe beauftragt sind, müssen Sie Ihre Teammitglieder dennoch durch ihre individuellen Aufgaben führen.

Um Ihrem Team die Unterstützung zu geben, die es benötigt, müssen Sie in der Lage sein, seine Programmiersprache zu sprechen. Dies hilft Ihnen dabei, Code-Reviews zu leiten, an technischen Gesprächen teilzunehmen, Hindernisse zu antizipieren (und zu verhindern) und sicherzustellen, dass Sie die effizientesten Technologien implementieren. Die regelmäßige Teilnahme an Kursen und der Beitritt zu einer Programmier-Community sind zwei einfache Möglichkeiten, um für Ihr Entwicklungsteam ein Meister der Problemlösung zu werden.

Ihr technisches Fachwissen hilft Ihrem Team, sich an Ihre Anforderungen zu halten Produkt-Roadmaps und erreichen Sie wichtige Meilensteine.

4. Stärken Sie Ihre Kommunikationsfähigkeiten

Wenn Sie den Job als Entwicklungsleiter übernehmen, werden Sie zum Bindeglied zwischen Ihrem Engineering-Team und anderen Teilen Ihres Unternehmens. Beispielsweise können Sie der Geschäftsleitung die Bedürfnisse Ihrer Entwickler mitteilen oder Anfragen von Vertriebsleitern an Ihr Team weiterleiten.

Leute ohne technischen Hintergrund denken vielleicht, dass du über Musik sprichst, wenn du anfängst, über C# zu sprechen. Ingenieure ohne Erfahrung in der Unternehmensführung verdrehen möglicherweise die Augen, wenn Sie anfangen, über Fünfjahrespläne statt über bevorstehende Pläne zu sprechen Produkteinführung. Obwohl Mitarbeiter dieselbe Unternehmenskultur teilen, „verstehen“ sie sich nicht unbedingt ständig.

Entwicklermanager sind Übersetzer, die ihr Team repräsentieren und ihnen bei Bedarf Nachrichten zurücksenden.

Da Sie ständig mit Menschen mit unterschiedlichem Hintergrund zusammenarbeiten, müssen Sie Ihre zwischenmenschlichen Fähigkeiten stärken. Erfahre, wie du am besten mit verschiedenen Menschen kommunizieren kannst. Welche Teams bevorzugen E-Mail gegenüber SMS? Wer ist der Ansprechpartner für jedes Team? Hört jemand besser zu, wenn er keinen Hunger hat? 🙋

Je stärker Ihre Kommunikationsfähigkeiten sind, desto wahrscheinlicher ist es, dass Ihr Team die Ressourcen erhält, die es benötigt, und desto besser wird es seine Prioritäten mit denen Ihres Unternehmens verbinden.

5. Seien Sie verfügbar, um Ihre Teammitglieder zu unterstützen

Der Entwicklungsleiter kann in Teilzeit eine leitende und eine Teilzeit-technische Rolle innehaben, aber in dieser Position müssen Sie ein Vollzeitleiter für Ihr Team sein. Wenn Sie die Leistung Ihres Teams kontinuierlich verbessern möchten, müssen Sie Ihre erstklassigen Führungsqualitäten Tag für Tag in die Praxis umsetzen.

Als Entwicklungsmanager müssen Sie als eine Art Coach für Ihre Teammitglieder agieren. Planen Sie regelmäßige Einzelgespräche mit Ihren Teammitgliedern ein, bei denen Sie sich zusätzlich zu aktuellen Projekten über Karriereziele und Problembereiche unterhalten können. Wenn Sie einen neuen Mitarbeiter haben, sprechen Sie während der Onboarding-Phase mit ihm über seinen gewünschten Karriereweg.

Basierend auf dem, was du gelernt hast, kannst du dir überlegen, wie du ihre berufliche Entwicklung unterstützen kannst. Sie müssen nicht für ihren Bachelor-Abschluss bezahlen, um ihnen zum Erfolg zu verhelfen. Bringen Sie sie mit Mentoren in Kontakt, schicken Sie sie auf Konferenzen, empfehlen Sie sie für Vorträge — Ihre Möglichkeiten sind endlos (und einfacher als Sie vielleicht denken).

Unterstützung sowohl bei aktuellen Projekten als auch bei langfristigen Karrierezielen zu bieten, ist Ihre Chance, in Ihre Mitarbeiter zu investieren. Es wird ihnen helfen, bessere Mitarbeiter zu werden — und sie werden sich auch geschätzt fühlen. Wussten Sie fast die Hälfte der Mitarbeiter ihren Job verlassen, um neue Fähigkeiten zu erwerben? Um Ihr Entwicklungsteam langfristig in Bestform zu halten, müssen Sie jedem Mitarbeiter helfen, sich weiterzuentwickeln.

Führe dein Team als effektiver Entwicklungsmanager

Um Ihr Entwicklungsteam zum Erfolg zu führen, ist eine unschlagbare Mischung aus menschlichen Fähigkeiten, technischen Fähigkeiten und Führungsqualitäten erforderlich. In Ihrer vielseitigen Rolle ist Ihre Fähigkeit, zu kommunizieren und Ihr Team mit dem Rest Ihres Unternehmens in Einklang zu bringen, von unschätzbarem Wert.

Mit Easy Agile Roadmaps für Jira kannst du die Teamzusammenstellung vereinfachen, indem du jedes Jira-Problem per Drag-and-Drop auf eine visuelle Zeitleiste ziehst. Schauen Sie sich unsere Demo an heute, um zu sehen, wie dieses Tool Ihrem Engineering-Team helfen kann, zu glänzen!

Inzwischen sind Sie mit Scrum ziemlich vertraut. Es gibt Ihrem Team einen Rahmen, mit dem es arbeiten kann, um interne Ziele zu erreichen, damit es seinen Kunden hochwertige Software liefern kann. Aber du kannst deine Scrum-Praktiken jederzeit verbessern, um deine Kunden weiterhin zu begeistern. 😁 Eine davon ist das tägliche Scrum — eine Praxis, die einfach klingt, aber leicht falsch verwaltet werden kann (dazu bald mehr 😉).

Das tägliche Scrum besteht aus drei Elementen — Scrum-Rollen, Scrum-Artefakte, und Scrum-Ereignisse.

In diesem Artikel zeigen wir Ihnen, wie diese Komponenten in das wichtige tägliche Scrum-Meeting passen, geben einige Tipps, damit Ihr tägliches Scrum reibungslos abläuft, und besprechen, welche Fallen Sie vermeiden sollten, damit Ihr Team immer am Ball ist. Wir weisen Sie auch auf Ressourcen hin, mit denen Sie die anderen Elemente der Agilität beherrschen können. Unser Ziel ist es wie immer, dich zu einem agilen Profi zu machen. 🏄🏽 ‍ ♀️

Was ist das Daily Scrum Meeting?

Lassen Sie uns eine kurze Zusammenfassung der einzelnen Punkte machen, bevor wir in das tägliche Gedränge eintauchen:

• Scrum-Rollen: Dies sind der Product Owner, der Scrum Master und das Entwicklungsteam. Diese Scrum-Teammitglieder arbeiten als Einheit zusammen, um ihre Ziele zu erreichen.
• Scrum-Artefakte: Zu den Artefakten gehören das Produkt-Backlog, das Sprint-Backlog und das Increment. Die Artefakte stellen Informationen für das Team dar, die es ihnen ermöglichen, transparente Ansichten zu haben, anhand derer sie ihren Fortschritt messen können.
• Scrum-Ereignisse: Der Sprint, die Sprint-Planung, das tägliche Scrum, das Sprint-Review und Sprint-Rückblick geben Sie dem Team die Möglichkeit, alle Scrum-Artefakte zu erfüllen und zu verfeinern, die angepasst werden müssen, um die Ziele des Teams im Blick zu behalten.

Das Daily Scrum ist ein Treffen zwischen Teammitgliedern, um den aktuellen Sprintfortschritt zu besprechen. Es ist an der Zeit herauszufinden, ob Anpassungen am Sprint oder am Produkt-Backlog vorgenommen werden müssen, um das Ziel zu erreichen Sprintziel.

Bedeutung von Daily Scrum

Das tägliche Scrum spielt eine entscheidende Rolle bei der Verbesserung der Teamkoordination und Kommunikation. Dieses kurze, fokussierte Meeting bietet dem Team ein strukturiertes Umfeld, in dem es sich über Fortschritte und Hindernisse abstimmen kann. Es leistet einen Beitrag zu mehreren Schlüsselbereichen:

1. Fortschrittstransparenz: Die Teammitglieder erhalten einen klaren Überblick darüber, woran alle gerade arbeiten, was die Rechenschaftspflicht und die gegenseitige Unterstützung fördert.
2. Identifizierung von Hindernissen: Probleme und potenzielle Hindernisse werden frühzeitig erkannt, sodass das Team sie umgehend beheben und Projektverzögerungen minimieren kann.
3. Gezielte Zusammenarbeit: Indem die Diskussionen relevant und auf den Punkt gebracht werden, kann das Team seine Zeit effektiver nutzen und sich auf Lösungen statt auf langwierige Debatten konzentrieren.
4. Ausrichtung der Ziele: Das Treffen hilft dabei, die Bemühungen auf die Sprintziele zu bekräftigen und neu auszurichten und sicherzustellen, dass alle an einem Strang ziehen und sich in die gleiche Richtung bewegen.

Durch die Einhaltung von Best Practices, wie z. B. die Einhaltung des Zeitrahmens für die Besprechung und die Förderung einer inklusiven Atmosphäre, können Teams die Vorteile des täglichen Scrums maximieren, was zu einem kohärenteren und effizienteren Arbeitsumfeld führt.

Die wichtigsten Teilnehmer des Daily Scrum

Entwicklungsteam

Die Mitglieder des Entwicklungsteams sind die Hauptteilnehmer am täglichen Scrum. Während des Treffens berichten sie über ihre Fortschritte bei der Erreichung des Sprintziels, um herauszufinden, ob Anpassungen vorgenommen werden müssen. Sie können dies tun, indem sie jeweils drei Fragen beantworten:

1. Woran habe ich gestern gearbeitet, um das Sprintziel zu erreichen?
2. Wie werde ich heute auf das Sprintziel hinarbeiten?
3. Gibt es etwas, das mich daran hindert, das, woran ich gerade arbeite, zu beenden?

Auf diese Weise ist jeder im Team über den Fortschritt des gesamten Teams auf dem Laufenden. Die Antworten auf diese Fragen ermöglichen es dem Team auch, etwaige Blocker aufzudecken und den Sprint-Backlog entsprechend anzupassen. Ein Beispiel für einen Blocker kann ein Bug sein, der eine Entwicklerin daran hindert, ihre zugewiesene User Story im Sprint fertigzustellen.

Scrum Master und Product Owner

Im traditionellen Scrum ist der Scrum Master und Product Owner nehmen nicht aktiv am täglichen Scrum-Meeting teil — und sind auch technisch nicht erforderlich —, da sie nicht die Entwicklungsarbeit leisten, mit der das Sprintziel erreicht werden kann. Sie können jedoch immer noch wertvolle Besprechungsteilnehmer sein. Es liegt am Scrum-Team, zu entscheiden, ob sie teilnehmen sollen.

• Der Product Owner kann wegweisend bei der Anpassung der Backlog-Elemente des Sprints sein. Zum Beispiel kann der Bug, der andere Arbeiten blockiert, verschoben werden, sodass er rechtzeitig behoben wird, um das Sprintziel in Reichweite zu halten.
• Der Scrum-Master kann sicherstellen, dass die Best Practices für das tägliche Scrum befolgt werden und dass das Team einige der häufigsten Fallstricke vermeidet, die die Ziele des täglichen Scrum-Meetings verraten. Schauen wir uns diese als Nächstes an.

Was ist der Unterschied zwischen Daily Scrum und Daily Standup?

Manchmal kann es verwirrend sein, die Unterschiede zwischen Daily Scrum und täglicher Stand Up — und manchmal werden die Begriffe synonym verwendet. Es lohnt sich jedoch, auf die Unterschiede zwischen den beiden hinzuweisen.

Ein Daily Scrum ist ein Ereignis, das definiert ist in Scrum-Leitfaden. Also, was ist dann täglicher Stand-up und wie unterscheidet er sich? 🤔

Ein tägliches Stand-up ist ein tägliches Meeting, dessen Ziel es ist, den Teammitgliedern Fortschritte auf dem Weg zu einem gemeinsamen Ziel zu vermitteln. Es ist jedoch weniger restriktiv, was die Teilnehmer und die Zeitlimits angeht. Mit anderen Worten, Teammitglieder außerhalb des Scrum-Teams können teilnehmen und das Meeting kann länger als 15 Minuten dauern. Beispielsweise kann ein Unternehmen täglich ein Stand-up durchführen, an dem die gesamte Belegschaft oder eine bestimmte Abteilung teilnehmen, deren Fortschrittsberichte nicht auf die Softwareentwicklung beschränkt sind.

Best Practices für das tägliche Scrum

Was sind also die besten Methoden, um Ihre täglichen Scrum-Meetings effektiv durchzuführen?

1. Schließe das tägliche Gedränge in einer Zeitbox ab

Ein Zeitrahmen von 15 Minuten wird am häufigsten verwendet, um sicherzustellen, dass das Team konzentriert und auf den Punkt kommt. Schließlich müssen die Teammitglieder ihre drei Fragen nur kurz und effektiv beantworten.

2. Führen Sie das Meeting jeden Tag zur gleichen Zeit und am gleichen Ort durch

Dies wird für ein gewisses Maß an Kohärenz und Regelmäßigkeit sorgen und dazu beitragen, Scrum-Werte von Engagement und Fokus.

3. Beziehen Sie in jedes tägliche Scrum-Meeting dieselben Teammitglieder ein

Wenn Sie eine wechselnde Besetzung von Charakteren haben, laufen Sie Gefahr, dass es zu Unterbrechungen kommt. Bei einigen Teilnehmern der Besprechung fehlt wahrscheinlich der Kontext aus früheren Besprechungen und sie müssen auf dem Laufenden gehalten werden.

Tägliche Scrums für entfernte oder verteilte Teams

Tägliche Scrums sind für die Ausrichtung der Teams von entscheidender Bedeutung, aber für Teams an verschiedenen Standorten oder an verschiedenen Standorten ist eine durchdachte Ausführung erforderlich, um die Effektivität aufrechtzuerhalten. So können Sie das Beste aus Ihren virtuellen täglichen Scrums herausholen:

Intelligente Nutzung von Videokonferenzen

Videokonferenzen bieten den Vorteil einer Live-Konversation, die für die Zusammenarbeit und Klarheit in Echtzeit von entscheidender Bedeutung ist.

• Respektiere persönliche Bedürfnisse: Erkenne, dass es anstrengend sein kann, vor der Kamera zu stehen. Bieten Sie Flexibilität, indem Sie den Teammitgliedern die Wahl lassen, wann sie ihre Kameras verwenden möchten.
• Ermüdung vermeiden: Ermutigen Sie dazu, bei wichtigen Diskussionen die Kamera zu verwenden, bieten Sie jedoch die Möglichkeit, nur Audio zu hören, um Erschöpfung zu vermeiden.

Zeitzonen mit Bedacht verwalten

Verteilte Teams erstrecken sich oft über mehrere Zeitzonen. So meistern Sie die Herausforderung:

• Intelligent planen: Finden Sie eine geeignete Besprechungszeit, die für die Mehrheit geeignet ist. Zum Beispiel könnte jemand am Vormittag teilnehmen, während es für andere früh am Morgen ist.
• Ziehen Sie asynchrone Updates in Betracht: Wenn die Zeitzonen sehr unterschiedlich sind, sollten Sie sich auf asynchrone Kommunikation wie Kommentare in der Taskleiste oder Chat-Kanäle verlassen, um alle auf dem Laufenden zu halten, ohne ihre Work-Life-Balance zu stören.

Verwenden Sie visuelle Tools

Visuelle Hilfsmittel können das Verständnis und die Teilnahme an virtuellen Besprechungen erheblich verbessern.

• Bildschirmübertragung: Verwenden Sie die Bildschirmübertragung, um Taskboards oder Projektmanagement-Software anzuzeigen und so einen klaren, visuellen Kontext für Diskussionen zu bieten.
• Tools für die Zusammenarbeit: Nutze Tools wie Miro oder Trello für visuelles Brainstorming und Aufgabentracking während des Scrums.

Arbeitsvereinbarungen definieren

Durch die Erstellung klarer Arbeitsvereinbarungen wird sichergestellt, dass alle in Bezug auf Prozesse und Erwartungen auf derselben Wellenlänge sind.

• Kommunikationsmethoden: Geben Sie an, wie Teammitglieder kommunizieren sollen, sei es über Videoanrufe, Messaging-Apps oder E-Mails.
• Tools für die Zusammenarbeit: Entscheiden Sie, welche Tools Sie für Dokumentation, Zusammenarbeit in Echtzeit und asynchrone Updates verwenden möchten. Zu den beliebten Optionen gehören Slack für die Kommunikation und Jira für das Aufgabenmanagement.

Fallstricke bei Daily Scrum

Es gibt verlockende Aktivitäten, die Sie bei der Durchführung Ihres täglichen Scrum-Meetings vermeiden sollten. Dies sind einige der häufigsten Fallstricke, die es zu vermeiden gilt:

1. Das Meeting als Status-Update verwenden

An den Product Owner, Scrum Master oder andere Stakeholder. Das Hauptziel dieses Treffens besteht darin, dass das Entwicklungsteam seine drei Fragen beantwortet, damit es alle erforderlichen Anpassungen vornehmen kann, um das Sprintziel beizubehalten. Es sollte nicht als Status-Meeting für Entwickler genutzt werden, um über den Fortschritt ihrer Arbeit zu berichten.

2. Machen Sie daraus eine Problemlösungssitzung

Um alle Blockaden, die in der Sitzung besprochen werden, innerhalb des 15-minütigen Zeitrahmens zu lösen. Eines wird zweifellos passieren, wenn das Team dies versucht — das Meeting wird zu lang dauern! Der Scrum Master sollte dem Team raten, während des Meetings bei der Arbeit zu bleiben und diese Problemlösungsversuche auf einen Zeitpunkt außerhalb des täglichen Scrum-Meetings zu verschieben.

3. Konzentrieren Sie sich auf ein Taskboard

Um den Fortschritt zu verfolgen. Das tägliche Scrum-Meeting ist eine Zeit für Diskussionen. Wenn das Team auf ein Taskboard starrt, verschwendet es wertvolle Zeit, indem es sich auf den Status der Aufgaben konzentriert und nicht darüber spricht, Anpassungen an seiner Arbeit vorzunehmen.

Zusätzlich zu diesen wichtigen Punkten gibt es mehrere andere häufige Fehler, die die Effektivität eines täglichen Scrums beeinträchtigen können:

• Es ist ein langweiliges Statusmeeting geworden an dem niemand teilnehmen will. Dies deutet auf einen Mangel an Engagement und Zielstrebigkeit hin.
• Entwickler berichten über persönliche Leistungen an einen Scrum Master oder Manager, was den kollaborativen Geist des Teams untergraben kann.
• Das Treffen findet nicht statt wenn der Scrum Master es an diesem Tag nicht schafft. Diese Abhängigkeit kann die Konsistenz der täglichen Fortschrittskontrollen stören.
• Das Team versucht Probleme zu lösen und finden Sie während des täglichen Scrums Lösungen, die vermieden werden sollten, um die Timebox zu respektieren.
• Das tägliche Scrum wird verwendet, um Arbeitselemente zu verfeinern, was nicht der beabsichtigte Zweck ist. Die Verfeinerung sollte separat erfolgen.
• Die Timebox wird nicht respektiert, was dazu führt, dass einige Teammitglieder das Gefühl haben, dass das Meeting eine Belastung ist. Es ist wichtig, das 15-Minuten-Limit einzuhalten.
• Einige Entwickler denken, dass sie nicht auftauchen müssen, was zu Fehlausrichtungen und verpassten Gelegenheiten zur Teamsynchronisierung führen kann.

Indem Teams sich dieser häufigen Fallstricke bewusst sind und ein konzentriertes und effizientes tägliches Scrum pflegen, können sie sicherstellen, dass sie das Beste aus ihrer gemeinsamen Zeit machen und ihre Sprintziele auf Kurs halten.

Meistere Daily Scrum und werde ein agiler Profi

Bei Einfach und agil, wir bieten Produkte um all Ihre Scrum-Events zu verwalten. Wir setzen uns leidenschaftlich dafür ein, Agile für seine Teilnehmer zugänglich und leicht verständlich zu machen. Zusätzlich zu unseren Produkten stellen wir gerne Ressourcen zur Verfügung, damit du dein agiles Spiel verbessern kannst 💪. Schau dir unsere an Blog und unsere Podcast um ein agiler Profi zu werden!

Agil sein oder agil handeln — was ist der Unterschied?

Organisationen auf der ganzen Welt haben erkannt, dass sie schnell reagieren müssen, um den Herausforderungen des ständigen Wandels zu begegnen. Infolgedessen kämpfen sie um die Einführung agiler Arbeitsweisen, und die Pandemie beschleunigt die Einführung agiler Methoden.

Diejenigen, die es richtig machen, können einen starken Einfluss auf ihr Geschäftsergebnis und ihren Wettbewerbsvorteil haben. Aber für andere sind die Vorteile vielleicht noch abzuwarten.

Hier kann „agil handeln“ und „agil sein“ den entscheidenden Unterschied ausmachen. Denn um die Vorteile agiler Methoden wirklich nutzen zu können, müssen Unternehmen von tun zu Sein.

Dieser Artikel erklärt den Unterschied zwischen agil sein oder agil handeln. Außerdem werden wir Sie durch einige der häufigsten Herausforderungen führen, mit denen viele Unternehmen auf ihrem Weg zur Agilität konfrontiert sind.

Die wichtigsten Punkte

• Um das volle Potenzial agiler Arbeitsweisen auszuschöpfen, müssen Teams eine agile Denkweise entwickeln und agile Prozesse einführen.
• Der Übergang von „agil handeln“ zu „agil sein“ erfordert Zeit, Coaching und einen neuen Managementansatz.
• Richtig gemacht, kann Agilität die Kundenzufriedenheit, das Engagement der Mitarbeiter, das Wachstum und die Rentabilität steigern.

Warum agil und warum jetzt?

Agile erfreut sich bereits seit über 20 Jahren zunehmender Beliebtheit, aber als die Pandemie ausbrach, beschleunigte sich dieses Wachstum.

In allen Branchen ist es heute von entscheidender Bedeutung, digitale Erlebnisse bieten zu können. Unternehmen müssen heute wie Softwareunternehmen handeln und denken, wobei das Online-Erlebnis der Kunden im Mittelpunkt steht. Zusammen mit einem aktiven Ansatz bei der Kundengewinnung müssen Sie einen echten Mehrwert bieten, um sich von der Konkurrenz abzuheben.

Für Unternehmen, die in diesem Umfeld überleben und gedeihen wollen, wenden sich viele an agile Frameworks um schnell einen Mehrwert für Kunden zu schaffen und Geschäftsergebnisse zu erzielen. Agilität ermöglicht es Teams:

• Machen Sie das Komplexe einfach — durch das Arbeiten in einem klaren, strukturierten Rahmen wird aus Chaos Ordnung.
• Behalten Sie den Überblick — Agile Teams haben ein gemeinsames Verständnis von ihren Fortschritten auf dem Weg zu ihren Zielen.
• Erfolge replizieren — Wenn ein Team einen effektiven Weg findet, Ergebnisse zu erzielen, kann es Lösungen für andere Zwecke verwenden und unternehmensweit austauschen.
• Schaffen Sie eine abgestimmte, zielgerichtete Kultur — wenn Hunderte von Mitarbeitern in einer Organisation Dutzende agiler Teams bilden, bilden sie ein stabiles Rückgrat und gehen denselben Weg zum gleichen Ziel.

„Agile Organisationen, die als lebende Systeme betrachtet werden, haben sich weiterentwickelt, um in einem unvorhersehbaren, sich schnell verändernden Umfeld erfolgreich zu sein. Diese Organisationen sind sowohl stabil als auch dynamisch. Sie konzentrieren sich auf die Kunden, passen sich flexibel an Umweltveränderungen an und sind offen, inklusiv und hierarchiefrei. Sie entwickeln sich kontinuierlich weiter und akzeptieren Ungewissheit und Ambiguität. Wir glauben, dass solche Organisationen für die Zukunft weitaus besser gerüstet sind als traditionelle Organisationen.“

- McKinsey & Company

Was bedeutet es, agil zu sein?

Viele Organisationen verwenden einige agile Prozesse, um Projekte zu verwalten. Das heißt aber nicht, dass die Teams die agile Methodik vollständig verstanden und angenommen haben. Es könnte sein, dass sie „agil handeln“, anstatt tatsächlich „agil zu sein“.

Hier ist der Unterschied zwischen den beiden:

Agil handeln

„Agile handeln“ ist das Missverständnis, dass Ihr Unternehmen agil wird und auf Veränderungen reagiert, wenn Sie agile Dinge tun. Unternehmen, die in diese Falle getappt sind, könnten einige agile Prozesse durchmachen, wie zum Beispiel tägliche Stehaufsteher, Sprints, und Rückblicke. Teams sind so strukturiert, dass sie klein, funktionsübergreifend und kollaborativ sind. Aber wenn sie dort aufhören, werden diese Teams nicht wirklich agil und es kann sein, dass sie Schwierigkeiten haben, Ergebnisse zu erzielen.

Agile Zeremonien, Tools und Strukturen sind zwar entscheidend für die Implementierung, aber sie sind nur ein Teil dessen, was ein Unternehmen agil macht.

Agil sein

„Agil sein“ bedeutet, dass Sie die oben genannten Aktivitäten einbeziehen, aber über die Prozesse hinausgehen. Das bedeutet, eine agile Denkweise und agile Werte auf alle Bereiche der Organisation anzuwenden. Teams müssen geschult werden, um die agile Denkweise zu beherrschen und alle Herausforderungen zu meistern, die sich auf dem Weg dorthin ergeben. Es erfordert mehr Zeit und Mühe, als einfach agil zu arbeiten, aber es ist entscheidend, wenn Sie die Vorteile nutzen möchten.

Was ist eine agile Denkweise?

Eine agile Denkweise anzunehmen bedeutet, ihre vier Kernwerte zu verstehen und zu leben. Um agil zu sein, müssen Sie:

1. Respektiere die Menschen - Erkennen Sie, dass Mitarbeiter für den Erfolg Ihres Unternehmens von entscheidender Bedeutung sind. Sorgen Sie dafür, dass die Mitarbeiter gemeinsame Ziele verfolgen, sich sicher und in der Lage fühlen, Ideen auszutauschen, und dass Sie eine „Wir“ -Mentalität gegenüber „Ich“ annehmen.
2. Fluss optimieren - Erhöhen Sie die Qualität bei jedem Schritt, damit Sie Probleme erkennen und frühzeitig Kurskorrekturen vornehmen können. Dies trägt dazu bei, den Wert zu maximieren und Verschwendung zu minimieren und gleichzeitig einen konsistenten, nachhaltigen Arbeitsablauf zu schaffen.
3. Innovation fördern — Fördern Sie das Experimentieren mit Zusammenarbeit, konstruktivem Feedback und Autonomie. Planen Sie Zeit und Raum ein, damit Kreativität und Ideen fließen können.
4. Unermüdlich verbessern - Denken Sie daran, dass es mit der agilen Denkweise keinen Endpunkt gibt. Es geht um kontinuierliche Verbesserung. Daher müssen Sie zukünftige Prozesse im Rahmen einer kontinuierlichen Praxis kontinuierlich reflektieren und verbessern.

Um diese Werte zur Grundlage für die Arbeit in Ihrem gesamten Unternehmen zu machen, müssen Sie agile Prozesse mit einer agilen Denkweise kombinieren. Ohne die agile Denkweise sind Sie nicht „agil“, und Ihre Prozesse werden nicht das volle Potenzial Ihres Unternehmens entfalten.

„Die agile Denkweise ist ein Denkprozess, der Verständnis, Zusammenarbeit, Lernen und Flexibilität beinhaltet, um leistungsstarke Ergebnisse zu erzielen. Durch die Kombination der agilen Denkweise mit Prozessen und Tools kann sich das Team an Veränderungen anpassen und seinen Kunden einen Mehrwert bieten.“

- Atlassian

Agile Prozesse und Tools reichen nicht aus

Agile Prozesse, einschließlich der Zeremonien, Tools und Apps, sind dazu da, die Denkweise des Teams zu unterstützen. Aber ohne die richtige Denkweise in Ihrem Unternehmen zu vermitteln, werden Sie nicht wirklich agil sein.

Die Förderung der agilen Denkweise gibt einem Unternehmen die Möglichkeit, sich jederzeit schnell in eine bestimmte Richtung zu bewegen, um den Kunden den besten Wert zu bieten. Teams, die Agilität beherrschen, sind in der Regel:

• Autonom und ermächtigt um Entscheidungen rund um das Produkt und das Kundenerlebnis zu treffen.
• In der Lage an Veränderungen anpassen schnell.
• Immer bereit zu lernen etwas Neues.

Verlobt mit einem geteilter Zweck und eine Kultur der Zusammenarbeit.

„Es geht darum, sich auf Veränderungen einstellen zu können. Ob das nun in Bezug auf Mitarbeiter, Ressourcen oder Budget ist — wie auch immer das für ein Unternehmen aussieht. Wenn Sie in der Lage sind, schnell von einem Schwerpunktbereich zum anderen zu wechseln, bevor es Ihr Konkurrent tut, dann haben Sie einen Wettbewerbsvorteil auf dem Markt.“

- Sean Blake, Marketingleiter, Easy Agile

Häufige Herausforderungen, auf die Sie achten sollten, wenn Sie von agiler zu agiler Arbeit übergehen

Je früher Sie handeln und von agiler zu agiler Vorgehensweise übergehen können, desto eher profitieren Ihre Kunden, Mitarbeiter und Ihr Geschäftsergebnis.

Im Folgenden finden Sie einige häufig auftretende Herausforderungen und Tipps zu deren Bewältigung.

• Die Leute könnten an alten Gewohnheiten festhalten
  Menschen finden Veränderungen schwierig, besonders wenn Gewohnheiten tief verwurzelt sind. Sie werden vielleicht feststellen, dass einige Leute auf ihrem Standpunkt beharren und an der alten Art festhalten, Dinge zu tun. Es ist wichtig, sich daran zu erinnern, dass dies einige Zeit in Anspruch nehmen kann und die Menschen Unterstützung benötigen, um neue Arbeitsweisen zu erlernen. Stellen Sie sicher, dass Sie genügend Gelegenheiten für Feedback und Diskussionen bereitstellen, damit Sie als Team das wiederholen können, um einen Prozess zu finden, der für Ihr Unternehmen funktioniert.
• Nicht nur das Team muss gecoacht werden
  Agil zu sein ist eine Denkweise für das gesamte Unternehmen, einschließlich Manager und Führungskräfte. Wenn Ihre Führungskräfte Agilität nicht verstehen und unterstützen, wird es schwierig sein, an Dynamik zu gewinnen und alte Prozesse und Hierarchien zu verändern. Scrum Master und Agile Trainer müssen Zeit damit verbringen, Führungskräfte zu coachen, um neue agile Denkweisen und Fähigkeiten zu entwickeln.
• Für viele Unternehmen erfordert Agilität einen neuen Führungsstil
  Der traditionelle Führungsstil von Command and Control mag im Industriezeitalter funktioniert haben. Aber jetzt passt es nicht mehr zu der Art und Weise, wie Unternehmen und Mitarbeiter heute arbeiten müssen, und es unterstützt nicht die agile Denkweise. Um agil zu sein, benötigen Teams das Vertrauen, die Autonomie und die Fähigkeit, eine Idee ohne Hindernisse bis zur Umsetzung umzusetzen. Damit dies gelingt, müssen Führungskräfte hinter diesen vielseitigen Bemühungen zur kulturellen Transformation stehen.

Bist du bereit, agil zu sein?

Über agile Prozesse hinauszugehen und ein agiles Mindset im gesamten Unternehmen zu skalieren, ist nichts, was Sie über Nacht in Angriff nehmen können. Es erfordert Zeit, Mühe, Training und Unterstützung durch Führungskräfte, um agile Werte zu verinnerlichen und die Kommando-Mentalität der Vergangenheit hinter sich zu lassen.

Unterwegs stehen Sie möglicherweise vor Herausforderungen, Sie werden feststellen, dass es immer mehr zu lernen gibt, und Sie müssen agil sein, wenn es um die Einführung von Agile geht.

Der Preis für echte Agilität ist jedoch erheblich, einschließlich der Steigerung der Kundenzufriedenheit, der Steigerung des Mitarbeiterengagements und der Verbesserung der Produktivität — die Investition lohnt sich also.

Agilität hilft modernen Unternehmen, durch Veränderungen in einer unsicheren und unvorhersehbaren Welt erfolgreich zu sein. Für die meisten von uns ist dies keine wünschenswerte Arbeitsweise mehr — sie ist unverzichtbar.

Lassen Sie uns über den Prozess der Backlog-Verfeinerung sprechen, der früher als Backlog-Grooming bekannt war. Vielleicht kennst du das Pareto-Prinzip und die Philosophie, 80% der Arbeit mit 20% Aufwand zu erledigen. Das klingt wunderbar, oder?

Auf der anderen Seite Raffinieren ein Produkt-Backlog, die Aktualisierung von Backlog-Elementen und Schätzungen mag wie eine luxuriöse Aktivität erscheinen, die man verschiebt, bis sie frei von anderen Aktivitäten im agilen Prozess sind.

Das ist jedoch nicht der Fall. Eine Verfeinerung des Backlogs ist unverzichtbar. Manchmal liegt die Macht im Detail, und beim Backlog-Management könnte das nicht wahrer sein.

Backlog-Refinement ist vergleichbar mit großen Köchen, die ihre neuen Rezepte entwickeln. 🍳 Das liegt daran, dass die Verfeinerung eines Backlogs neben Details auch eine Menge an Lücken und Anpassungen erfordert.

Diskutieren Sie mit uns, was die Verfeinerung eines Backlogs bedeutet. Wir werden uns ansehen, was es ist, wie wichtig es ist, wie man es im Detail macht und einige wichtige Tipps.

Schauen wir uns zunächst an, was Backlog-Refinement ist.

Beseitigen Sie Ihren flachen Backlog mit

Einfacher agiler Teamrhythmus

Jetzt testen

Über die Backlog-Verfeinerung

Die Verfeinerung von Rückständen ist wie das Beschneiden einer Pflanze: Sie werfen die Zweige weg, die nicht mehr benötigt werden, damit Sie der Pflanze helfen können, richtig zu wachsen.

Das bedeutet, dass Sie bereits Elemente in Ihrem Backlog haben, diese jedoch möglicherweise einige Informationen oder ein Update benötigen, bevor sie implementiert werden. Außerdem müssen einige Artikel möglicherweise sogar aus dem Backlog gestrichen werden.

Das Verfeinern des Backlogs spart Zeit und Geld, da sichergestellt wird, dass die Artikel zum richtigen Zeitpunkt für die Entwicklung bereit sind. Es stellt auch sicher, dass kein wertvoller Artikel für Kunden vergessen wird. Auf der anderen Seite wird garantiert, dass nur Artikel verwendet werden, die für den Kunden von Wert sind. All dies hilft Ihnen, den Kundenfokus zu behalten.

Schnappen Sie sich Ihre Gartenschere, denn wir helfen Ihnen dabei, Ihren Rückstand abzubauen. ✂️

Der Product Owner plant höchstwahrscheinlich Arbeitssitzungen, um den Backlog zu verfeinern.

Diese Backlog-Refinement-Sitzungen sollten regelmäßig stattfinden. Sie können das Backlog jedoch informeller verfeinern, solange es sich um einen fortlaufenden Prozess handelt. Neben dem Product Owner sind einige der Scrum-Team Mitglieder können teilnehmen. Denkt daran das Entwicklungsteam, der Scrum Masterund Product Owner sind das Scrum Team. Obwohl der Product Owner das Backlog selbst aktualisieren kann, ist es eine gute Praxis, das Team einzubeziehen.

Neben der Aktualisierung und Vollständigkeit des Backlogs beinhaltet die Backlog-Verfeinerung:

• Aufteilen allgemeiner Benutzerberichte oder anderer Arten von Backlog-Elementen wie Aufgaben oder Bugs sowie Hinzufügen von Details zu ihnen, um das Verständnis zu verbessern
• Hinzufügen oder Überprüfen von Schätzungen zu Problemen, da Schätzungen entscheidend sind für Sprint-Planung
• Ordnen Sie Backlog-Probleme so an, dass sie in den nächsten Tagen mit hoher Priorität behandelt werden Scrum-Iteration

Wichtig: Denken Sie daran, dass der Kunde letztendlich die Prioritäten bestimmt. Das ist einer der Gründe für die Verfeinerung von Backlogs sollte kundenorientiert sein (dazu später mehr).

Tools, die Ihnen helfen, Ihren Backlog kundenorientiert zu halten, helfen Ihnen auch dabei, Ihren Kunden bessere Ergebnisse zu liefern. Einfacher agiler Teamrhythmus ermöglicht es Ihnen, Ihr Backlog und Ihre Sprints im Kontext der User Story Map anzuzeigen, sodass Sie als gesamtes Team auf einen Blick sehen können, welche Arbeit für Ihre Benutzer am wichtigsten ist.

Nachdem Sie nun wissen, was das Verfeinern eines Backlogs ist und wer daran beteiligt ist, wollen wir uns damit befassen, wie das geht.

So verfeinern Sie ein Backlog

Es gibt so viele Möglichkeiten, einen Backlog zu verfeinern, dass es unmöglich wäre, dir die beste zu nennen.

• Sie könnten zuerst verfeinern — aufteilen und detailliert — und dann schätzen, wobei Sie zuerst mit den am wenigsten verstandenen Elementen beginnen.
• Sie könnten zunächst eine Schätzung vornehmen, um zunächst Artikel zu ermitteln, für die eine Verfeinerung vor einer Schätzung erforderlich ist, und erst dann, falls erforderlich, Elemente mit hohem Aufwand verfeinern.
• Sie könnten ein spezielles Tool verwenden, das Sie bei der Verfeinerung oder Schätzung unterstützt, wie z. Einfacher agiler Teamrhythmus, oder Sie könnten sich einfach auf eine Tabelle oder ein Whiteboard und einen Stift verlassen.

Bei der Verfeinerung des Backlogs verfolgen der Product Owner und die beteiligten Teammitglieder die folgenden Ziele:

• Stellen Sie sicher, dass das Backlog korrekt ist, was bedeutet, dass es alle erforderlichen Elemente enthält.
• Behalten Sie die Priorisierung dieser Elemente bei.

Sorgen Sie für die Lieferung der wichtigsten Artikel, die ganz oben auf dem Backlog stehen sollten.

Im Zuge der Verfeinerung müssen die Beteiligten möglicherweise das wiederbeleben Produktvision und die Produkt-Roadmap. Es könnte auch hilfreich sein, Folgendes zu erstellen Benutzerpersönlichkeiten und definiere Akzeptanzkriterien, speziell für die Artikeldetaillierung.

Wissen Sie, wie ein Backlog-Element aussieht, das für einen Sprint bereit ist? Wenn nicht, entwickeln Sie eine Definition von erledigt sowie eine Definition von bereit. Erarbeiten Sie dann Punkte wie die folgenden, um die Artikelbereitschaft zu erreichen:

• Vermittlung eines Verständnisses der Akzeptanzkriterien
• Vereinbarung einer Struktur für die vollständige Beschreibung verschiedener Artikelarten
• Definition einer klaren Ansicht der Abhängigkeiten zwischen Elementen
• Identifizierung des Fachexperten für jeden Artikel

Schließlich sollten Sie zuerst Elemente mit hoher Priorität verfeinern. Das sind diejenigen, die Entwickler im nächsten Sprint zuerst implementieren werden.

Denken Sie daran, dass die Backlog-Verfeinerung die Gesamtheit aller Aktivitäten ist, die mit der Verwaltung von Backlog-Elementen zu tun haben. Aber es gibt eine Sache: Bei der Backlog-Verfeinerung gibt es keine Timebox. Laut das Scrum-Framework, es ist nicht eines der Scrum-Ereignisse. Stattdessen ist es ein kontinuierlicher Kreuzzug, und es ist nicht unbedingt ein Treffen (obwohl es das sein kann).

Wenn Sie sich an die Verfeinerung des Backlogs gewöhnen, können Sie die folgenden Fragen verwenden, um Ihren Fortschritt zu bewerten.

Checkliste zur Verfeinerung des Backlogs

Es ist zwar nett, Ziele zu haben, aber Sie müssen bestimmte Maßnahmen ergreifen, um sie zu erreichen. Also, hier ist eine Checkliste, die Sie regelmäßig durchgehen müssen. Du kannst sie verwenden, um entweder zu beurteilen, ob das Backlog verfeinert werden muss, oder um zu bestätigen, dass die Verfeinerung im Moment abgeschlossen ist.

• Enthält das Backlog Anwenderberichte oder andere Arten von Gegenständen, die keinen Sinn mehr machen?
• Haben Sie ein Nutzerbedürfnis ermittelt, das noch nicht in einer geeigneten Form eines Backlog-Elements enthalten ist?
• Erwartet Ihr Kunde, dass Sie dringende Artikel implementieren, die am Ende des Backlogs stehen?
• Hat sich die Wichtigkeit, einen Artikel auszuliefern, seit Sie sich das letzte Mal den Backlog angesehen haben, geändert?
• Hat das Backlog einen Artikel, für den kein agile Schätzung existiert?
• Ist eine Schätzung veraltet?
• Ist ein Backlog-Element zu weit gefasst, um zu verstehen, was Entwickler in das implementieren sollten nächster Sprint?

Sie können nur behaupten, einen verfeinerten Backlog zu haben, wenn Sie alle oben genannten Fragen mit „Nein“ beantworten. Arbeiten Sie bis dahin weiter daran und vermeiden Sie die unten aufgeführten Fallen.

ANSEHEN: Beseitigen Sie Ihren flachen Backlog

Was Sie bei der Backlog-Verfeinerung vermeiden sollten

1. Bitten Sie erfahrenere Teammitglieder, die Backlog-Elemente detailliert zu beschreiben oder Schätzungen abzugeben. Zum Beispiel sind Nachwuchsentwickler dafür nicht gut gerüstet — sprechen Sie mit erfahreneren Teammitgliedern über diese Themen.

2. Beziehen Sie ausgewählte Teammitglieder ein. Wenn Sie mit dem gesamten Team sprechen, wird in der Regel nur Lärm gemacht. Und wie bereits erwähnt, sollten Sie versuchen, erfahrenere Teammitglieder einzubeziehen, anstatt jüngere Mitarbeiter.

3. Dokumentieren Sie Ihre Entscheidungen. Das ist furchtbar wichtig. Das menschliche Gedächtnis ist unzuverlässig. Um also gute Entscheidungen zu wiederholen und schlechte zu vermeiden, sollten Sie beide im Laufe der Zeit dokumentieren.

4. Geben Sie Backlog-Elemente nicht übermäßig detailliert an. Oder Sie riskieren, dass Entwickler nicht wissen, was sie mit ihnen anfangen sollen. Eine gute Möglichkeit, dies zu vermeiden, besteht darin, einige Mitglieder des Entwicklungsteams in die Verfeinerung des Backlogs einzubeziehen.

5. Sie sollten Backlog-Elemente, die sich derzeit in der Entwicklung befinden, nicht verfeinern. Du solltest das Backlog für den nächsten Sprint oder nachfolgende Sprints verfeinern.

6. Verfeinere den Backlog des aktuellen Sprints erst, wenn er endet. Sie könnten versucht sein, Backlog-Elemente nur bis zur allerletzten Minute zu verfeinern. Das ist nicht gut. Unerwartete Dinge passieren, wie z. B. geschäftige Tagesordnungen und Diskussionen, die länger dauern als erwartet. Das hat zur Folge, dass Sie möglicherweise nicht das liefern, was erwartet wird.

7. Vermeiden Sie Unstimmigkeiten bei Schätzungen. Das ist normalerweise ein Zeichen dafür, dass es diesem Gegenstand an Raffinesse mangelt. Höre auf die Leute, die die höchsten oder niedrigsten Schätzungen vorschlagen. Sie sind in der Regel diejenigen, die die Artikel nicht verstanden haben, weil entweder Informationen fehlen oder zu viele Informationen fehlen.

8. Lassen Sie mehrere Personen die Schätzungen abwägen. Wenn Sie nur eine Person fragen, kann dies zwar die Schätzung beschleunigen, aber das zeugt nicht von einem gemeinsamen Verständnis. Und das ist etwas, woran Sie bei der Backlog-Verfeinerung interessiert sein sollten.

Wenn Sie sich nicht sicher sind, ob Sie diesen Vorgang durchführen müssen, werfen Sie einen Blick auf die folgenden Vorteile.

Bewährte Methoden zur Aufrechterhaltung eines DEEP-Backlogs

Ein wirklich effektiver Backlog folgt dem DEEP-Prinzipien - Angemessen detailliert, geschätzt, aktuell und priorisiert. So können Sie diese Prinzipien in Ihrem täglichen Backlog-Management operationalisieren:

Angemessen detailliert

• Fortschrittliches Ausarbeitungssystem: Implementieren Sie einen mehrstufigen Detaillierungsansatz, bei dem Elemente immer detaillierter werden, wenn sie im Backlog nach oben gelangen:
  • Stufe 1 (Anfang des Backlogs): Vollständig detailliert mit Akzeptanzkriterien, Modellen und technischen Hinweisen
  • Stufe 2 (die nächsten 2-3 Sprints): Grundlegende Akzeptanzkriterien und erste technische Bewertung
  • Stufe 3 (weiter draußen): Minimale Details, gerade genug, um Umfang und Zweck zu verstehen
• Checkliste auf Detailebene: Erstellen Sie für jede Prioritätsstufe eines Backlog-Eintrags eine standardisierte Checkliste zur „Vollständigkeit der Details“:

Checkliste für Artikel mit hoher Priorität:
☐ Akzeptanzkriterien definiert
☐ UI/UX-Überlegungen dokumentiert
☐ Abhängigkeiten identifiziert
☐ Technischer Ansatz skizziert
☐ Spezifizierte Testanforderungen

• Just-in-Time-Detaillierungssitzungen: Planen Sie 30-minütige Sitzungen ein, die ausschließlich der detaillierten Beschreibung bestimmter Punkte mit hoher Priorität gewidmet sind, die kurz vor der Implementierung stehen. Konzentrieren Sie sich dabei auf einen Punkt nach dem anderen, anstatt zu versuchen, alles auf einmal detailliert zu beschreiben.

Geschätzt

• Workshop zur Kalibrierung von Schätzungen: Halten Sie eine vierteljährliche Kalibrierungssitzung ab, bei der das Team einige abgeschlossene Elemente erneut schätzt, um zu überprüfen, ob sich ihre Schätzgenauigkeit verbessert oder angepasst werden muss.
• System zur Bewertung des Vertrauens: Fügen Sie jeder Schätzung ein Konfidenzrating (hoch/mittel/niedrig) bei, um Punkte zu kennzeichnen, die möglicherweise kurz vor der Umsetzung erneut geschätzt werden müssen.
• Bibliothek mit Referenzgeschichten: Pflegen Sie einen kleinen Satz von Referenzberichten mit bekannten Schätzungen, die neue Teammitglieder verwenden können, um ihr Verständnis von Storypoints oder anderen Schätzeinheiten zu kalibrieren.
• Leitung für Rotationsschätzungen: Weisen Sie dem „Schätzungsleiter“ eine rotierende Rolle zu, der das Schätzungsmaterial vorbereitet und die Diskussion komplexer Sachverhalte vor der Verfeinerungssitzung moderiert.

Aufstrebend

• Zeitplan für die Entwicklung des Backlogs: Erstellen Sie eine visuelle Zeitleiste, die zeigt, wie sich die wichtigsten Themen in Ihrem Backlog entwickelt haben. So können Stakeholder besser nachvollziehen, wie sich Prioritäten im Laufe der Zeit von selbst ergeben.
• Tracking aufteilen/zusammenführen: Verfolgen Sie Elemente, die häufig geteilt oder zusammengeführt werden, um Muster zu identifizieren, die auf eine falsche Definition des Bereichs oder ein verändertes Verständnis hinweisen könnten.
• Zeitbox für Innovation: Reservieren Sie 10% der Verfeinerungssitzungen, um potenzielle neue Backlog-Artikel zu besprechen, die auf aktuellem Kundenfeedback, Marktveränderungen oder technischen Entdeckungen basieren.
• Schnittprotokoll: Richten Sie ein klares Protokoll für die Archivierung oder Entfernung von Backlog-Elementen ein, die seit 3-6 Monaten nicht verschoben wurden, und fordern Sie eine ausdrückliche Begründung dafür, dass Elemente, die stagnieren, beibehalten werden.

Priorisiert

• Rahmen für die Priorisierung mehrerer Faktoren: Erstellen Sie ein einfaches Bewertungssystem, das bei der Priorisierung von Artikeln den Geschäftswert, die Auswirkungen auf die Kunden, das technische Risiko und die strategische Ausrichtung berücksichtigt.
• Prioritäre Horizontplanung: Definieren Sie klare „Prioritätshorizonte“, in denen die Elemente nach dem Implementierungszeitrahmen (Jetzt, Weiter, Später, Zukunft) gruppiert werden, anstatt zu versuchen, eine perfekt geordnete Liste mit über 100 Elementen zu führen.
• Überprüfung der Prioritäten der Interessengruppen: Führen Sie einen monatlichen Alignment-Check durch, bei dem die wichtigsten Beteiligten die wichtigsten 10 bis 15 Backlog-Elemente überprüfen, um sicherzustellen, dass die Priorisierung immer noch den aktuellen Geschäftsanforderungen entspricht.
• Matrix zwischen Dringlichkeit und Wichtigkeit: Verwenden Sie eine 2x2-Matrix, um Elemente visuell nach Dringlichkeit und Wichtigkeit zuzuordnen. So können Sie wirklich wichtige und nur dringende Elemente unterscheiden.

Der Wert der Verfeinerung Ihres Backlogs

Durch die Verfeinerung des Backlogs können Sie Zeit und Geld sparen. Früher hat jemand vor der Entwicklung im Grunde genommen ein Dokument mit einer Anforderungsspezifikation in Stein gemeißelt. Angesichts des Aufstiegs von Agile ist das eine alte Geschichte.

Ein Backlog trägt massiv zum Erfolg eines agilen Projekts bei. Es ist ein lebendiges Dokument, was bedeutet, dass es sich im Laufe der Zeit verändert. Aber obwohl es sich ändert, muss es korrekt bleiben. Und es gibt keine strengen Regeln, wenn es darum geht, einen Backlog zu verfeinern. Das bedeutet zum Beispiel, dass nicht für jeden Artikel Details erforderlich sind.

Der Product Owner sollte jedoch sicherstellen, dass die Backlog-Elemente für die Planung bereit sind. 📅 Und ohne Backlog-Verfeinerung wäre das eine Herkulesaufgabe.

Stellen Sie sich vor, Sie treffen Sprintziel ohne:

• Genügend Informationen zu Backlog-Elementen oder Elementen mit umfangreichen, komplexen Beschreibungen
• Veraltete Schätzungen oder gar keine Schätzungen
• Punkte mit hoher Priorität, die am Ende des Backlogs vergessen wurden
• Artikel, die sich nur in den Köpfen der Menschen befinden oder für den Kunden keinen Wert mehr darstellen

Folgendes würde Ihnen bevorstehen:

• Verrückte Entwicklungskalender
• Nicht gelieferte Artikel
• Verspätet gelieferte Artikel
• Wahnsinnige Budgets

Das wäre definitiv keine gute Prognose für die Kundenbindung.

Überbrücken Sie Kundenorientierung mit Ihrer Backlog-Struktur

Die meisten Teams behaupten zwar, kundenorientiert zu sein, aber um die Kundenbedürfnisse wirklich in die Struktur Ihres Backlogs einzubetten, sind systematische Ansätze erforderlich:

Personengetriebene Backlog-Organisation

Erstellen Sie eine Backlog-Struktur, die Artikel explizit mit Kundenpersönlichkeiten und Journeys verknüpft:

• Persona-Tagging-System: Implementieren Sie Tags oder benutzerdefinierte Felder in Ihrem Backlog-Tool, die jedes Element bestimmten Benutzerpersönlichkeiten zuordnen (z. B. „Power User Sarah“ oder „New Customer Alex“).
• Ausrichtung der Kundenreise: Ordnen Sie Backlog-Elemente bestimmten Phasen der Kundenreise zu und stellen Sie so sicher, dass Sie die Bedürfnisse während des gesamten Kundenerlebnisses berücksichtigen.
• Personenbezogene Filterung: Richte Backlog-Views ein, die nach Persona gefiltert sind, um regelmäßig zu überprüfen, ob du bestimmte Nutzertypen vernachlässigst.

Verfahren zur Integration von Kundenstimmen

Richten Sie regelmäßige Rhythmen ein, um Kundenfeedback direkt in das Backlog-Management einzubeziehen:

• Bewertung von Kundeneinblicken: Planen Sie eine monatliche Sitzung ein, in der Kundensupport-Protokolle, Benutzerrecherchen und Analysen speziell überprüft werden, um potenzielle Backlog-Ergänzungen oder Neupriorisierungen zu identifizieren.
• Ergebnisorientierte Gruppierung: Gruppieren Sie Backlog-Elemente nach Kundenergebnissen und nicht nach Funktionen, sodass sich das Team auf das konzentrieren kann, was die Kunden erreichen möchten, anstatt auf bestimmte Implementierungen.
• Verifizierungspunkte für Kunden: Markieren Sie vor der Implementierung bestimmte wichtige Backlog-Elemente zur direkten Überprüfung durch den Kunden und erstellen Sie so eine Feedback-Schleife, die Ihr Verständnis bestätigt.

Rahmen für die Bewertung des Kundenwerts

Implementieren Sie ein schlankes Framework zur Bewertung des Kundennutzens:

Kundenwertskala (1-5):
1: Nett zu haben, minimale Auswirkungen auf die Nutzer
2: Löst kleinere Probleme für einige Benutzer
3: Bemerkenswerte Verbesserung für viele Benutzer
4: Signifikanter Mehrwert für Kernbenutzer
5: Bahnbrechende Funktionen für die Mehrheit der Benutzer

Details ausbalancieren: So vermeiden Sie Zu- und Unterverfeinerung

Für ein effizientes Backlog-Management ist es entscheidend, den richtigen Detaillierungsgrad zu finden. Es ist ein schwieriger Balanceakt, aber mit den richtigen Rahmenbedingungen sollten Sie in der Lage sein, leicht Fuß zu fassen. Hier sind ein paar Ideen:

Das „Just-Right“ -Detaillierungsframework

Implementieren Sie ein visuelles System in Ihrem Backlog-Tool, um den Detailstatus anzuzeigen:

• Rot: Unterentwickelt, erfordert vor der Sprint-Planung viel Arbeit
• gelb: Teilweise verfeinert, wichtige Fragen bleiben
• Grün: Entsprechend detailliert für die aktuelle Priorität

Detailliertes Radardiagramm

Verwenden Sie bei komplexen Objekten ein einfaches Netzdiagramm, um die Vollständigkeit verschiedener Detaildimensionen zu beurteilen:

• Funktionale Anforderungen
• Technische Überlegungen
• Grenzfälle/Ausnahmen
• UX/UI-Spezifikationen
• Testansatz

Verfeinerungsprotokoll mit Zeitrahmen

Legen Sie Zeitlimits auf der Grundlage der Artikelgröße fest:

• Kleine Gegenstände: Max. 15 Minuten Verfeinerungszeit
• Mittlere Artikel: Max. 30 Minuten
• Große Gegenstände: Max. 60 Minuten (oder erwägen Sie das Teilen)

Wenn ein Gegenstand innerhalb dieser Timeboxes nicht ausreichend verfeinert werden kann, ist das ein Zeichen dafür, dass entweder der Gegenstand zu groß ist oder dass es an grundlegendem Verständnis fehlt.

Progressive Detailschwellen

Definieren Sie klare Schwellenwerte für den Zeitpunkt, an dem die Detailgenauigkeit erhöht werden sollte:

• Wenn ein Artikel in die Zone „Die nächsten 2 Sprints“ wechselt: Stellen Sie sicher, dass alle Akzeptanzkriterien definiert sind
• Wenn ein Artikel in die Zone „Nächste Sprint-Kandidaten“ wechselt: Fügen Sie einen technischen Ansatz und eine Teststrategie hinzu
• Wenn ein Element für den bevorstehenden Sprint ausgewählt wird: Letzte Detailprüfung mit dem Implementierungsteam

Dokumentation von Backlog-Entscheidungen zur Rückverfolgbarkeit

Erstellen Sie abschließend ein System, das den Kontext und die Argumentation hinter Backlog-Entscheidungen beibehält.

Integration des Entscheidungsprotokolls

Führen Sie ein überschaubares Entscheidungsprotokoll, das direkt mit den Änderungen im Backlog verknüpft ist. Es würde ungefähr so aussehen:

‍Backlog-Entscheidungsprotokoll

Datum: [Datum]
Artikel: [Artikel-ID/Name]
Entscheidung: [Änderung der Priorisierung, Änderung des Umfangs usw.]
Begründung: [Geschäftlicher Kontext, Kundenfeedback, technische Einschränkungen]
Interessengruppen: [Wer war an der Entscheidung beteiligt oder darüber informiert]
Auswirkung: [Welche anderen Elemente oder Zeitpläne sind betroffen]

Anmerkungen zur Historie von Backlog-Einträgen

Verwenden Sie Kommentare oder einen Verlaufsabschnitt in jedem Backlog-Element, um wichtige Änderungen zu dokumentieren.

• Prioritätsänderungen (und warum)
• Änderungen des Umfangs
• Anpassungen der Schätzungen
• Abhängigkeiten entdeckt

Schnappschüsse zur Backlog-Überprüfung

Machen Sie regelmäßig „Schnappschüsse“ der 20 wichtigsten Artikel Ihres Backlogs und speichern Sie sie mit Daten, um einen historischen Kontext darüber zu erhalten, wie sich die Prioritäten entwickelt haben.

Dokumentation der Übergangskriterien

Dokumentieren Sie explizit die Kriterien, die ein Element von einem Status in einen anderen verschoben haben.

• Warum wurde dieser Artikel in den Sprint aufgenommen?
• Warum wurde diesem Artikel die Priorität entzogen?
• Warum hat sich die Schätzung erheblich geändert?

Regelmäßige Backlog-Gesundheitsaudits

Implementieren Sie einen systematischen Ansatz, um den Status des Backlogs im Laufe der Zeit aufrechtzuerhalten.

Gesundheitscheckliste für den monatlichen Backlog

Datum: [Datum]
Prüfer: [Namen]

Artikel überprüfen
- [] Artikel, die älter als 6 Monate sind, wurden überprüft und aktualisiert/archiviert
- [] Keine verwaisten Artikel (alle mit Epics/Themes verbunden)
- [] Alle Elemente mit hoher Priorität sind ausreichend detailliert
- [] Akzeptanzkriterien, die für ähnliche Artikel einheitlich sind

Überprüfung der Kennzahlen
- Wachstumsrate des Auftragsbestands: [%]
- Fertigstellungsrate der Artikel: [%]
- Durchschnittliche Zeit im Backlog: [Tage]
- Schätzgenauigkeit: [%]

Überprüfung des Kontostands
- Arbeitsverhältnis zwischen technischen Schulden und Funktionen: [Verhältnis]
- Verteilung nach strategischen Themen: [Analyse]
- Verteilung auf Kundenpersönlichkeiten: [Analyse]

Aktionselemente
1. [Aktion]
2. [Aktion]
3. [Aktion]

Vitalitätsscore im Backlog

Du kannst sogar ein einfaches Bewertungssystem (0-100) für den Zustand des Backlogs erstellen, das auf folgenden Faktoren basiert:

• Aktualität (wann Artikel zuletzt aktualisiert wurden)
• Qualität der Details
• Klarheit bei der Priorisierung
• Strategische Ausrichtung
• Technischer Schuldenstand

Verfolgen Sie diesen Wert im Laufe der Zeit, um Trends zu identifizieren.

Automatisierung der Erkennung von Veraltungserkennung

Richten Sie die automatische Kennzeichnung für potenziell veraltete Backlog-Elemente ein.

• Keine Aktivität seit über 90 Tagen
• Keine aktuellen Änderungen, obwohl sie hohe Priorität haben
• Schätzungen oder technische Ansätze, die vor größeren Systemänderungen liegen

Die Verfeinerung des Backlogs ist ein wesentlicher Prozess

Wenn du an Weltraummissionen denkst und sie mit Backlog-Refinement vergleichst, ist der Backlog dein Missionsleitfaden. 🚀 Und wenn du keinen verfeinerten Backlog hast, bringt dich dein Missionsführer nicht weiter als in deinen Hinterhof. 😨

Die Verfeinerung des Backlogs sollte dir dabei helfen, dauerhaft relevante Gegenstände in deinem Backlog zu haben. Und mit relevant meinen wir vollständig, wertvoll, detailliert und doch übersichtlich, vor Kurzem geschätzt und korrekt bestellt.

Es ist zwar SEHR leicht, die Bedeutung der Backlog-Verfeinerung zu vergessen, aber tun Sie das nicht. Es ist wichtig, sich auf den aktuellen Sprint zu konzentrieren, aber das Wichtigste ist, ein zufriedenstellendes Produkt zu liefern. Und ein entsprechend ausgefeilter Backlog fördert den Teamgeist.

Außerdem sollten Sie nicht der Product Owner sein, der während eines Sprint-Planungsmeetings einen Eimer voller Fragen bekommt. Das ist ein starker Hinweis darauf, dass die Backlog-Verfeinerung episch gescheitert ist.

Einfacher agiler Teamrhythmus kann Ihnen helfen, User Stories zu verfeinern, indem es Ihnen Folgendes ermöglicht:

• Bewertung in User Stories registrieren
• Ziehen Sie User Stories per Drag-and-Drop, um sie nach Kundennutzen und Geschäftswert zu priorisieren

Probiere diese Tipps bei der Backlog-Verfeinerung aus. Wir sind sicher, dass du es lieben wirst, und wenn du Hilfe brauchst, sind wir für dich da und helfen dir gerne weiter.

Kennen Sie den Unterschied zwischen Agile und Waterfall und haben Sie darüber nachgedacht, welches für Ihr Unternehmen am besten geeignet ist?

Jagen Sie keinen Wasserfällen hinterher — es sei denn, Sie suchen nach einer Projektmanagement-Methode. 😁 Die Wasserfallmethode ist ein gängiges Framework, das Teams seit Jahren verwenden. Aber es ist nicht die einzige Methode, Dinge zu tun, und je nach den Bedürfnissen Ihres Teams ist es möglicherweise nicht die beste Methode.

In diesem Beitrag werden wir die Unterschiede zwischen agilen Methoden und Wasserfallmethoden behandeln, einschließlich der Vor- und Nachteile der einzelnen Methoden. Wir werden auch eine mögliche Alternative vorstellen, die sogenannte Hybridmethode, die für bestimmte Teams das Beste aus beiden Welten bieten kann.

Erstelle eine visuelle Roadmap-Zeitleiste deiner Jira-Probleme

Einfache agile Roadmaps

Jetzt testen

Agil gegen Wasserfall

Wenn es um Agile und Waterfall geht, haben diese Methoden nicht viel gemeinsam. In vielerlei Hinsicht ist Agile die Antwort auf die Einschränkungen der häufig verwendeten Wasserfallmethode. Es gibt jedoch definitiv immer noch Vor- und Nachteile für jedes Framework.

Lassen Sie uns diese beiden Methoden genauer untersuchen.

Die Wasserfall-Methodik

Wir beginnen mit dem Wasserfallansatz, da er etwas einfacher zu erklären ist. Die Idee eines Wasserfalls mag majestätisch und gewagt klingen, aber die Wasserfallmethode ist ziemlich traditionell und unkompliziert.

Das Wasserfallmodell wird verwendet, um das traditionelle Projektmanagement zu beschreiben, bei dem ein Projektplan von einem Projektmanager vor Arbeitsbeginn erstellt wird. Projektanforderungen und Aufgaben werden im Voraus geplant und dem Team zur Verfügung gestellt, das dann bis zur Projektabwicklung an einer Aufgabe und dann an der nächsten arbeitet.

Die Aufgaben werden in der Reihenfolge erledigt, in der sie im ursprünglichen Plan festgelegt wurden. Die sequentielle Reihenfolge der Aufgaben, die von einer zur nächsten kaskadieren, gibt dem Wasserfall-Projektmanagement seinen Namen.

Waterfall ist eine weit verbreitete Projektmanagement-Methode, die jedoch ihre Grenzen hat. Der strikte Ansatz hilft den Teams, in jedem Schritt eines Projekts zu wissen, was sie erwarten können. Er ist jedoch nicht sehr anpassungsfähig und es kann sein, dass das gesamte Team keinen Input hat.

Dieser Mangel an Flexibilität hat moderne Teams behindert. Es macht es schwieriger, bei Bedarf die Gänge zu wechseln. Ein vorgegebener Plan lässt nicht viel Spielraum für Änderungen, und es wird versäumt, sich an das unschätzbare Feedback von Stakeholdern und Kunden anzupassen.

Wasserfall-Profis

• Zu Beginn werden klare Ziele und Vorgaben festgelegt.
• Es gibt eine einfache Struktur, die sich Projekt für Projekt wiederholt.
• Für Teammitglieder ist es leicht zu verstehen, was von ihnen erwartet wird.
• Der allgemeine Druck auf die Mitarbeiter ist geringer.
• Es ist einfacher, sich einzuarbeiten, insbesondere für neue Mitarbeiter.
• Informationen können problemlos an alle Teammitglieder weitergegeben werden.
• Der Erfolg wird an der Erledigung von Aufgaben gemessen, was zu einer schnelleren Befriedigung führt.
• Budgets können genauer vorhergesagt werden.
• Das Endergebnis eines Projekts wird von Anfang an festgelegt, sodass der Weg für alle Beteiligten klar ist.
• Die meisten Planungen werden von einer Person geleitet.

Wasserfall-Nachteile

• Der Prozess ist nicht so flexibel wie agile Ansätze.
• Es ist schwierig, Hindernisse und Abhängigkeiten vorherzusehen, die die Arbeit verzögern könnten.
• Die Arbeit ist nicht immer gleichmäßig auf das Team verteilt.
• Eine Projektüberlastung ist möglich.
• Kurzlebige Teams können Konflikte ignorieren, um das Projekt abzuschließen.
• Es ist schwierig, die Richtung oder den Umfang der zu erbringenden Leistungen zu ändern, wenn ein Projekt einmal begonnen hat.
• Während der gesamten Projekt- oder Produktentwicklung ist der Kunde weniger involviert.
• Die Beteiligten sehen möglicherweise erst am Ende eines Projekts oder bis ein Endprodukt fertiggestellt ist, Fortschritte.
• Es gibt keine frühe Testphase, um sicherzustellen, dass ein Projekt oder Produkt auf dem richtigen Weg ist.

Die agile Methodik

Agil ist ein iterativer Ansatz, bei dem der Schwerpunkt auf Testen und Anpassen liegt. Dabei werden frühzeitiges Feedback und die Einbindung der Interessengruppen genutzt, um den bestmöglichen Weg in die Zukunft zu finden. Bei Agile gibt es immer noch einen Plan, der jedoch weder starr noch streng ist und viel Spielraum lässt, um sich anzupassen und im Laufe der Zeit zu wachsen.

Einfache agile Roadmaps: Das einfachste und flexibelste Roadmapping-Tool für Jira

Jetzt testen

Der Plan entwickelt sich im Zuge der Erfassung neuer Informationen weiter, um sicherzustellen, dass das Endergebnis den Bedürfnissen der Kunden und Interessengruppen entspricht. Anpassungsfähigkeit spielt in agilen Praktiken eine große Rolle, und genau das hat so viele Teams von der Methodik überzeugt. Die Fähigkeit, sich an Veränderungen anzupassen, ist heute eine gefragte Stärke, wenn man das Tempo bedenkt, mit dem sich der Wandel in Technologie, Wirtschaft, globalen Märkten und mehr vollzieht.

Agile Profis

• Das gesamte Team ist an der Planung beteiligt.
• Feedback ist von zentraler Bedeutung für den Prozess.
• Kunden und Stakeholder sind beteiligt.
• Die Kundenreise steht im Mittelpunkt, wenn eine Entscheidung getroffen wird.
• Das Team kann sich anpassen, wenn neue Informationen erfasst werden.
• Unterwegs können Änderungen vorgenommen werden, um Straßensperren oder ins Stocken geratene Arbeiten zu vermeiden.
• Die Kapazität (Arbeitsbelastung) jedes Teammitglieds wird kontinuierlich bewertet, um Burnout zu verhindern.
• Langjährige Teams lernen weiterhin, wie man zusammenarbeitet.
• Die Prozesse werden in jeder Phase des Projekts/Produkts kontinuierlich verbessert.
• Alle Stimmen in einem Team, unabhängig von der Rolle, werden gehört, wenn es darum geht, sich zu versammeln Rückblick Rückmeldung.

Agile Nachteile

• Agile Techniken und Terminologie können schwer zu verstehen sein.
• Teams können eine Weile brauchen, um die richtigen agilen Methoden zu erlernen.
• Agile Teams erhalten möglicherweise nicht die Unterstützung, die sie vom Management und den Geschäftsinhabern benötigen.
• Möglicherweise sind nicht alle Teammitglieder an das agile Framework gebunden, was zu einer Diskrepanz im gesamten Team führt.
• Mangelnde Unterlagen können die Details unklar machen.
• Budgets können unvorhersehbar werden, wenn sich herausstellt, dass das Projekt/Produkt in eine andere Richtung gehen muss.
• Der Umfang eines Projekts/Produkts kann weiter wachsen (Scope Creep).
• Die vielen agile Besprechungen nehmen viel Zeit in Anspruch.
• Es ist schwieriger, neue Mitarbeiter zu finden, die Erfahrung mit agilen Methoden haben.

Agile ist ein weit gefasster Begriff, der eine Reihe verschiedener Frameworks abdeckt, die agile Praktiken verwenden. Lean, DevOps, Kanban, und Scrum sind alle verschiedene Formen von Agile, die unterschiedliche Bedürfnisse erfüllen.

Zum Beispiel beinhaltet das Scrum-Framework die Wiederholung von Sprints, die häufig von agilen Softwareentwicklungsteams verwendet werden. Wenn Sie noch nie von Scrum gehört haben, ist das vielleicht eine Menge, die Sie in sich aufnehmen müssen. 🤯

Ein Scrum dauert zwei Wochen, beginnend mit Sprint-Planung, wenn der Product Owner Entscheidungen zur Priorisierung darüber trifft, welche Backlog-Elemente (Aufgaben) im kommenden Sprint erledigt werden sollen. Von dort aus arbeitet das Team an den spezifizierten Aufgaben, geleitet von einem Scrum Master wer leitet tägliche Standup-Meetings, um alle über den Projekt-/Produktfortschritt auf dem Laufenden zu halten. Schließlich finden am Ende des Sprints ein Sprint-Review und eine Sprint-Retrospektive statt, um sicherzustellen, dass sich das Team kontinuierlich weiterentwickelt und verbessert.

Einfache Agile User Story Maps: Erzielen Sie eine reibungslosere Sprint-Planung und eine einfachere Backlog-Verfeinerung.

Jetzt testen

Interessiert daran, mehr über andere beliebte agile Methoden zu erfahren? Es stehen so viele zur Auswahl! Wir haben darüber berichtet 8 beliebte Entwicklungsmethoden in einem früheren Beitrag.

Die hybride Methodik

Muss die Wahl zwischen Agilität und Wasserfall liegen? Sie denken vielleicht, können wir nicht all diese Vorteile zusammenfassen? Das hybride agil Ein Ansatz kann für einige Teams das Beste aus beiden Wörtern bieten.

Ein Hybridmodell kombiniert die wertvollen Techniken, die sowohl von Waterfall- als auch von Agile-Frameworks bereitgestellt werden. Sie könnten beispielsweise mit einer Reihe agiler Sprints für das Prototyping und das Einholen von Feedback beginnen, gefolgt von einem einzigen Aktionsplan, der sich auf nicht-agile Techniken bezieht. Es kann das Beste aus beiden Welten sein und es kann als Sprungbrett dienen, während ein Team versucht, ein vollständiges agile Transformation.

Ein hybrider Ansatz kommt häufig beim agilen Projektmanagement und anderen unkonventionellen agilen Anwendungen ins Spiel. Agile wurde ursprünglich für die Softwareentwicklung konzipiert, aber Teams in allen möglichen Branchen übernehmen kontinuierlich Aspekte der Agilität. Die agilen Methoden, die von Softwareentwicklern beobachtet werden, funktionieren nicht immer für andere Arten von Teams. Agilität kann ein schwieriger Übergang sein, insbesondere wenn Teams daran gewöhnt sind, dass Dinge auf andere Weise erledigt werden.

Ein Ansatz, der Ihren Bedürfnissen entspricht

Nehmen Sie sich bei der Auswahl des für Ihr Team, Ihr Unternehmen oder Ihr Unternehmen am besten geeigneten Ansatzes Zeit, um die Bedürfnisse des Teams sowie Ihrer Kunden und Stakeholder zu berücksichtigen. Agilität mag eine schwierige Umstellung sein, aber wenn Sie glauben, dass die Vorteile Ihre Prozesse verbessern und Ihrem Unternehmen langfristig helfen werden, ist es vielleicht an der Zeit, den Umstieg vorzunehmen. Ein hybrider Ansatz kann Ihnen helfen, dieses Ziel schrittweise zu erreichen, ohne dass Ihre aktuellen Prozesse so stark beeinträchtigt werden.

Easy Agile hilft Teams mit Leidenschaft dabei, besser zu arbeiten, indem agile Tools, die für Jira entwickelt wurden. Wenn Sie mehr über agile und andere Methoden erfahren möchten, folgen Sie den Einfacher Agile-Blog. Es steckt voller Anleitungen, Tipps und Strategien — und wenn das Lesen von Inhalten nichts für Sie ist, haben wir eine Podcast auch! 📢

Agile Retrospektiven bieten Möglichkeiten zur Selbstbeobachtung. Wie bei vielen Dingen im Leben ist das Ende fast so wichtig wie der Anfang. Deshalb ist es wichtig, das, was während der gesamten Iteration schief gelaufen ist, zu verbessern und zu wiederholen, was gut gelaufen ist.

Das retrospektive Treffen sollte in regelmäßigen Abständen abgehalten werden, um die Teamprozesse und -ergebnisse zu analysieren. Die Reflexion über den letzten Sprint sollte als Richtschnur für den nächsten Sprint dienen.

Sprint-Retrospektiven sind ebenfalls informell, aber strukturiert. Informalität ist ein typisches Merkmal einer Retrospektive, die zur Problemlösung anregt.

In diesem Artikel besprechen wir, was eine agile Retrospektive ist, wie man sie erfolgreich leitet und wie man das Format der Retrospektive nutzt.

Was ist eine agile Retrospektive?

Eine agile Retrospektive ist auch bekannt als Sprint- oder Segelboot-Retrospektive.

Das Scrum-Leitfaden bietet eine klare Definition der agilen Retrospektive. Laut dem Leitfaden kann das agile Team die Sprint-Retrospektive als Gelegenheit nutzen, um schnelles Feedback für kontinuierliche Verbesserungen einzuholen. Kontinuierliche Verbesserung erfolgt durch kontinuierliche Teamarbeit und Arbeitsanalysen.

Während des Treffens bespricht das Team, was gut gelaufen ist und was nicht. Es sollte das Gute identifizieren, das es wiederholen will, sowie die Bereiche, die angepasst werden müssen, damit der nächste Sprint reibungsloser ablaufen kann.

So funktionieren die 12 Prinzipien des Agiles Manifest beschreibt Rückblicke: „In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden kann, und passt dann sein Verhalten entsprechend an.“

So implementieren Sie ein Sprint-Retrospektiv-Format

Sie können die agile Retrospektive entweder nach jedem Sprint, Quartal oder dem gesamten Projekt implementieren. Sie sollten jedoch in regelmäßigen Abständen eine Retrospektive durchführen, um die Iterationen und Verbesserungen fortzusetzen.

Verwenden Sie für jedes Meeting ein retrospektives Format. Die Erstellung eines Forums für eine Retrospektive ist ein guter Anfang. Es schafft die Voraussetzungen für das beteiligte Team und es weiß genau, was erwartet wird.

Wir haben retrospektive Boards hinzugefügt Einfacher agiler Teamrhythmus um Ihnen und Ihrem Team bei einem größeren Teil des agilen Zyklus zu helfen, von der Planung bis zur Überprüfung.

So planen Sie das Sprint-Rückblick:

1. Vorbereitung

Wie bei einem Standup-Meeting sollte Ihre Vorbereitungszeit für die Retrospektive etwa 15 Minuten dauern. Das Retro-Meeting ist wie ein Treffen mit magerem Kaffee, bei dem die Tagesordnung relativ unstrukturiert, aber demokratisch ist. Jeder kann seinen Beitrag leisten.

Idealerweise solltest du ein nachträgliches Forum einrichten, in dem Teammitglieder Feedback erfassen können, sobald es entsteht. Denke daran, die Teammitglieder daran zu erinnern, ihre Gedanken vor der Besprechung dem Board mitzuteilen.

Das Rückblickboard hilft dabei, den Retro-Prozess durch Aufgaben zu leiten, bei denen das Team zu kurz kam oder sich durch Aktionsgegenstände hervorgetan hat. Es hilft auch dabei, Bereiche zu identifizieren, in denen Verbesserungen möglich sind, und die Maßnahmen zu identifizieren, die die Gruppe ergreifen muss, um Veränderungen zu bewirken.

Wenn Teammitglieder vor Ort keine Software verwenden, um ihre agile Retrospektive zu ermöglichen, können sie eine andere Technik anwenden. Diese Technik beinhaltet in der Regel ein Whiteboard, Post-Its und Marker, die das Brainstorming während des gesamten Meetings leiten.

Welche Methode auch immer (Scrum oder Kanban), die der Scrum Master verwendet, hilft eine visuelle Darstellung dabei, die bestmöglichen Ergebnisse für zukünftige Arbeitsabläufe zu erzielen.

Heißer Tipp 🔥

Es ist am besten, einen neutralen Moderator oder agilen Coach hinzuzuziehen, der diesen Prozess leitet. Diese Technik sollte dazu beitragen, die Teammitglieder zur Teilnahme und zum Austausch zu ermutigen, ohne sich unter Druck gesetzt zu fühlen.

2. Verwenden Sie die Vorlage für den Rückblick als Richtschnur für Ihr Tagesordnungsformat

Der Vorstand für die Rückschau hilft bei der Festlegung der Tagesordnung für das Sitzungsformat. Ganz gleich, ob Sie starten, beenden, weitermachen, froh, traurig, wütend oder den persönlichen Favoriten unseres Teams wählen — hohe Töne, tiefe Töne und das Halten des Takts. Stellen Sie sicher, dass Sie es an die Bedürfnisse Ihres Teams anpassen.

In der Regel besteht das Verfahren aus sechs Schritten:

2.1 Die Bühne bereiten

Frischen Sie bei Bedarf Ihr Gedächtnis über Themen und Geschichten im letzten Sprint auf. Stellen Sie einen Timer ein und geben Sie dem Team etwas mehr Zeit, um alle kurzfristigen Gedanken oder Dinge hinzuzufügen, die möglicherweise noch fehlen

Zu Beginn der Retrospektive sollte der Scrum Master den Product Owner, die Teammitglieder und andere relevante Stakeholder vorstellen.

Heißen Sie alle willkommen und lassen Sie sie wissen, dass ihre Teilnahme wertvoll ist. Informieren Sie die Teammitglieder darüber, dass Ehrlichkeit entscheidend für positive Ergebnisse ist. Stellen Sie sicher, dass neue Teams wissen, dass Fragen willkommen sind und dass der Erfahrungsaustausch für eine erfolgreiche Sprint-Retrospektive unerlässlich ist.

Wirf einen Eisbrecher ein, um den Ton des Treffens festzulegen. Ein kurzes Spiel mit „Zwei Wahrheiten und einer Lüge“ kann schnell für eine entspannte Atmosphäre sorgen, wenn Sie genug Zeit haben.

Teilen Sie dem Team mit, wie viel Zeit es dauern sollte, jeden Abschnitt des Sprint-Reviews abzuschließen. Um alle auf dem Laufenden zu halten, kann sich der Timer auch hier als nützlich erweisen.

2.2 Feiere die Siege

Gratuliere den Teammitgliedern, die sich ausgezeichnet haben. Besprechen Sie die Veröffentlichung von Erfolgsgeschichten auf LinkedIn oder anderswo, bevor Sie mit dem Sprint-Review fortfahren. Interagiere mit Gegenständen, die auf dem Retro-Board erstellt wurden, reagiere mit einem Emoji oder hinterlasse einen Kommentar.

2.3 Daten sammeln

Die Datenerfassung umfasst das Sammeln von Informationen von Teammitgliedern zu Problemen im Sprint-Retrospektiv. Ziel ist es, dass das Team die Ursache der Probleme aufdeckt.

Die Teammitglieder beginnen diesen Prozess mit dem Austausch von Sprinterfahrungen. Ob die Erfahrung gut, schlecht oder hässlich war — teile sie mit anderen. Es ist immer eine gute Idee, festzuhalten, wie sich alle fühlen. Nehmen Sie an einer Stimmungsumfrage teil, um das allgemeine Gefühl im Team zu verstehen.

Teilen Sie mit, welche Prozesse Sie verwendet haben und welche Meilensteine Sie erreicht haben. Wenn Teammitglieder neue Technologien angewendet haben, teilen Sie uns mit, wie diese funktioniert haben. Wenn sie neue Tools verwendet haben, teilen Sie allen die Vor- und Nachteile der einzelnen Tools mit. Was auch immer die Erfahrung war, lassen Sie alle wissen, was gut funktioniert hat und was eine Enttäuschung war.

Der Scrum-Master kann diese Phase erleichtern, indem er die „Fünf-Warum-Methode“ anwendet. Die „Fünf Warum“ beziehen sich im Wesentlichen auf die fünfmalige Frage, warum ein Problem aufgetreten ist. Wenn Sie die Frage mehrmals wiederholen, wird tiefgründiges Nachdenken unterstützt, um der Ursache des Problems auf den Grund zu gehen.

2.4 Brainstorming-Lösungen

Sobald die Teammitglieder die Mängel des vorherigen Sprints identifiziert haben, können sie Lösungen finden.

Bei der Teamsitzung sollte es nun um Zusammenhänge zwischen Problemen und Lösungen gehen. Das Verknüpfen von Problemen und Lösungen erfordert Verständnis. Sobald das Team seine Fehler verstanden hat, kann es sich mehrere Lösungen überlegen, um jeden Problembereich durch bessere Maßnahmen zu lösen.

Bringen Sie so viele Ideen wie möglich ein, um mehrere Lösungen in Betracht zu ziehen. Sobald sich das Team über den Aktionspunkt einig ist, sollten Sie ihn unbedingt festhalten, damit die entsprechenden nächsten Schritte eingeleitet werden können.

Der retrospektive Vorstand in Teamrhythmus befindet sich neben deiner Arbeit in Jira, sodass rückblickende Elemente hinzugefügt werden können, wenn der Sprint oder die Version fortschreitet. Aktionspunkte aus der Retrospektive können in Jira-Probleme umgewandelt werden, sodass Elemente, die eine Aktion wert sind, am Ende der Diskussion nicht verloren gehen.

Das Scrum Master sollte auch sicherstellen, dass das Team in dieser Phase befugt ist, entsprechende Lösungen vorzuschlagen. Wenn sie nicht befugt sind, Probleme zu lösen, muss der Scrum Master das Problem auf eine höhere Ebene bringen.

2.5 Wählen Sie praktikable Lösungen

Nicht alle Lösungen aus der Brainstorming-Phase werden realisierbar sein. Bitten Sie das Scrum-Team, einschließlich des Product Owners, für jedes Problem drei vielversprechende Lösungen auszuwählen. Sie können verschiedene Techniken verwenden, um diesen Prozess einzugrenzen, und die Teammitglieder bitten, abzustimmen. Vielleicht möchtest du es mit einer Punktabstimmung versuchen oder positiv abstimmen, indem du der Lösung einen Daumen hoch gibst.

Bei der einfachen Abstimmung muss jeder die Lösung auswählen, die für ihn in der Folgeaktivität am besten geeignet ist. Bei der Punktabstimmung finden die Meeting-Teilnehmer die besten drei Lösungen, indem sie einen Punkt auf drei der Ideen platzieren, von denen sie glauben, dass sie am wertvollsten sind.

Schließlich bedeutet das Mehrstimmensystem, dass der Scrum Master jedem Punkte gibt. Das Scrum-Team muss diese Punkte dann für eine oder mehrere der besten Ideen vergeben.

2.6 Beenden Sie das Meeting

Beenden Sie das Meeting mit einer positiven Note, bevor Sie mit dem nächsten Sprint fortfahren. Versuche zu gehen mit:

• Eine detaillierte Zusammenfassung des vorherigen Sprints
• Eine detaillierte Sprint-Planungsübung für das nächste Sprint-Meeting
• Klare Aktionspunkte und nächste Schritte
• Arbeiten Sie als Team zusammen, um festzustellen, ob dieses Ergebnis effektiv ist oder für die nächste Iteration verbessert werden muss

3. Ergebnisse der Sprint-Sitzung im Rückblick

Softwareentwicklungsteams können die S.M.A.R.T.-Kriterien um ihre Lösungen zu analysieren. Das Einholen der Inputs des Product Owners ist ein wertvoller Teil der retrospektiven Treffen, da sie die Prioritäten und Sichtweisen diversifizieren

Der agile Coach oder Scrum Master nimmt die S.M.A.R.T.-Lösungen auf und übersetzt sie in Item-Aktionen. Der Scrum Master sollte die Teammitglieder bitten, Verantwortung für Aktivitäten zu übernehmen, um Eigenverantwortung zu fördern und Verhaltensänderungen zu fördern.

Sobald der Product Owner zustimmt, sollte jede Aktivität Teil des Backlogs werden.

Wie man durch eingehende Selbstbeobachtung zu erfolgreichen Retrospektiven kommt

Eine gründliche Selbstbeobachtung fördert kontinuierliche Verbesserung und Produktivität. Das Befolgen einer Vorlage für den Rückblick hilft dabei, diese Ziele zu erreichen und unterstützt gleichzeitig die integrierte Teamarbeit. Der Product Owner profitiert auch von Ihren Teamleistungen bei jeder Sprint-Retrospektive, was ein vorrangiges Ziel ist.

Verbessern Sie die Teamausrichtung mit Team-Retrospektiven

Einfacher agiler Teamrhythmus unterstützt agile Retrospektiven und hilft Ihnen und Ihrem Team, ein gemeinsames Verständnis der Arbeit zu entwickeln und zu verstehen, wie Sie am besten zusammenarbeiten. Unser Ziel ist es, agilen Teams dabei zu helfen, effektiv zusammenzuarbeiten.

Testen Sie Easy Agile TeamRhythm 30 Tage lang kostenlos

Ihr Unternehmen hat sich endlich dazu verpflichtet, Scrum zu praktizieren. SCHREI!! 🎉 Das gelobte Land liegt vor dir — selbstorganisierte Teams, nachhaltiges Liefertempo und Autonomie, um das Richtige für das Produkt und das Team zu tun. Du kannst es kaum erwarten, loszulegen! (Spoiler-Alarm: In deiner Zukunft gibt es einen agilen Release-Train.)

Das war vor drei Monaten. Heute ist Ihre Produktentwicklungsorganisation ein großes Durcheinander. Die Teams liefern die falsche Arbeit zur richtigen Zeit. Der Code steckt in einem Regal fest und wartet darauf, dass ein anderes Team eine Abhängigkeit bereitstellt. Und das obere Management denkt darüber nach, den Stecker zu ziehen und zu den alten Wasserfallzeiten zurückzukehren.

Wenn Sie in einer großen Organisation mit mehr als 50 Softwareentwicklern und Ingenieuren arbeiten, kann Scrum eine harte Nuss sein. Je größer das Unternehmen, desto wahrscheinlicher sind teamübergreifende Abhängigkeiten, Planungskonflikte und Herausforderungen, die für Transparenz zwischen den Geschäfts-, Produkt- und Entwicklungsteams sorgen. Aber keine Angst...

SAFe zur Rettung! SAFe ist die Abkürzung für skaliertes agiles Framework. SAFe soll großen Unternehmen bei der Implementierung von Scrum helfen und bietet einen Rahmen für die Koordination der Arbeit vieler Scrum-Teams.

Teil des SAFe-Frameworks ist das Konzept eines Agile Release Trains (ART). Wenn Sie mit ARTs nicht vertraut sind, sind Sie hier richtig. Wir erklären, was eine ART ist, warum sie großen Unternehmen hilft, Softwarelösungen effizienter bereitzustellen, und wie Sie eine ART in Ihrem Unternehmen starten können.

Möchten Sie Ihr Team befähigen, das Scaled Agile Framework (SAFe) zu implementieren?

Probieren Sie einfache Agile-Programme aus

Nehmen Sie an einer Demo teil

Also, was ist ein Agile Release Train?

Lassen Sie uns zunächst die Zug-Metapher erklären. Ein Zug fährt die Gleise hinunter, um ein bestimmtes Ziel zu erreichen. Unterwegs kann der Zug an mehreren Depots anhalten und neue Fracht oder Passagiere aufnehmen. Ihre Softwarelösung sind die Bahngleise. Der Beitrag des Teams zu dieser Lösung ist die neue Fracht, die Sie in den Depots abholen. Und das Ziel ist der Geschäftswert, den Sie Ihren Benutzern bieten. Einfach genug, oder?

ARTs helfen einer Gruppe von Teams, sich auf den Geschäftszweck ihrer Arbeit zu konzentrieren und die Bereitstellung von Lösungen zu koordinieren. Ihre Teams sind wahrscheinlich nach Funktionen oder Wertströmen organisiert. Ein ART identifiziert den Input und den Zeitpunkt der Beiträge der einzelnen Teams, die zur Erreichung des Geschäftsziels für den Wertstrom beitragen. Stellen Sie sich das als funktionsübergreifende Koordination bei der Einnahme von Steroiden vor.

Hier sind einige grundlegende Anforderungen für eine ART:

• Der Zeitplan ist fest, sodass der Umfang variabel ist. Aber keine Panik — sobald Ihre Teams ein gleichbleibendes Tempo erreicht haben, wird das Vertrauen in den Umfang zunehmen.
• Alle Teams müssen den gleichen Sprint- und Release-Rhythmus einhalten.
• Jedes Team folgt den Werten und Prinzipien der Agiles Manifest.
• ARTs nehmen an Planungsveranstaltungen für Programminkremente (PIs) und Inspektions- und Anpassungszeremonien (I&A) teil, die Retrospektiven und Systemdemos ähneln.
• Zwischen den Programminkrementen müssen regelmäßig Iterationen für Innovation und Planung (IP) geplant werden. Dies gibt Ihrem großen Team aus einzelnen agilen Teams Zeit, um Innovationen zu entwickeln, die Infrastruktur zu aktualisieren oder an speziellen Schulungen oder einer Hot-Tech-Konferenz teilzunehmen. IP-Iterationen bieten auch einen guten Puffer für den Fall, dass Ihr PI hinter dem Zeitplan zurückbleibt.

Wenn Ihr Unternehmen groß genug ist, benötigen Sie möglicherweise mehrere Agile Release Trains, die sich auf unabhängige Wertströme konzentrieren. Wenn das der Fall ist, benötigen Sie möglicherweise eine zusätzliche Koordinationsebene, die in einer Lösungszug. Aber lassen Sie uns nicht überholen.

Prinzipien eines agilen Release-Trains

Ein Agile Release Train (ART) orientiert sich am Scaled Agile Framework (SAFe), um sicherzustellen, dass mehrere agile Teams sich aufeinander abstimmen und nahtlos zusammenarbeiten können. Hier sind die Kernprinzipien, die einem Agile Release Train zugrunde liegen:

Fester Zeitplan

ARTs halten sich an einen vordefinierten Zeitplan, um die Arbeit konsistent abzuliefern. Dieser Zeitplan ist in Form von Programminkrementen (PIs) organisiert, die in der Regel 12 Wochen lang sind. Der feste Rhythmus hilft den Teams, ihre Arbeit effizient zu planen und durchzuführen.

Zweiwöchentliche Trittfrequenz

Ähnlich wie einzelne agile Teams in Sprints arbeiten, arbeiten ARTs in zweiwöchigen Segmenten, den sogenannten Systeminkrementen. Dieser regelmäßige Rhythmus ermöglicht kontinuierlichen Fortschritt und schnelle Feedback-Zyklen.

Bekannte Geschwindigkeit

Die Kapazität des Zuges, Arbeit mit einem bestimmten Pi — der sogenannten Geschwindigkeit — zu produzieren, wird aus historischen Leistungsdaten abgeleitet. Durch die Aufteilung von Projekten in kleinere Aufgaben können Teams Prioritäten setzen und wichtige Funktionen effektiver bereitstellen.

Schrittweise entwickeln, auf Abruf veröffentlichen

Während die Entwicklung einem starren Zeitplan folgt, ist das Veröffentlichungsdatum flexibel und hängt vom Projektabschluss ab. Dieser Ansatz ermöglicht es den Teams, den Kunden kontinuierlich einen Mehrwert zu bieten, ohne durch feste Veröffentlichungsdaten eingeschränkt zu sein.

Planung der Programminkremente

Die PI-Planung ist ein Eckpfeiler, bei dem alle agilen Teams innerhalb der ART zusammenkommen, in der Regel persönlich, um strategische Ziele für das bevorstehende Inkrement festzulegen. Diese kollaborative Planung stellt sicher, dass alle an einem Strang ziehen und auf gemeinsame Ziele hinarbeiten.

Innovation und Planung

Am Ende jedes PI nehmen die Teams an einer Innovations- und Planungsveranstaltung (IP) teil. Dieser Zeitraum ist der Planung der nächsten Stufe, der Durchführung von Bildungsaktivitäten und der Erfüllung der Infrastrukturanforderungen gewidmet.

Prüfen und anpassen

Um die kontinuierliche Verbesserung zu fördern, veranstalten ARTs am Ende jedes PI eine Veranstaltung zur Überprüfung und Anpassung (IA). Die Teams bewerten ihre Fortschritte und identifizieren Verbesserungsmöglichkeiten im Rahmen eines Workshops zur Problemlösung. So stellen sie sicher, dass sie ihre Prozesse ständig verfeinern und bessere Ergebnisse erzielen.

Rollen in einem SAFe Agile Release Train

Im Allgemeinen verwenden Teams eine ART in einer Scrum-Umgebung, aber SAFe- und agile Release-Train-Konzepte können auf jede agile Methodik angewendet werden, einschließlich Extreme Programming (XP), Lean oder Kanban. Unabhängig von der von Ihnen gewählten agilen Methode sind bestimmte Rollen erforderlich, um eine ART durchzuführen.

Agile Teams

Ohne agile Teams kann es keine ART geben. Danke, Captain Obvious. 🙄

Ein Unterschied zwischen SAFe und traditionellem Scrum besteht darin, dass ARTs es Ihnen ermöglichen, mit Teams zusammenzuarbeiten, die sich einer bestimmten Funktion widmen, wie Frontend- oder Backend-Entwicklung, Qualitätssicherung, DevOps, Sicherheit sowie Geschäfts- oder Produktfunktionen. ART selbst ist funktionsübergreifend, sodass Ihre Teams dies nicht tun müssen.

Jedes Team muss einen Scrum Master und Product Owner haben, genau wie in Scrum.

Release Train Engineers (RTEs)

So wie Scrum Master ihren Teammitgliedern helfen, die Scrum-Prinzipien und Best Practices zu befolgen, sind Release Train Engineers dienende Führungskräfte, die dasselbe für den agilen Release Train tun. RTEs helfen dabei, die korrekte Ausführung von Programminkrementen sicherzustellen, Blockaden zu beseitigen, Risiken zu managen und mit den Teams an Verbesserungen zu arbeiten.

Release Train Engineers berichten in der Regel an ein Agile Management Office oder im Fall von Lean an das Portfoliomanagement-Team.

Produktmanager

Während einige traditionelle Scrum-Teams beide verwenden Produktmanager SAFe arbeitet in einer solchen Größenordnung, dass beide Rollen erforderlich sind. Der Produktmanager bestimmt die Vision, die Roadmap und den Feature-Backlog, während der Product Owner dafür verantwortlich ist, das PI-Ziel mit dem Team zu definieren und die Funktionalität auszuführen.

Einfache agile Programme ermöglicht es Release Train-Ingenieuren und Programmmanagern, Programme effektiv zu verwalten, um eine Abstimmung im großen Maßstab zu gewährleisten.

Probieren Sie einfache Agile-Programme aus

Systemarchitekten

Auch hier ist aufgrund der Größe, in der SAFe-Teams arbeiten, ein Systemarchitekt erforderlich, um die übergeordnete Struktur des Gesamtsystems zu entwerfen, zu bestimmen, wie jedes Teil in das Puzzle passt, und stabile Integrationspunkte zu schaffen, um Daten und Prozesse in ein zentralisiertes ERP zu integrieren.

Geschäftsinhaber

Die Geschäftsinhaber sind dafür verantwortlich, Geschäftsergebnisse wie Umsatz- oder Kundengewinnungsziele zu erreichen. Als Hauptakteur von ARTS agieren Geschäftsinhaber auf strategischer Ebene und werden an Diskussionen über Vision, Roadmap und Programminkrementierung teilnehmen. Ihre Aufgabe besteht darin, sicherzustellen, dass die Produkte so gebaut werden, dass sie bestimmte Geschäftsziele erfüllen.

Kunden

Kunden sind die ultimativen wirtschaftlichen Käufer oder werthaltigen Nutzer der Lösung. Ihr Feedback und ihre Bedürfnisse sind entscheidend für den Erfolg der ART.

Systemteams

Systemteams helfen in der Regel beim Aufbau und der Wartung von Entwicklungs-, kontinuierlichen Integrations- und Testumgebungen. Sie spielen eine entscheidende Rolle dabei, sicherzustellen, dass die Infrastruktur die ART effektiv unterstützt.

Geteilte Dienste

Zu den gemeinsamen Diensten gehören Spezialisten, die für den Erfolg einer ART erforderlich sind, die aber nicht einem bestimmten Zug gewidmet werden können. Dazu gehören häufig Datensicherheitsexperten, Informationsarchitekten, Site Reliability Engineers (SRE), Datenbankadministratoren (DBAs) und viele mehr.

Starte mit deinem Agile Release Train

Also, du bist bereit, auf die ART zu springen! Großartig! Lassen Sie uns die Schritte durchgehen, um Ihnen den Einstieg in Ihre Reise zu erleichtern.

1. Beginne mit dem Training

Sparen Sie nicht an diesem. Sie haben Ihre agilen Praktiken wahrscheinlich mit etwas Training begonnen. Machen Sie das Gleiche hier. All die harte Arbeit und die besten Absichten der Welt können dir nicht helfen, wenn du kein solides Verständnis der Grundlagen hast.

Neben der Schulung der Teams sollten Sie auch Ihre Führungsteams und Führungskräfte schulen. Genau wie zu der Zeit, als Ihr Unternehmen agile Prinzipien eingeführt hat, sollten Sie sicherstellen, dass Sie die Zustimmung dazu haben, ein Verständnis dafür haben, wie agile Release Trains funktionieren und welche Rollen zu ihrer Unterstützung erforderlich sind.

2. Identifizieren Sie Ihre Wertströme

In SAFe gibt es zwei Arten von Wertströmen: betriebliche und entwicklungsorientierte. Ein operativer Wertstrom konzentriert sich darauf, den Endnutzern den Wert zu bieten, der durch den Wertstrom aus der Entwicklung geschaffen wurde. Ein Beispiel könnte die Erfüllung einer Bestellung von einer E-Commerce-Website sein.

Ein Entwicklungswertstrom konzentriert sich auf die Entwicklung der Geschäftslösung, beispielsweise auf den Aufbau einer E-Commerce-Website.

Die Identifizierung Ihrer Wertströme ist wichtig, bevor Sie Personen und Teams auswählen, die an dem Wertstrom arbeiten, und die zusätzlichen Rollen besetzen, die für die ART erforderlich sind. Sobald die Spieler ausgewählt wurden, können Sie mit der Planung beginnen.

3. Bereiten Sie das Programm Increment Backlog vor

Es ist Zeit, deine zu verfeinern Programm-Rückstand und machen Sie sich bereit für die PI-Planung. Planung und Verfeinerung ist am besten, wenn Sie sich persönlich treffen können, aber manchmal ist das in großen Organisationen unmöglich. Wenn Sie ein verteiltes Team haben, stellen Sie sicher, dass Sie einen guten Backlog haben Tool wie Jira um virtuelle Besprechungen zu ermöglichen.

🚨 Auf der Suche nach der kompletten PI Planning-Lösung für Jira?

Probieren Sie einfache Agile-Programme aus

Ideal für die dezentrale, ferngesteuerte oder persönliche Planung von Programminkrementen.

Nehmen Sie an einer Demo teil!

Erstellen Sie Ihre User Stories auf Programmebene, damit sie in eine zweiwöchige Timebox passen, und planen Sie Ihre erste Veröffentlichung. Lassen Sie in der Iteration etwas Spielraum, bis Ihre Teams eine vorhersehbare Geschwindigkeit erreicht haben.

4. Starten Sie das Programm Increment

Jetzt ist es wie immer Scrum. Sie haben Ihren Sprint startklar — führen Sie ihn einfach wie gewohnt aus. Am Ende des Sprints kannst du den Beitrag deiner Teams zum Release Train hinzufügen.

5. Spülen und wiederholen

Agile Release Trains sind ein kontinuierlicher, iterativer Bereitstellungsmechanismus. Genau wie bei traditionellem Scrum werden Ihre Teams etwas entwickeln, veröffentlichen, lernen und dann wieder mit der Entwicklung beginnen. Vergessen Sie nicht, eine Innovations- und Planungsiteration einzuplanen, um dem Team eine Pause vom Trubel zu geben und Zeit zu geben, ihre Systeme oder ihr Team zu verbessern.

Bist du bereit, an Bord zu springen?

SAFe- und Agile Release Trains helfen Teams dabei, agile Entwicklungspraktiken beizubehalten, wenn sie an Größe zunehmen. Was auf den ersten Blick kompliziert erscheinen mag, ist in Wirklichkeit ein gut orchestrierter Prozess, der für die Teamsynchronisierung gemäß den Geschäftswertströmen konzipiert ist.

Nutze das Scrum-Wissen, das du in den einzelnen Teams hast, und trainiere dann in SAFe-Praktiken und bereite dich darauf vor, deinen ersten agilen Release-Train zu erstellen. Sie lernen, indem Sie es tun, aber ersparen Sie sich und Ihrem Unternehmen einige Kopfschmerzen und Geld und investieren Sie zuerst in Schulungen.

Wir haben in diesem Artikel auf einige großartige Lernartikel verlinkt, aber hier sind noch ein paar weitere, die Ihnen helfen sollen, Ihr SAFe-Lernen zu beschleunigen:

• Der ultimative Leitfaden zur PI-Planung [2021 SAFe Edition]
• SAFe Program Board 101: Alles, was Sie wissen müssen
• Scaled Agile Framework (SAFe) 5.0 — Der einfache Agile Review
• Optimieren Sie Ihre Arbeitsabläufe mit einer besseren PI-Planungssoftware
• So bereiten Sie sich auf die verteilte PI-Planung vor

Viel Glück auf deiner agilen Reise und bleib SAFe! (Zu kitschig? 🤦🏽 ‍ ♀️)

Bei Easy Agile orientieren wir uns (natürlich) an agilen Prinzipien und bemühen uns, Softwareentwicklungsteams dabei zu unterstützen, agile Methoden in die Praxis umzusetzen. Da jedoch jeden Tag so viel zu erledigen ist, ist es leicht, die Kernprinzipien der agiles Manifest.

Sie denken wahrscheinlich, dass Sie die agilen Prinzipien schon einmal gelesen haben und sie jetzt in die Praxis umsetzen... den ganzen Tag, jeden Tag. Warum müssen wir sie noch einmal überdenken?

Sie müssen die Prinzipien nicht auswendig lernen. Sie sind viel mehr ein Leitfaden als ein Routineprozess. Aber wenn Sie die agilen Prinzipien mit Ihren täglichen agilen Praktiken abgleichen, wird bestätigt, dass Sie sie in die Tat umsetzen. Dies hilft Ihnen auch dabei, Bereiche zu identifizieren, in denen Verbesserungen möglich sind. 🙌

Die anhaltende Relevanz der Prinzipien des agilen Manifests

Das agile Manifest konzentriert sich auf:

• Kontinuierliche Verbesserung durch Reaktion auf Feedback und Änderungen
• Es ermöglicht Softwareentwicklern und funktionsübergreifenden Teams, sich so zu organisieren, dass Zusammenarbeit und Interaktion gefördert werden
• Kunden in den Entwicklungsprozess einbeziehen und auf ihr Feedback reagieren

Das Manifest skizziert 12 agile Prinzipien, die das A und O der agilen Softwareentwicklung sind. Wir möchten diesen agilen Prinzipien einen praktischen Kontext bieten und werden sie daher in drei Kategorien unterteilen: Entwicklung funktionierender Software durch Organisation, Unterstützung der Teams bei der Zusammenarbeit und Taktiken zur Kundenzufriedenheit.

Organisieren Sie sich, damit Sie funktionierende Software erstellen können

Die ersten agilen Prinzipien, die wir besprechen werden, drehen sich um das Konzept einer funktionierenden Software — ein Produkt, das Ihre Kunden so früh wie möglich im Softwareentwicklungsprozess verwenden können. Sie passen es an, sobald Sie Feedback darüber erhalten, was gut funktioniert und was verbessert werden könnte. Dies steht im Gegensatz zu einem Wasserfall von der Methodik bis zur Entwicklung, bei der es sich um einen lineareren Ansatz handelt, der in der Regel keine iterativen Aktualisierungen zulässt.

Ein Ziel ist es, funktionierende Software zu entwickeln, die kontinuierlich aktualisiert werden kann. Aber das ist leichter gesagt als getan ohne die Hilfe von speziell entwickelten Tools wie Jira, dessen Ziel es ist, agilen Teams bei der Verwaltung ihres gewählten agilen Frameworks zu helfen, sei es Kanban oder Gedränge. (Sie können unseren Leitfaden zu den Unterschieden zwischen lesen Kanban und Scrum... oder wie man sie zusammen benutzt. 💪)

Schauen wir uns nun an, welche der 12 agilen Prinzipien in diese Kategorie fallen — #3, #7 und #8 — und wie Jira dabei hilft, ein Framework zu implementieren, das diesen Prinzipien entspricht.

Agiles Prinzip #3

„Stellen Sie häufig funktionierende Software bereit, von ein paar Wochen bis zu ein paar Monaten, wobei Sie den kürzeren Zeitrahmen bevorzugen.“

Atlassian (die Macher von Jira) fasst zusammen die Verkörperung dieses Prinzips perfekt in seiner Definition eines Sprints: „Ein Sprint ist ein kurzer, zeitlich begrenzter Zeitraum, in dem ein Scrum-Team daran arbeitet, eine bestimmte Menge an Arbeit zu erledigen.“

Agile Sprints laufen zwar über einen kurzen Zeitraum, aber ihre reibungslose Ausführung erfordert für Produktbesitzer und Softwareentwickler viel Arbeit. Zum Glück bietet Jira Möglichkeiten, diese Arbeit zu rationalisieren — sieh dir unseren Leitfaden an Teile deines Sprints automatisieren.

Agiles Prinzip #7

„Funktionierende Software ist das wichtigste Maß für Fortschritt.“

Mit Sprints können Sie sicherstellen, dass Ihr Team schrittweise funktionierende Software bereitstellt. Wenn ein Sprint gut genug geplant ist, kann er als Stopp für die Veröffentlichung Ihrer nächsten Reihe von Features und Funktionen für Ihre Endbenutzer dienen.

Agiles Prinzip #8

„Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Nutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.“

Agile Frameworks wie Scrum können dabei helfen zu messen, ob ein Team ein konsistentes Tempo einhält. Innerhalb von Sprints kann der Aufwand auf verschiedene Arten gemessen werden, wie agile Storypoints. Wenn Sprints abgeschlossen sind, erstellt Jira automatisch einen visuellen Bericht darüber, wie viele Storypoints ein Team in seinem Team von Sprint zu Sprint abschließt Geschwindigkeitstabelle.

Zeit für Teamzusammenarbeit

Du bist ein agiles Team, das funktionierende Software bereitstellt und ein Super-Tool wie Jira nutzt, um deine Arbeit zu planen und deine Fortschritte zu verfolgen. Aber du brauchst eine menschliche Berührung, um wirklich agilen Werten zu folgen. Bitte begrüßen Sie die agilen Prinzipien #4, #6, #11, #5 und #12 auf der Bühne.

Agiles Prinzip #4

„Geschäftsleute und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.“

Tägliche Stand-up-Meetings sind eine Manifestation dieses Prinzips. In diesem Meeting ging jedes Teammitglied auf drei Themen ein: (1) woran sie gestern gearbeitet haben; (2) woran sie heute arbeiten; und (3) was sie daran hindert, heute Fortschritte zu erzielen.

Agiles Prinzip #6

„Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu vermitteln, ist ein persönliches Gespräch.“

Ob in einem persönlichen Meeting oder in einem Remote-Meeting, die Vermittlung von Informationen ist schwierig — aber (puh) wir haben das bereits mit Methoden wie täglichen Sprints und Geschwindigkeitsdiagrammen angegangen, um Informationen zwischen den Teammitgliedern auszutauschen und den Teamfortschritt visuell zu überprüfen. Und schon bald werden Sie andere Möglichkeiten sehen, wie agile Softwareentwicklungsteams sich organisieren und miteinander kommunizieren.

Agiles Prinzip #11

„Die besten Architekturen, Anforderungen und Designs entstehen in Teams, die sich selbst organisieren.“

Nun, zunächst, was genau ist ein sich selbst organisierendes Team? Es bedarf keiner Anleitung oder eines Mikromanagements von außen, um herauszufinden, woran gearbeitet werden muss und wie diese Arbeit definiert und priorisiert wird. Diese Teams finden heraus, wie sie ihre Arbeit planen, iterieren, um diese Arbeit zu erledigen, und arbeiten dann gemeinsam daran, wie sie sich kontinuierlich verbessern können. Das agile Scrum-Zeremonien — Stand Up, Sprint Planning, Sprint Review und Retrospektive — sind ein praktisches Beispiel dafür.

Agiles Prinzip #5

„Baue Projekte rund um motivierte Menschen auf. Bieten Sie ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertrauen Sie darauf, dass sie die Arbeit erledigen.“

Ok, nach diesem Prinzip sind wir aus dem Ruder gelaufen — aber aus gutem Grund. Das Befolgen des Prinzips #11 ist sinnvoll, da gute, selbstorganisierte Teams von Natur aus motiviert sind. Sie arbeiten zusammen, um herauszufinden, wie die Arbeit erledigt werden kann, und um sich gegenseitig zu helfen, wenn jemand nicht weiterkommt. Nichtsdestotrotz ist es wichtig, dass definierte Rollen in einem agilen Team, wie ein Scrum Master, der Teammitglieder motivieren und ihnen Feedback geben kann.

Agiles Prinzip #12

„In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden kann, und passt dann sein Verhalten entsprechend an.“

Dieses Prinzip beschreibt perfekt eine Rückblick — eine Teambesprechung, um über deinen letzten Sprint oder deine letzte Iteration nachzudenken und zu besprechen, wie du dich für den nächsten Sprint verbessern kannst. Indem du diese Fragen beantwortest: (1) Was lief gut? ; (2) Was hätte besser laufen können? ; und (3) Was können wir anpassen, um uns beim nächsten Mal zu verbessern? Ihr Team arbeitet zusammen und interagiert, um effektiver zu werden.

Kundenzufriedenheit erreichen

Nicht zuletzt gehören zu den agilen Prinzipien auch Kundenbedürfnisse. Wer ist Ihr Kunde? Was sind ihre Bedürfnisse? Wie reagieren Sie auf ihr Feedback, um sicherzustellen, dass Sie ein funktionierendes Produkt anbieten, das sie lieben? Geben Sie die Prinzipien #1, #2, #9 und #10 ein.

Agiles Prinzip #1

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

Es stellt sich heraus, dass Sie wissen müssen, wer Ihr Kunde ist, um Ihren Kunden zufrieden zu stellen. 😉 Das erfordert Arbeit. Eine bewährte Methode, um herauszufinden, wer Ihre Kunden sind, besteht darin, Kundenpersönlichkeiten. Dabei handelt es sich um fiktive Profile Ihrer Kunden, die Dinge wie ihre Verhaltensmuster, ihre gemeinsamen Probleme und das Aussehen ihrer allgemeinen demografischen Informationen dokumentieren.

Agiles Prinzip #2

„Wir begrüßen die sich ändernden Anforderungen, auch in der späten Entwicklungsphase. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“

Anforderungen können nur wirksam geändert werden, wenn sie definiert und den Stakeholdern zur Rückmeldung zur Verfügung gestellt werden. Selbst wenn dieses Feedback spät in einem Entwicklungszyklus zu Veränderungen führt, ist das in Ordnung! (Wahrscheinlich erhalten Sie auch Feedback zu der funktionierenden Software, die Sie bereits geliefert haben. 😎) Tools wie ein Produkt-Roadmap oder ein User-Story-Map die visuelle Ansicht Ihres Produkt-Backlogs bieten Ihren Kunden und Stakeholdern eine Plattform, auf der sie Feedback geben können.

Agiles Prinzip #9

„Kontinuierliches Augenmerk auf technische Exzellenz und gutes Design erhöht die Agilität.“

Ein Wort: Rückblick.

Ok, noch zwei Worte: Sprint Review.

Im Zusammenhang mit Prinzip #9 sind die Retrospektive und das Sprint-Review zwei agile Zeremonien, mit denen Sie die Qualität und das Design Ihrer Software kontinuierlich anpassen können, um die Bedürfnisse Ihrer Kunden bestmöglich zu erfüllen.

Agiles Prinzip #10

„Einfachheit — die Kunst, die Menge der nicht geleisteten Arbeit zu maximieren — ist unerlässlich.“

Stellen Sie sich vor, Sie hätten Ansichten Ihrer Kundenprofile (Personas), eine visuelle Abbildung ihrer Reise durch Ihr Produkt (User Story Map) und eine priorisierte Ansicht Ihres Plans zur Auslieferung Ihres Produkts (Roadmap). Was für eine Zeit, um am Leben zu sein! Wenn Sie alle drei Dinge tun, hat Ihr Team wahrscheinlich ziemlich gute Einblicke in die Frage, ob Sie die richtige Arbeit erledigen oder nicht. 💪

Die 12 agilen Prinzipien in die Tat umsetzen

Jetzt verstehst du, wie die agilen Prinzipien in agile Frameworks umgewandelt wurden und wie Tools wie Jira agilen Teams helfen können, mit diesen Frameworks zu arbeiten. Wir haben auch drei effektive Möglichkeiten erwähnt, um diese Prinzipien in die Tat umzusetzen, und unsere Produkte machen es einfach.

• Einfacher agiler Teamrhythmus unterstützt agile Teams von der Planung bis zur Überprüfung mit Funktionen, die User Story Mapping, Backlog-Refinement, Sprint- und Versionsplanung sowie Team-Retrospektiven unterstützen.
• Einfache Agile Personas für Jira bietet Teams einen kundenorientierten Ansatz zur Verfeinerung von Backlogs.
• Einfache Agile Roadmaps für Jira bietet Teams und Stakeholdern visuelle Einblicke in die Vision und den Plan für ein Produkt.
• Einfache agile Programme ist eine komplette PI-Planungslösung, die eine skalierte teamübergreifende Planung und Ausführung einfach macht.

Schauen Sie sich alle unsere agilen Lösungen an in Der Marktplatz von Atlassian!

Agile Softwareentwicklung ist wie eine Roadmap, um Software richtig zu machen. Wie im Agile-Manifest hervorgehoben, werden echte Konversationen wichtiger als Tools, die Bereitstellung funktionierender Software, anstatt in der Dokumentation zu ertrinken, die Zusammenarbeit mit Kunden, anstatt nur Verträge auszuhandeln, und man passt sich schnell an Veränderungen an. Das Manifest betont die Macht der Zusammenarbeit in funktionsübergreifenden Teams und macht es für das Projektmanagement in verschiedenen Kontexten relevant.

Stellen Sie sich Agile als Denkweise vor, nicht nur als Methode. Es ermöglicht Projektteams, Feedback in einer freundlichen, iterativen Umgebung zu geben und zu erhalten, die zu großartigen Ergebnissen führt. Obwohl agile Prinzipien in der Softwareentwicklung immer beliebter wurden, können sie tatsächlich Wunder für jedes Projektteam bewirken. Egal, ob es um das Baumanagement, das Content Marketing oder sogar die Planung von Hochzeiten geht, Agile bietet Ihnen alles.

Lassen Sie uns herausfinden, warum agiles Projektmanagement für jedes Team hervorragend geeignet ist. Wir werden untersuchen, wie sich seine Prinzipien nahtlos in Ihre Projektprozesse einfügen lassen. Denken Sie daran, dass es egal ist, für welches agile Framework — wie Scrum oder Kanban — Sie sich entscheiden, solange es zu Ihrem Team passt. Kurz gesagt:

• Agile Prinzipien eignen sich perfekt für die Zusammenarbeit im Team.
• Agile Arbeitsabläufe für Projektteams tragen zur kontinuierlichen Iteration und Verbesserung bei.
• Das Framework, das Sie wählen, Scrum oder Kanban, ist weniger wichtig als Ihre Teammentalität.
• Der Einsatz von agilem Projektmanagement in Ihrem gesamten Unternehmen erhöht die Sichtbarkeit und Koordination.

Agile Prinzipien im Projektmanagement

Die Kernprinzipien von Agile — Zusammenarbeit, Empowerment und Transparenz — eignen sich ideal für das Projektmanagement. Unabhängig von der Art des Teams sollte das Ziel eine kontinuierliche Verbesserung sein. Teams erreichen dieses Ziel, indem sie bei der Umsetzung ihrer Projekte nach einem iterativen Ansatz zusammenarbeiten.

Agile ist eine Denkweise der Anpassungsfähigkeit, des Teilens von Fortschritten und des Lernens aus dem, was funktioniert hat und was nicht. Sie verbessern sich im Laufe der Zeit.

Thomas Edison bringt den Geist eines iterativen Ansatzes perfekt auf den Punkt: „Ich bin nicht gescheitert. Ich habe gerade 10.000 Möglichkeiten gefunden, die nicht funktionieren.“ 💡 Es ist diese Einstellung, die die agile Denkweise ausmacht.

Entitäten wie die Institut für Projektmanagement setzen Sie sich für die Vorzüge des agilen Projektmanagements und seine Auswirkungen auf die Zusammenarbeit der Teams ein:

• Die Teams sind für die Projektabwicklung verantwortlich und organisieren sich selbst, um ihre Erfolgschancen zu maximieren.
• Agile Projektmanager fördern die Diskussion von Frameworks und Prozessen, fördern aber auch eigenständiges Denken.
• Agile Werte fördern Vertrauen und gesunde Arbeitsbeziehungen.
• Als Entscheidungsrahmen fördert agiles Projektmanagement die Rechenschaftspflicht und fördert gleichzeitig die kontinuierliche Entscheidungsfindung und Umsetzung.

Agile Workflows für Projektteams

Wie kann ein traditionelles Projektteam selbstorganisiert genug werden, um agiler zu werden? Lassen Sie uns einen Schritt durchgehen Scrum-Arbeitsablauf im Rahmen eines allgemeinen Projekts.

Rückstand

Entwicklungsteams arbeiten auf der Grundlage eines Produkt-Backlogs, bei dem es sich um eine Liste priorisierter Funktionen handelt, die von einem Kunden gewünscht werden. Diese Liste muss jedoch nicht aus einer Reihe von Softwarefunktionen bestehen. Es kann sich um eine beliebige Reihe von Aufgaben oder Ergebnissen handeln, die ein Projektteam erledigen muss.

Besprechung zur Sprint-Planung

Agile Teams arbeiten in Sprints, bei denen es sich um festgelegte Zeiträume (z. B. zwei Wochen) handelt, um einen vereinbarten Arbeitsaufwand zu erledigen. Während der Sprint-Planung überprüft und bespricht das Team die wichtigsten Prioritäten aus dem Backlog. Anschließend entscheiden sie, was im Sprint erreicht werden kann, und verpflichten sich zu dieser Arbeit.

Nehmen wir als untypisches Beispiel ein Marketingteam, das an einer Kampagne arbeitet. In einer traditionellen Projektmanagementumgebung kann das Team einen Wasserfallansatz verfolgen. Sie würden einen monatelangen Inhaltskalender mit sozialen Medien, Blogartikeln, Videos und anderen Inhalten erstellen. Im Rahmen von Agile würden sie sich nur auf die nächsten zwei Wochen der Inhaltsproduktion festlegen, bevor sie entscheiden, was als Nächstes kommt.

Stehaufsteher

Ein Stand-up ist ein tägliches Treffen der Teammitglieder. Dabei beantwortet jedes Mitglied drei Fragen:

• Woran hast du gestern gearbeitet?
• Woran wirst du heute arbeiten?
• Gibt es Probleme, die Ihre Arbeit daran hindern, abgeschlossen zu werden?

Die Fragen bieten jeder Person die Möglichkeit, ihre Fortschritte mitzuteilen und Unterstützung zu leisten, falls sie die Arbeit eines Teamkollegen entsperren können, indem sie zur Lösung seines Problems beitragen.

Sprint-Bewertung

Wenn der Sprint abgeschlossen ist, treffen sich die Teams, um die gerade abgeschlossene Arbeit zu überprüfen und vorzuführen. In unserem Marketing-Fall kann es eine Zeit sein, in der das Team zusammenkommt, um sich ihre Inhaltsvideos anzusehen, die Kommentare und das Feedback aus ihren Social-Media-Posts zu lesen und wichtige Kennzahlen aus all ihren Inhalten zu überprüfen.

Sprint-Retrospektiven

Die Produktentwicklungsteams treffen sich nach jedem Sprint, um zu besprechen, wie sie die Dinge für ihren nächsten Sprint verbessern können. In diesem Meeting bespricht das Team:

• Was ist gut gelaufen?
• Was lief nicht so gut?
• Was können wir in Zukunft verbessern?

Angenommen, Ihr Marketingteam hatte einen Beitrag, der unerwartet viral geworden ist. Warum war es so effektiv? Was können wir daraus lernen, um die Inhalte der nächsten zwei Wochen anzupassen? Diese Art von Fragen sollten Sie sich stellen, damit Sie weiter iterieren und als Team gemeinsam lernen können.

Scrum oder Kanban?

Der oben skizzierte Workflow ist ein typisches agiles Scrum-Framework. Es muss jedoch nicht die Art und Weise sein, wie agile Praktiken im Projektmanagement implementiert werden. Verschiedene Arten von Projekten erfordern möglicherweise unterschiedliche Frameworks. Beispielsweise sind in Scrum die Rollen klarer definiert als in Kanban.

Gedränge

Ein Scrum-Team besteht aus bestimmten Rollen, denen unterschiedliche Verantwortlichkeiten übertragen werden, um das Team durch den Entwicklungsprozess zu führen. Laut dem Scrum-Leitfaden:

• Entwickler erstellen einen Plan für jede Sprint-Iteration, definieren die Vollständigkeit der Arbeit, passen ihren Plan täglich an und ziehen sich gegenseitig zur Rechenschaft.
• Ein Product Owner ist für die Verwaltung des Produkt-Backlogs verantwortlich, indem er die Produktziele kommuniziert, Artikel priorisiert und für Transparenz über den gesamten Backlog sorgt.
• Der Scrum Master coacht und leitet das Team bei der Einführung von Scrum.

Kanban

Einige Projekte eignen sich möglicherweise besser für Kanban als für Scrum. Es gibt wichtige Unterschiede zwischen den beiden Frameworks, die den Ansatz eines Teams für agiles Projektmanagement beeinflussen können:

• Kontinuierlicher Workflow im Vergleich zu festen Sprint-Iterationen
• Kontinuierliche Lieferung im Vergleich zur Auslieferung nach Abschluss jedes Sprints
• Keine festen Rollen im Vergleich zu definierten Scrum-Rollen

Kanban-Teams verwenden ein Kanban-Board, um ihre Aufgaben zu visualisieren und den Umfang der zu einem bestimmten Zeitpunkt laufenden Arbeit zu begrenzen.

Das agile Framework, das Sie verwenden, ob es Scrum oder Kanban, ist weniger wichtig als das gemeinsame Verständnis Ihres Teams darüber, wie Sie zusammenarbeiten, um gemeinsame Ziele zu erreichen. Das Schöne an einem agilen Ansatz ist, dass er dazu beiträgt, Ihr Framework und die Art und Weise, wie Sie es bei Wiederholungen und Rückblicken verwenden, zu optimieren.

Agiles Projektmanagement für Ihr gesamtes Unternehmen

Da Softwareentwicklungsteams weiterhin agile Prozesse einsetzen, können sie andere Teams ermutigen, sich ihnen anzuschließen. Der Einsatz agiler Methoden in anderen Abteilungen verbessert die Fähigkeit dieser Teams zur Zusammenarbeit. Es schafft auch ein gemeinsames Gefühl der Einheit in Ihrem gesamten Unternehmen, da Sie alle dieselbe Methode anwenden, um jedes Ihrer Ziele zu erreichen.

Versuchen Sie, täglich für Abteilungsleiter zu stehen, um die organisationsübergreifende Kommunikation zu verbessern. Halten Sie es kurz und bündig und konzentrieren Sie sich auf die Themen, die den Arbeitsfortschritt fördern.

Die Planung ist eine kritische Phase des agilen Prozesses. Sie bietet die Gelegenheit, sich als Team auf Prioritäten zu einigen und die Arbeit in einer Reihenfolge zu organisieren, die für einen reibungslosen Ablauf sorgt. Der Planungsprozess hilft agilen Softwareentwicklungsteams und anderen Produktentwicklungsteams dabei, neue Informationen zu sortieren, sich an Abhängigkeiten anzupassen und auf sich ändernde Kundenbedürfnisse einzugehen.

Agile ist das Gegenteil der traditionellen Wasserfall-Projektplanung, die einen schrittweisen Ansatz verfolgt. Waterfall dominiert seit vielen Jahren die Projektplanung. Zu Beginn eines Projekts wurden detaillierte Pläne erstellt, die strikt eingehalten werden mussten. Dies mag ein Projekt oder Produkt voranbringen, aber neue Entwicklungen, die außerhalb des „Masterplans“ auftreten könnten, werden dabei nicht berücksichtigt.

Agile ist ein iterativer Prozess, der Teams dabei hilft, Verschwendung zu reduzieren und die Effizienz zu maximieren, um letztlich den Kunden einen Mehrwert zu bieten. Dieser kundenorientierte Ansatz hilft Teams, während des gesamten Entwicklungsprozesses fundierte Entscheidungen zu treffen — Entscheidungen, die den Stakeholdern kontinuierlich und konsistent einen Mehrwert bieten.

Einer der größten Vorteile eines iterativen agilen Ansatzes besteht darin, dass er frühzeitiges Feedback von Stakeholdern ermöglicht. Sie müssen nicht raten, ob Sie die richtigen Entscheidungen treffen oder nicht — Sie können jeden Schritt herausfinden, indem Sie die Beteiligten direkt in Ihren Prozess einbeziehen. Sie können Ihren Plan nach Bedarf anpassen, je nachdem, was den Kunden zu jedem Zeitpunkt den größten Mehrwert bietet.

Auch wenn Sie Teil eines erfahrenen agilen Teams sind, gibt es immer Verbesserungsmöglichkeiten und Prozesse, die optimiert werden müssen. In diesem Beitrag werden einige unproduktive Fehler beschrieben, die Teams bei der agilen Planung machen, einschließlich der Frage, wie agile Teams diese häufigen Fallstricke vermeiden können.

Agiler Planungsfehler #1: Nicht auf derselben Wellenlänge wie die Stakeholder zu sein

Binden Sie Interessengruppen in Ihren Planungsprozess ein? Verstehen sie Ihre Ziele und warum Sie jede Entscheidung treffen? Die direkte Zusammenarbeit mit allen Beteiligten, sowohl internen Interessenvertretern als auch Nutzern Ihres Produkts, wird Ihnen helfen, sich ein klares Bild von Bedürfnissen und Einschränkungen zu machen. Außerdem erhalten Sie die Informationen, die Sie benötigen, um zu entscheiden, was wann getan werden sollte.

Es ist niemals eine gute Idee, sich auf Annahmen auszuruhen. Ihre Stakeholder leben in einer anderen Welt als der, in die Sie tief verwurzelt sind, mit anderen eigenen Prioritäten und Annahmen. Damit Sie Ergebnisse erzielen können, die die Erwartungen Ihrer Stakeholder erfüllen, müssen Sie sich auf diese Erwartungen einigen. Binden Sie Ihre Stakeholder in die Planung ein, aber stellen Sie sicher, dass jeder versteht, dass sich die Erwartungen im Laufe des Prozesses ändern können, basierend auf neuen Informationen, die aus Erfolgen, Misserfolgen und Kundenreaktionen gewonnen werden.

Agiler Planungsfehler #2: Abhängigkeiten nicht berücksichtigen

Die Nichtberücksichtigung von Abhängigkeiten in der agilen Planung führt zu Engpässen, verzögerten Releases und untergräbt die Zusammenarbeit im Team. Die Zusammenarbeit innerhalb und zwischen Teams ist erforderlich, damit ein Unternehmen effektiv liefern kann. Wenn mehrere Teams an miteinander verbundenen Funktionen arbeiten und der Fortschritt eines Teams durch ein anderes blockiert wird, verlangsamt sich der gesamte Entwicklungszyklus. Ohne klare Sichtbarkeit der Abhängigkeiten kann sich die Arbeit verzögern und Termine nicht eingehalten werden.

Um Unterbrechungen des Arbeitsablaufs zu minimieren und zu vermeiden, sollten Sie sich die Zeit nehmen, die Beteiligten zu konsultieren und Abhängigkeiten frühzeitig zu antizipieren. Tools, die Ihnen helfen, Abhängigkeiten zu visualisieren und abzubilden, und gemeinsame Roadmaps zur Verfolgung teamübergreifender Abhängigkeiten ermöglichen es Ihnen, sich ein Bild von Abhängigkeiten zu machen und die Arbeit so abzufolgen, dass Hindernisse vermieden werden. Die proaktive Verwaltung von Abhängigkeiten sorgt für reibungslosere Iterationen, eine schnellere Markteinführung und einen besser vorhersehbaren agilen Prozess.

Agiler Planungsfehler #3: Verwendung langweiliger, flacher Produktlandkarten

Flache Produktrückstände sind fad und langweilig 😴. Denken Sie an Karottenkuchen ohne Zuckerguss. Ihnen fehlen die Details und Funktionen, die Sie benötigen, um die gesamte Geschichte Ihres Produkt-Backlogs zu erfassen.

Sobald Sie mehr als eine Handvoll Artikel haben, werden sie außerdem überwältigend und es ist schwierig, sie sinnvoll zu organisieren. Es wird weniger klar, welcher Punkt der wichtigste ist, und es wird schwieriger, sicherzustellen, dass Ihre Entscheidungen mit dem übergeordneten Ziel des Projekts übereinstimmen.

Wenn Sie Ihre Roadmap planen, benötigen Sie einen Kontext, und Sie müssen in der Lage sein, die Kundenreise klar zu erkennen. User-Story-Maps visualisieren Sie die Kundenreise im Planungsprozess und während des gesamten Prozesses der Produktentwicklung. Sie nutzen User Stories — die kleinste Arbeitseinheit, die dem Kunden einen Mehrwert bieten kann —, sodass Sie den Backlog aus Kundensicht planen und organisieren können.

📕 Lesen Sie unsere ultimativer Leitfaden für User Story Maps um mehr zu erfahren.

Agiler Planungsfehler #4: Dem Plan nicht zu erlauben, zu leben, zu atmen und sich anzupassen

Wie wir bereits besprochen haben, ist Agile ein iterativer Ansatz. Das bedeutet, dass Ihre agile Planung Raum für Änderungen lassen muss. Ihr Plan sollte in der Lage sein, mit jedem Sprint oder jeder Produkt-Roadmap zu wachsen und sich anzupassen.

Zu Beginn eines Sprints fehlen Ihnen die Informationen, die Sie benötigen, um das Gesamtbild zu sehen. Sie haben nicht alles, was Sie benötigen, um die perfekte Lösung zu entwickeln, und das ist in Ordnung. Das ist alles Teil des Prozesses. Stunden oder Tage damit zu verbringen, den perfekten Plan auszuarbeiten, verschwendet nur Zeit, die besser damit verbracht werden könnte, zu lernen und Probleme zu lösen, sobald sie auftauchen. Was Sie in der Planungsphase für den größten Nutzen hielten, könnte im Laufe der Zeit völlig anders sein.

Möglicherweise müssen Sie Ihren Plan ändern, nachdem eine Straßensperre in einem täglichen Gespräch auftaucht, oder Sie erfahren von einem Kundenproblem, das Ihre Richtung völlig ändert. Wiederholungen sind unvermeidlich und willkommen! Sie helfen Ihnen, mit eingehenden Informationen Schritt zu halten, während Sie voneinander, von Stakeholdern und Ihren Kunden lernen.

Agile Planung ist kein Versprechen. Es ist eine Gliederung, die Ihnen hilft, Ihr Ziel zu erreichen, und die sich mit Ihren Zielen und Umständen ändert.

Agiler Planungsfehler #5: Rückblickende Erkenntnisse nicht in die folgende Planungssitzung einfließen lassen

Rückblicke sind ein wesentlicher Bestandteil des agilen Prozesses. Sie geben Teams die Möglichkeit, über alles nachzudenken, was in einem einzelnen Sprint oder nach der Fertigstellung eines Produkts passiert ist.

Eine effektive Retrospektive stellt dem gesamten Team wichtige Fragen, die den Prozess beim nächsten Mal verbessern können. Was ist gut gelaufen? Was ist es wert, es noch einmal zu wiederholen? Was lief nicht so gut? Was könnte beim nächsten Mal verbessert werden? Welche Hindernisse oder Abhängigkeiten sind entstanden? Was hast du gelernt? Wie hast du dich am Ende des Sprints gefühlt?

Eine Retrospektive bietet Einblicke, die die Effizienz, die Teamarbeit und die Teamdynamik, die Effektivität der Tools und die Kommunikation mit den Stakeholdern verbessern werden.

Es reicht nicht aus, einfach eine Retrospektive abzuhalten oder rückwirkendes Feedback zu sammeln, um an Wert zu gewinnen. Sie müssen sicherstellen, dass Sie das Feedback in das folgende Sprint-Planungsgespräch einbeziehen und Maßnahmen ergreifen, die zu einer spürbaren Verbesserung führen. Die nächste Iteration wird umso besser für die Zeit sein, die Sie damit verbringen, auf der Grundlage des Gelernten nachzudenken und sich zu verbessern.

Agiler Planungsfehler #6: Auswahl von Tools, die keinen kundenorientierten Ansatz verfolgen

Unabhängig davon, ob Ihr Team einen Scrum-Prozess, Kanban-Boards oder andere agile Methoden verwendet, sollten die von Ihnen ausgewählten Tools immer kundenorientiert sein. Und Sie müssen sie weiterhin so einsetzen, dass der Kunde bei der Entscheidungsfindung immer an erster Stelle steht.

Teams können in die Falle tappen und glauben, dass sie sich auf den Kunden konzentrieren, wenn sie nicht viel tun, außer einfachen agilen Methoden und generischen Prozessen zu folgen. Kunden müssen bereits in der Planungsphase in Ihren Entwicklungsprozess eingebunden werden, sodass bei jeder Entscheidung, die ein Teammitglied trifft, zuerst die Kundenbedürfnisse berücksichtigt werden.

Wählen Sie Planungstools, die Ihrem gesamten Team helfen, genau zu verstehen, was Ihre Kunden bewegt, und schauen Sie immer vorbei, um sicherzustellen, dass Sie Entscheidungen im Einklang mit Ihren Kunden treffen.

Zum Beispiel Personas bieten ein tiefes Verständnis dafür, was Kunden wollen, brauchen, nicht wollen usw. Sie geben wichtige Informationen über Kundenprobleme, Wünsche, demografische Merkmale, Ziele, Einkaufsmuster und vieles mehr preis. Wir empfehlen dringend, Kunden-Personas zu entwickeln, um ein umfassendes Bild von allen Personen zu erhalten, die Ihr Produkt verwenden werden. Es reicht jedoch nicht aus, Personas einfach herumliegen zu lassen.

Sie müssen diese Personas in Ihren agilen Planungsprozess einbeziehen und sie bei der Bearbeitung von Problemen und der Weiterentwicklung Ihres Produkts in den Mittelpunkt stellen.

Wir gehen zu den Rennen! 🏃🏃 ‍ ♀️ Sprints sind ein wichtiger Bestandteil der agilen Methodik. Ein Sprint ist ein vordefinierter Zeitraum, in dem agile Teams gemeinsam auf ein vereinbartes Sprintziel hinarbeiten. Es gibt vier Arten von Agile-Meetings, die im Laufe eines Sprints stattfinden, und jede davon ist entscheidend, um den Erfolg des agilen Prozesses sicherzustellen. Es geht darum, durch eine vorgegebene Menge an Arbeit zu sprinten, um die Ziellinie zu erreichen, wo Sie aus Ihrem Prozess lernen und das Rennen erneut beginnen (nur besser dran aufgrund dessen, was Sie im vorherigen Sprint gelernt haben).

Agile Meetings werden genutzt, um Teammitglieder, Führungskräfte und Stakeholder auf den gleichen Stand zu bringen, und sie leiten den Prozess eines agilen Sprints oder Gedränge.

In diesem Beitrag werden die vier wichtigsten Agile-Meetings behandelt, zu denen Sprint-Planung, tägliche Standups, Sprint-Reviews und Sprint-Retrospektiven gehören. Außerdem besprechen wir ein zusätzliches Agile-Meeting, das zur Verfeinerung des Backlogs genutzt wird.

Agile Besprechungen im Vergleich zu Scrum-Besprechungen

Scrum ist agil Methodik das wird am häufigsten in der Softwareentwicklung verwendet. Scrum-Meetings sind technisch gesehen eine Art agiles Meeting, aber sie haben spezifischere Parameter, die so konzipiert sind, dass sie in das Scrum-Framework passen. Der Prozess dreht sich um einen 2-4 wöchigen Sprint, an dem ein Product Owner, ein Scrum Master und das gesamte Scrum-Team beteiligt sind.

Wir haben es abgedeckt Scrum-Meetings (Zeremonien) ausführlich in einem anderen Artikel. In diesem Beitrag konzentrieren wir uns auf die vier wichtigsten agilen Meetingtypen. Diese Prozesse und Best Practices können überall angewendet werden mehrfach agil Methodologien, einschließlich Scrum und Kanban. Dieses Framework kann auch über die Softwareentwicklung hinaus branchenübergreifend angewendet werden und sich an die Bedürfnisse der meisten Teams anpassen.

Einfach ausgedrückt: Scrum hat einen starreren Rahmen, der auf vier Zeremonien/Treffen folgt. Der agile Prozess ist fast derselbe, mit vier sehr ähnlichen Meetings, aber es gibt mehr Flexibilität, um den Zeitrahmen des Sprints anzupassen und den Prozess anzupassen, wenn nicht speziell die Scrum-Richtlinien befolgt werden. Okay, vielleicht ist das immer noch nicht einfach ausgedrückt, aber es wäre nicht agil, wenn es linear und unkompliziert wäre.

Die 4 Arten von agilen Meetings

Es gibt vier zentrale Agile-Meetings: Sprint-Planung, tägliche Standups, Sprint-Reviews und Sprint-Retrospektiv-Meetings. Ein Sprint beginnt mit einem Sprint-Planungsmeeting. Jeden Tag findet ein tägliches Standup-Meeting statt. Schließlich finden am Ende des Sprints ein Sprint-Review und eine Retrospektive statt. Der Vorgang wiederholt sich mit neuen Federn, bis das Produkt, das Projekt oder die Arbeit abgeschlossen ist.

1. Besprechung zur Sprint-Planung

Das Sprint-Planungsmeeting findet zu Beginn eines Sprints statt und bezieht das gesamte Team mit ein. Bei der Sprint-Planung trifft sich das gesamte Team, um zu besprechen und zu vereinbaren, welche Arbeitsaufgaben (Backlog-Elemente) in das Sprint-Backlog verschoben werden sollen — die Elemente, die bis zum Ende des Sprints erledigt sein müssen. Während des Meetings werden die Sprintziele festgelegt und das Team orientiert sich an den Erwartungen.

Ohne ein Sprint-Planungstreffen zur Erläuterung der Sprint-Backlog (Aufgaben, die erledigt werden müssen), das Team wird während des Sprints Zeit damit verschwenden, herauszufinden, welche Arbeit Vorrang hat.

Zu vermeidende Fehler bei der Sprint-Planung:

• Beginnen Sie mit der Planung ohne verfeinerter Backlog
• Nicht auf derselben Wellenlänge wie Ihre Stakeholder
• Den Kunden und die Kundenreise bei der Planung ignorieren
• Erstellung eines starren Plans, der keinen Raum für Wachstum oder Anpassung bietet
• Mit fad flache Produktkarten denen ein kritischer Kontext fehlt
• Versäumnis, rückblickende Erkenntnisse in die folgende Planungssitzung einzubeziehen

Erfahre mehr über häufige Fehler bei der agilen Planung und wie Ihr Entwicklungsteam diese Fallstricke vermeiden kann.

2. Tägliches Standup-Meeting

Das tägliche Standup-Meeting findet an jedem Tag des Sprints statt. Im Scrum-Prozess könnte dieses Meeting auch als tägliches Scrum-Meeting bezeichnet werden. Es ist eine Gelegenheit für das Team, sich über die Arbeit auszutauschen, die am Vortag erledigt wurde, und darüber, was jede Person oder jedes Team in den nächsten 24 Stunden erledigen will.

Das Treffen zielt darauf ab, drei wichtige Fragen zu beantworten:

• Welche Arbeiten wurden seit dem letzten Standup abgeschlossen, um dem Team zu helfen, das Sprintziel zu erreichen?
• Welche Arbeiten planen Sie heute abzuschließen?
• Steht dir derzeit etwas im Weg oder behindert es deinen Fortschritt?

Dies ist ein guter Zeitpunkt, um etwaige Engpässe zu beheben. Was hat die Verzögerung verursacht, wenn die vom Vortag geplanten Arbeiten nicht abgeschlossen wurden, und wie kann das Team zusammenarbeiten, um Probleme zu lösen, die verhindern, dass die Arbeit voranschreitet?

Ein Standup-Meeting ist kurz und auf den Punkt gebracht, sodass jeder wieder zu der Arbeit zurückkehren kann, die er zu Ende bringen möchte. So kurz, dass oft Teilnehmern empfohlen wird stehen für die Dauer des Treffens. Daher der Name Daily Standup. Es umfasst alle Teammitglieder und findet idealerweise jeden Tag zur gleichen Zeit statt, um sicherzustellen, dass jeder immer teilnehmen kann.

Tägliche Standup-Fehler, die es zu vermeiden gilt:

• Die Zeit während des Meetings nicht im Auge behalten
• Kontinuierliches Überschreiten der zugewiesenen Besprechungszeit
• Umherschweifende Teilnehmer, die nicht bereit sind, die wichtigsten Fragen des Treffens zu beantworten
• Das Meeting aus Zeitgründen überspringen
• Teammitglieder kommen zu spät zum Meeting oder verpassen es ganz
• Den lautesten Stimmen erlauben, den Rest des Teams zu überschatten
• Jemanden dieselbe Aufgabe an mehreren aufeinanderfolgenden Tagen angeben lassen
• Unfähigkeit, potenzielle Engpässe zu beheben
• Zuweisung von Arbeiten, die über die Kapazität einer Person hinausgehen

3. Sitzung zur Sprint-Überprüfung

Das Sprint-Review ist eine Gelegenheit für das Team, die Arbeit, die es während des Sprints geleistet hat, zu präsentieren. Bei diesem Meeting kann es sich um eine interne Präsentation oder eine formellere Demonstration für die Beteiligten handeln, je nachdem, welche Anforderungen das Projekt hat und wie weit die Arbeit bereits fortgeschritten ist.

Zu vermeidende Sprint-Review-Fehler:

• Nicht richtig auf das Meeting oder die Demonstration vorbereitet
• Stakeholder nicht in Ihren Prozess einbeziehen
• Versäumnis nachzuweisen, wie die Arbeit dem Kunden einen Mehrwert bringt
• Erfolge übertreiben oder verschönern
• Versäumnis, Probleme zu lösen und wie sie gelöst wurden
• Das Feedback zum Sprint-Review wird nicht in das nächste Sprint-Planungstreffen einbezogen

4. Sitzung zum Rückblick auf den Sprint

Die Retrospektive ist ein entscheidender Teil des agilen Prozesses. Das Meeting findet am Ende des Sprints statt und bringt das gesamte Team zusammen, um seine Prozesse zu bewerten und zu besprechen, wie es sich beim nächsten Mal verbessern kann.

Welche Aspekte des Sprints verliefen gut und was können Sie aus diesem Erfolg lernen? Was lief nicht so gut und auf welche Engpässe ist das Team gestoßen? Was könnte beim nächsten Mal besser gemacht werden? Da es bei Agile vor allem um Lernen und Iterieren geht, gibt es nach jedem Sprint etwas zu lernen. Alles, von gut über schlecht bis mittelmäßig, kann in umsetzbare Verbesserungen umgewandelt werden.

Zu vermeidende Fehler im Nachhinein:

• Einzelne Teammitglieder für Engpässe verantwortlich machen
• Nur die lautesten Stimmen geben Einblick
• Es gelingt nicht, die leisen Stimmen im Raum zu stärken
• Immer wieder dieselben Fragen wiederholen, ohne die Dinge zu ändern
• Zulassen, dass die Retrospektive zu lang ist (zwei Stunden für einen zweiwöchigen Sprint anstreben)
• Überspringen einer Retrospektive aus Zeit- oder Ressourcenmangel
• Erkenntnisse oder Bedürfnisse von Stakeholdern vergessen oder nicht mit einbeziehen
• Versäumnis, das zu verbessern Sprint-Rückblick Prozess (Rückblick — der Rückblick!)
• Fehlende Berücksichtigung rückwirkender Erkenntnisse in den nächsten Sprint

Bonus: Besprechung zur Verfeinerung des Backlogs

Man könnte argumentieren, dass es ein fünftes Agile-Meeting gibt, insbesondere in der Welt der Produktentwicklung. Vor dem Sprint-Planungsmeeting muss der Product Owner ein Produkt-Backlog erstellen, das alle Aufgaben und Elemente umfasst, die das Team erledigen muss, um das Endprodukt oder Projekt vollständig zu entwickeln. Zu den Elementen gehören Benutzerberichte, Bugfixes, Funktionen und andere Aufgaben, die angegangen werden müssen, um das Endziel zu erreichen.

Verfeinerung des Backlogs bereitet das Backlog für die Sprint-Planung vor, indem Artikel so angeordnet werden, dass sie im nächsten Sprint die größte Wirkung erzielen. Bei der Backlog-Verfeinerung stellt ein Product Owner sicher, dass die Backlog-Elemente genügend Informationen, Details und Prioritäten enthalten, sodass das Team kluge Entscheidungen darüber treffen kann, was wann angegangen werden soll.

Je nach dem aktuellen Stand des Produkt-Backlogs kann vor Beginn der Sprint-Planung ein Meeting zur Feinabstimmung des Backlogs stattfinden. Außerhalb der Produktentwicklungsbranche könnte der Produkt-Backlog einer Aufgabenliste für ein Hauptprojekt ähneln.

Bei der Verfeinerung des Backlogs sollten folgende Fehler vermieden werden:

• Die Backlog-Verfeinerung wurde nicht rechtzeitig für die Sprint-Planung abgeschlossen
• Für das Planungstreffen bleibt zu viel Verfeinerung des Rückstands übrig
• Fehlende Priorisierung von Artikeln, die dem Kunden einen Mehrwert bieten
• Keine Berücksichtigung neuer Rückmeldungen, Fragen und Bedenken von Stakeholdern

Agile Meetings: Abschließende Überprüfung

Da hast du es also! Die vier wichtigsten Agile-Meetings sind Sprint-Planung, tägliche Standups, Sprint-Reviews und Sprint-Retrospektiven. Eine lobende Erwähnung geht an die Verfeinerung des Backlogs.

Lassen Sie uns den Zweck der einzelnen Besprechungen überprüfen:

• Sprint-Planung bringt alle auf den gleichen Stand darüber, was im Laufe des kommenden Sprints erreicht werden muss.
• Tägliche Standups stellen Sie sicher, dass das Team auf Kurs bleibt und hilft ihnen, potenzielle Engpässe zu beheben und zu lösen.
• Sprint-Bewertungen sind eine Gelegenheit für das Team, den Stakeholdern die während des Sprints geleistete Arbeit zu präsentieren und kritisches Feedback zu erhalten.
• Sprint-Retrospektiven Ermöglichen Sie dem Team, zusammenzukommen, um zu besprechen, was gut und was nicht gut gelaufen ist und wie es sich beim nächsten Mal verbessern kann.
• Verfeinerung des Backlogs bereitet das Backlog für die Sprint-Planung vor, um im nächsten Sprint die größtmögliche Wirkung zu erzielen.

Halten Sie effektive agile Meetings mit Easy Agile ab

Easy Agile setzt sich dafür ein, Teams dabei zu helfen, mit Agile besser zu arbeiten. Easy Agile entwickelt Produkte, die speziell für Jira-Benutzer entwickelt wurden, um agilen Teams zu helfen, effizienter und effektiver zu arbeiten.

Wir veröffentlichen regelmäßig Listen mit Tools, Ratschlägen und Anleitungen für agile Teams. Wenn Sie mit Jira arbeiten, werden Sie feststellen, dass unsere Ressourcen besonders hilfreich sind, um sich in der Produktentwicklung zurechtzufinden und Jira-Apps das wird die Art und Weise verbessern, wie Ihr Team zusammenarbeitet.

“Agile” is a simple word that means quite a lot today. What was once resigned to software developers and product development is now commonplace in many businesses, and agile implementation is showing no sign of slowing down.

It all boils down to this: Businesses today must be able to adapt fast.

The rigid approaches that worked for years don’t fit our rapidly changing business landscapes. Businesses of all shapes and sizes need to continually adapt to changing requirements, the changing needs of a global economy, cultural shifts, and evolving technological advancements.

It’s clear that agile is the way of the future, but how do you implement such a massive change across an organization, especially enterprises? Do you need a top-down approach, a bottom-up approach, or something in between? Let’s take a closer look at the benefits of agile and how to choose the best agile implementation approach.

Are you practicing SAFe®?

Bring the SAFe® Program Board into Jira

Try Easy Agile Programs

Why switch to an agile approach?

We’ve covered the benefits of agile in detail in our Beginner's Guide to Agile Methodology, but let’s recap some of the key points and why so many businesses are choosing to make the switch.

Agile practices focus on an iterative approach that continually adapts to new information and circumstances. By contrast, traditional project management generally adopts a waterfall approach — the project manager lays out a plan at the beginning of a project that the project team is expected to follow to the letter.

The problem with the traditional project management process is that it leaves little room to quickly grow and evolve. Agile project management and agile software development, on the other hand, need feedback and iterations at every turn. Agile teams test early and often to ensure they are on the right path, and they make adjustments in real-time.

The benefits of agile methods are far-reaching — that’s why we love it! Though it may take time to implement, agile is a worthy investment for any future-focused organization.

Additional benefits of agile:

• Managers can more easily account for the capacity of individuals and entire teams.
• The team can better manage work in progress (WIP).
• Everyone can clearly visualize the prioritization of tasks.
• Bottlenecks or roadblocks are addressed before they halt progress.
• Wasteful processes are eliminated or changed to improve efficiency.
• Multiple voices are included in the decision-making process.
• Teams can make iterations on products or projects in real-time.
• Stakeholders, customers, and end users are involved in your processes.
• Teams can provide continuous delivery to customers and stakeholders.
• Collaboration and teamwork improve.

With Easy Agile Programs you can equip your distributed or co-located teams to implement the Scaled Agile Framework® (SAFe®) without leaving Jira.

Join a demo

Agile implementation: Top-down or bottom-up?

So, you believe in agile and you’re ready to make it happen, but what’s the best approach? Do you implement it from the top-down or bottom-up? Let’s find out!

A top-down approach to agile implementation starts with those in charge. It often begins with management or business owners who hear about the benefits of agile and want their business to adopt agile practices. The problem is, when an idea only comes from the top, it can catch the rest of the organization off guard. If those in charge don’t give enough notice or provide all of the necessary resources and time to implement new ways of working, employees can become resentful and push back against the change.

On the other hand, when agile implementation comes from the bottom-up, leadership can push back. Teams and team leaders may want to improve their processes and adopt new ways of working, but they may not get adequate support or resources when they need them. It can take time to convince those in charge of the benefits of agile, which can take away from the time needed to actually learn and implement agile practices.

A hybrid approach

The good news is you don’t need to pick just one. The best approach for your business may turn out to be a hybrid approach. The more people you have on board, the better.

Agile implementation is easiest and most effective when as many people as possible buy into the process. It’s best if you have buy-in throughout multiple levels of your organization, from employees to managers to owners to CEOs.

Push-back on change is quite common in organizations, no matter the industry. It’s important to have people throughout the company who believe in the value of agile, are passionate about agile processes, and are excited about the possibilities agile presents.

Choosing an agile framework

As you implement agile principles, you’ll need to choose the framework that works best for your team. Depending on the needs of your team and organization, you may choose to adopt one framework or establish a mixture of frameworks.

Below, we’ll outline a few popular agile methodologies.

Scrum

Scrum is a strange word that’s very popular as a software development process. It’s a series of events that revolve around repeating sprints. One sprint (or Scrum) begins with sprint planning. The product owner reviews the product backlog, which represents all of the work that needs to be completed. They choose which items/tasks are the most important for the upcoming sprint and move those tasks into the sprint backlog.

Next, the development team, guided by the Scrum Master, works over a two-week span to complete the sprint backlog. Each day, the team meets for daily standups, which allow the team to go over what was accomplished over the previous 24 hours and discuss any possible roadblocks that stand in the way of the team completing work.

Lastly, the team completes a sprint review to gather feedback from stakeholders. They also conduct a sprint retrospective to discuss what went well and what didn’t over the course of the sprint. The insights are carried over into the next sprint to help all team members keep improving.

Wow! 🤯 That was a whirlwind explanation of Scrum. If you want to understand the process in more detail, we cover Scrum in a number of other guides, including the difference between Kanban and Scrum and guides to Scrum sprint planning and Scrum retrospectives.

Kanban

The Kanban framework is a visual process that helps teams manage the amount of work in progress. It allows teams and team leaders to see an at-a-glance view of what’s currently in progress and what’s on the horizon.

A Kanban board has three sections: to-do, doing, and done. Tasks flow throughout these sections one at a time to ensure no one is taking on more than one task at once. This ensures focus is always put on work in progress, no one gets bogged down with too many tasks, and potential bottlenecks are discovered before they impede productivity.

Chances are you’ve seen a Kanban board in action in some form or another. Trello is an example of an interactive Kanban board. The Kanban framework can be used on its own or paired with other frameworks, such as Scrum.

Lean

The lean methodology focuses on eliminating waste to improve efficiency. Lean follows five main principles: identify value, map the value stream, create flow, establish a pull system, and seek perfection.

Lean aims to waste less time by ensuring processes, communication, and the transfer of products or services run smoothly. When waste is eliminated and time is optimized, businesses can reduce costs. Efficiency is paired with a continuous improvement mindset, which helps teams work better together and deliver ever-improving products and services.

➡️ Learn more: Understanding Lean Agile and the 5 Lean Principles.

These are only a few popular agile methodologies. To learn more, read our article on 8 Software Development Methodologies Explained.

Seamless agile implementation

Agile implementation works best when people at all levels of the organization buy into the agile transformation. A top-down approach means the leadership is on board, but it forces employees to adopt a new way of working, and they may not be comfortable with the change. When it’s the other way around, employees, team members, and team leaders will struggle to implement agile without the support from those in charge and the people who allocate resources. A hybrid approach is often ideal, where as many people as possible are excited about and invested in the transition.

With the right tools, agile implementation becomes even easier. Easy Agile is dedicated to helping teams work better with agile. We design products that highlight the customer journey and allow teams to collaborate with each other seamlessly.

Easy Agile Programs is simple to use, collaborative, flexible, and it integrates directly with Jira. You can contact our team at any time to learn more about our suite of Jira products!

Join a demo

Try Free for 30 days

Die Priorisierung von Backlogs ist eine nie endende Aufgabe für Product Owner und Produktmanager. Wenn sich die Prioritäten als Reaktion auf sich ändernde Geschäftsanforderungen weiterentwickeln oder sogar die Arbeit abgeschlossen ist oder Anpassungen an der Teamausstattung vorgenommen werden, ist es wichtig, dass Sie sich weiterhin auf die Arbeit konzentrieren, die den größten Nutzen bringt, indem Sie Ihren Backlog in einem guten Zustand halten. Agile Schätzungstechniken können die Priorisierung Ihres Backlogs schneller und einfacher machen.

Schauen wir uns also einige spezifische Methoden an, um priorisiere deinen Backlog und erfahren Sie, wie agile Schätzungen dazu beitragen können, Ihren Endbenutzern und Stakeholdern den größtmöglichen Nutzen zu bieten.

5 Möglichkeiten, einen Backlog zu priorisieren

Natürlich gibt es mehr als fünf Möglichkeiten, Arbeitselemente in einem Backlog zu priorisieren. Wir haben jedoch einige unserer Favoriten ausgewählt, die in Kombination mit einem agilen Schätzprozess dazu beitragen, dass unser Produkt-Backlog stets priorisiert bleibt, sodass wir die Sprint-Planung im Handumdrehen durchführen können.

1. Gewichteter kürzester Job zuerst

Wow, ist das ein Schluck voll! Verwenden wir das Akronym „WSJF“, um uns darauf zu beziehen SAFE-Technik. WSJF ist nicht so einschüchternd, wie es klingt. Es handelt sich um eine einfache Formel, die Artikeln aus dem Produktrückstand einen Geschäftswert zuweist.

WSJF = Kosten der Verzögerung ÷ Auftragsdauer

Kosten der Verzögerung ist die Summe von drei relativen Metriken:

• Nutzer-/Geschäftswert: Die relative Wichtigkeit des Arbeitselements.
• Zeitkritikalität: der Rückgang des Nutzer-/Geschäftswerts im Laufe der Zeit.
• Reduzierung des Risikos: die Reduzierung des geschäftlichen oder technischen Risikos.

Um die relative Größe der Verzögerungskosten zu ermitteln, stellen Sie sich den niedrigsten Geschäftswert, den geringsten Wertverlust im Laufe der Zeit und die geringste Risikominderung als Wert 1 vor. Das Gleiche wie bei Schätzung des Storypoints der Fibonacci-Sequenz, passen Sie diese Punktzahl entsprechend an, wenn Sie Arbeitselemente vergleichen, um sie relativ zueinander zu bewerten.

Die Jobdauer wird ebenfalls relativ ausgedrückt. Wenn Sie Ihre Arbeitselemente mithilfe einer relativen Schätzung anhand von Story Points schätzen, entspricht der Story-Point-Wert der Auftragsdauer.

Wenn du diese Technik verwendest, um eine große Menge an Arbeit in einem Backlog zu priorisieren, in dem einige Artikel nur T-Shirt-Größe hatten, konvertiere deine T-Shirt-Größen in Standard-Fibonacci-Zahlen und verwende diesen Wert.

Warnung: Seien Sie vorsichtig bei der Umrechnung von T-Shirt-Größen in Story Points. Sie benötigen eine Möglichkeit, die Arbeitselemente in T-Shirt-Größe zu kennzeichnen, die Sie in Story Points umgewandelt haben. Sie und Ihr Scrum Master müssen diese Schätzungen als Schätzungen der T-Shirt-Levels erkennen und nicht als tatsächliche Schätzungen der Storypoints, die mit vollständig verfeinerten Arbeitsaufgaben einhergehen.

Sehen Sie in Easy Agile TeamRhythm mehr auf einen Blick, um die Priorisierung Ihres Backlogs zu beschleunigen

💡 Tipp: Füge bis zu drei zusätzliche Felder auf Ausgabekarten hinzu

SEHEN SIE WIE

2. Moskau

Ein Muss, ein Muss, ein Könnten-Hättest und ein Nicht-Haben sind die Kriterien, die verwendet werden, um einen Backlog mit der MoSCoW-Technik zu priorisieren. Das Produktteam definiert diese Bezeichnungen auf der Grundlage der einzigartigen Eigenschaften des Produkts und der Konkurrenzangebote.

Jedes Arbeitselement fällt in eine dieser Kategorien. Der einfachste Teil dieses Vorgangs besteht darin, Won't-have-Elemente direkt in den Papierkorb zu schicken und sie dir aus dem Weg zu räumen. Als Nächstes priorisieren Sie zuerst die Must-Haves und dann die Soll-Haves. Die Elemente, die man haben könnte, fallen natürlich an das Ende des Backlogs.

Nehmen Sie diese Artikel in Ihre regelmäßigen Verfeinerungsgespräche mit Ihren Teammitgliedern auf und weisen Sie jedem Artikel eine T-Shirt-Größe oder einen Storypoint-Wert zu. Dann bist du bereit, deinen Sprints oder Releases die richtige Menge an Arbeitselementen hinzuzufügen, basierend auf der Geschwindigkeit deiner Teams oder der Anzahl der Storypoints, die sie während eines Sprints voraussichtlich abschließen werden.

3. Kano

Das Kano-Modell der Priorisierung verwendet fünf Klassifizierungen:

• Muss sein: die grundlegende Funktionalität, die Ihre Benutzer erwarten.
• Attraktiv: eine angenehme Überraschung für Ihre Benutzer, aber niemand wird verärgert sein, wenn es nicht da ist.
• Eindimensional: Arbeitselemente, die Ihre Nutzer glücklich machen und sie enttäuschen werden, wenn sie nicht Teil Ihres Produkts sind.
• Gleichgültig: Arbeitselemente, die für Ihre Kunden unwichtig sind. Oft handelt es sich bei diesen Arbeitsaufgaben um technische Probleme oder Verbesserungen, die dem Softwareentwicklungsteam helfen, effizienter zu entwickeln oder mit den neuesten Versionen seines Tech-Stacks zu arbeiten — aber Ihren Kunden sind sie wirklich egal.
• Umgekehrt: Der Vorgang, bei dem eine frühere Funktion oder ein vorheriges Update rückgängig gemacht wird. Wenn Sie jemals eine Funktion entwickelt oder eine Benutzeroberflächenaktualisierung vorgenommen haben, die Ihre Benutzer gehasst haben, dann kennen Sie sich mit Reverse-Work-Aufgaben aus. Hoppla. Leider sind dies manchmal notwendige Übel, insbesondere wenn es um Sicherheitsfunktionen oder die Umstellung von Benutzern auf ein neues Produkt geht, nachdem sie ein veraltetes Produkt außer Dienst gestellt haben.

Wie bei der MoSCoW-Methode schätzen Sie diese Arbeitselemente während der Verfeinerung und fügen sie dann Ihrem Iterations- oder Release-Plan hinzu. Aber anders als bei MoSCow möchten Sie vielleicht Ihre Sprints und Releases mit Arbeitselementen aus jeder Klassifizierung ausgleichen.

4. Rangliste stapeln

Die brutalste aller Priorisierungstechniken, das Stack-Ranking, zwingt Teams dazu, eine lineare Rangfolge der Arbeitsaufgaben zu haben, was bedeutet, dass es nur eine oberste Priorität, eine zweite Priorität, eine dritte Priorität usw. gibt. Brutal!

Sobald du dich daran gewöhnt hast, ist Stack-Ranking eine nützliche Methode, um zu erzwingen Produktmanager um schwierige Entscheidungen zwischen Arbeitselementen zu treffen. Selbst wenn zwei Arbeitselemente während desselben Sprints abgeschlossen werden können, ist es Sache des PO, zu bestimmen, welches zuerst erledigt wird, und dann spiegelt sich diese Wahl im Sprint-Backlog wider.

Oft wird dieser Job einfacher, wenn er schlecht formuliert wird. Wenn Sie zum Beispiel nur einen Tag Zeit hätten, um neue Nutzer für Ihr Produkt zu gewinnen, welche Arbeit würden Sie in der Produktion erwarten? BUMM! Da ist deine oberste Priorität.

Das Schöne am Stack-Ranking ist, dass es PoS ermöglicht, kleinere Arbeitselemente in aktuelle Sprints zu verschieben, wenn andere Arbeiten mit höherer Priorität zu umfangreich sind. Wenn das größere Arbeitselement hinzugefügt wird, wird das Team aufgrund seiner Geschwindigkeit zu viel beansprucht. Diese kleinen Arbeitselemente dienen dazu, die Sprints zu füllen, damit die Teams ihr Tempo beibehalten und so produktiv wie möglich arbeiten können. Nur weil ein Arbeitselement, das zwei Stockwerke hoch ist, zu zwei Dritteln im Backlog liegt, heißt das nicht, dass es niemals erledigt werden kann.

5. Zuordnung von Geschichten

Mithilfe von Story Mapping können Sie die Reise des Kunden durch Ihr Produkt von Anfang bis Ende visualisieren. (Ja, das haben wir direkt von unserem anderen gestohlen ausgezeichneter Artikel zum Thema Story-Mapping.) Fortgeschrittene Story-Mapper sollten das, was Sie über Story-Mapping gelernt haben, nutzen und darüber nachdenken, wie Sie MoSCOW- oder Kano-Techniken zu Ihren Story-Maps hinzufügen können.

Vielleicht könnte dein episches Rückgrat oben auf der User-Story-Map die Buckets in der MoSCoW-Methode repräsentieren?

Wenn Sie wie wir sind, sind Ihre Story-Mapping-Sitzungen produktive Brainstorming-Aktivitäten, und Sie werden die Sitzungen mit viel mehr Arbeit verlassen, als Sie erledigen können. Indem Sie die MoSCoW- oder Kano-Prinzipien auf die Geschichten in Ihren Benutzererlebnissen anwenden, werden Sie die wichtigsten Geschichten entdecken, die Sie priorisieren müssen, und die Geschichten, die auf eine spätere Veröffentlichung warten können.

Agile Schätzung in die Backlog-Priorisierung einbauen

Wir haben Ihnen fünf verschiedene Techniken an die Hand gegeben, mit denen Sie Ihre Arbeitselemente in einem organisierten, priorisierten und wertschöpfenden Produkt-Backlog zusammenfassen können:

1. Gewichteter kürzester Job zuerst
2. MOSKau
3. KANO
4. Rangfolge stapeln
5. Storymaps

Wir haben Ihnen auch Möglichkeiten aufgezeigt, wie Sie agile Schätzungen wie T-Shirt-Größen und Storypoints in Ihren Priorisierungsprozess einbeziehen können, damit Ihr Team die wichtigsten Aufgaben erledigt und gleichzeitig die Geschwindigkeit beibehalten und Ihre Kunden und Stakeholder beeindrucken kann.

Wir empfehlen Ihnen, diese Ideen aufzugreifen, sie mit Ihrem Team zu teilen und sie auszuprobieren. Wenn Sie Hilfe bei der Verwendung des Story-Map-Konzepts benötigen, versuchen Sie es Einfacher agiler Teamrhythmus. Wie auch immer Ihr Team seinen Produkt-Backlog priorisiert, denken Sie daran, die wichtigsten Arbeiten an die erste Stelle zu setzen und diese Prioritäten dann nach Bedarf anzupassen. Machen Sie es einfach und bleiben Sie agil!

Du bist Teil eines agilen Teams. Du kennst die Übung. Sie haben eine agile Denkweise, Sie und Ihre Teammitglieder nehmen an den agilen Zeremonien teil und Sie verwenden agile Tools wie Jira. Alles gut! Es besteht aber auch eine gute Chance, dass Sie Teil einer größeren Organisation sind, die entweder agile Praktiken nicht vollständig versteht oder selbst eine agile Transformation benötigt. An dieser Stelle kann ein agiler Coach einspringen.

Seien wir ehrlich — wenn Ihr Unternehmen in seinem agilen Framework perfekt aufeinander abgestimmt wäre, würden Sie diesen Beitrag nicht lesen. 😉 In vielen großen Unternehmen ist die Einführung agiler Praktiken auf eine Untergruppe von Teams beschränkt, insbesondere auf die Softwareentwicklungs- und Projektmanagementteams.

Aber du willst mehr — du willst ein Meister in Sachen Agilität sein. Ein altes Sprichwort lautet etwa: „Der beste Weg, etwas zu lernen, ist, es zu vermitteln.“ Oder, wie Yoda es ausdrückte: „Es gibt immer zwei, nicht mehr und nicht weniger. Ein Meister und ein Lehrling.“

In diesem Beitrag erklären wir, was den Kern eines effektiven Agile-Coaches ausmacht, welche Unterschiede zwischen einem agilen Coach auf Teamebene und auf Organisationsebene bestehen, und geben einen Beispielpfad, um ein zertifizierter Agile-Coach zu werden. Wir stellen dir auch einige unserer besten Bildungsressourcen zur Verfügung, um dich auf dem Laufenden zu halten, egal in welcher Phase deiner agilen Reise du dich gerade befindest.

Was ist ein Agile Coach?

Lassen Sie uns eine Sache aus dem Weg räumen. Ein agiler Coach ist kein Instruktor mit katzenähnlichen Reflexen.

Unser Agile Coach bietet professionelles Coaching und Fachwissen, indem er Organisationen hilft, die agile Methodik und ihre Vorteile gut genug zu verstehen, um sie in großem Maßstab in funktionsübergreifenden Teams umzusetzen. Dies wird in zwei Buckets bereitgestellt:

• Zusammenarbeit mit einer Untergruppe einer Organisation (Teams, Manager und Stakeholder) an agilen Best Practices zur Verbesserung von Leistung und Ergebnissen
• Förderung organisatorischer Veränderungen durch die Zusammenarbeit mit der Führung, um Hindernisse zu beseitigen, die eine vollständige agile Transformation ermöglichen

Eine agile Coaching-Rolle ist kein Patentrezept. Es kann sich um eine feste oder vorübergehende Stelle in einem Unternehmen handeln. Agile Coaches haben eine Vielzahl von Hintergründen, darunter Softwareentwickler, Product Owner, Scrum Master und Projektmanager.

Ein agiler Coach ist ein Facilitator. Da es sich um eine Mentorenrolle handelt, sollte ein agiler Coach über Kompetenzen in den Bereichen Zusammenarbeit und Kommunikation verfügen.

Du willst also ein agiler Coach werden

Du bist alle dabei. Sie möchten Ihr agiles Fachwissen erweitern, indem Sie dessen Prinzipien vermitteln oder agile Methoden außerhalb Ihres Teams vermitteln. Nun, wo fängst du an? Hier ist der Plan.

Lassen Sie uns das mit einem dreigleisigen Ansatz angehen:

1. Erlernen der agilen Frameworks
2. Engagieren Sie sich in einer agilen Community
3. Formelles agiles Training

Erlernen der agilen Frameworks

In der Regel benötigen Sie einige Erfahrung in der Arbeit mit agilen Frameworks, bevor Sie mit formellen Agile-Coaching-Zertifizierungen beginnen. Allerdings kann es schwierig sein, das zu beherrschen Vielzahl von Frameworks innerhalb der agilen Entwicklung, auch im Laufe einer langen Karriere. Zu weiß:

• Gedränge
• Kanban
• ScrumBan
• DevOps
• Digital Agile (DA)
• eXtreme Programming (XP)
• Praxis
• Skaliertes Agile-Framework (Sicher)
• Scrum im großen Maßstab (LeSS)

Aber warte... es gibt noch mehr! Uns geht die Tinte aus, wenn wir sie alle auflisten, also lass uns weitermachen. ✍️

Viele von uns verbringen den Großteil ihrer Zeit damit, mit einem oder zwei Frameworks oder einer Mischung davon zu arbeiten. Sie können beispielsweise lange in einer Scrum-Umgebung arbeiten, bevor Sie alle folgenden Aspekte beherrschen:

• Scrum-Rollen
• Scrum-Artefakte
• Scrum-Zeremonien

Und das ist ok! Wir schlagen vor, das, was Sie in Ihrer eigenen Arbeitsumgebung wie Scrum können, zu beherrschen und dann so viel wie möglich über ein oder zwei andere Dinge zu lernen, die Sie interessieren könnten und die Sie möglicherweise nicht direkt üben können. Lernen Sie zum Beispiel SAFe oder Weniger und wie sie agile Praktiken in großem Maßstab ermöglichen, wäre ein guter Anfang.

Ein wichtiger Tipp, den Sie beachten sollten: Es ist leicht, die Kernprinzipien von Agile aus den Augen zu verlieren, wenn Sie sich zu sehr damit beschäftigen, Frameworks täglich zu üben. Schließen Sie ab und zu Ihre Augen und gehen Sie zurück und lesen Sie das agiles Manifest (ok, du musst eigentlich deine Augen öffnen, aber du weißt, was wir vorschlagen):

• Individuen und Interaktionen statt Prozesse und Tools
• Funktionierende Software statt umfassender Dokumentation
• Zusammenarbeit mit dem Kunden statt Vertragsverhandlungen
• Auf Änderungen gemäß einem Plan reagieren

Du kannst jetzt deine Augen öffnen.

Wenn Sie bereits in einem Framework wie Scrum mit einem Entwicklungsteam als Scrum Master oder Product Owner arbeiten, haben Sie wahrscheinlich viele der Voraussetzungen, um mit Agile-Coach-Schulungen zu beginnen.

Engagieren Sie sich in einer agilen Community

Bevor Sie sich für eine Agile-Coaching-Zertifizierung bewerben, ist es eine gute Idee, Teil einer agilen Community zu sein. Dadurch werden drei Dinge erreicht:

1. Es hält Sie über aktuelle Ereignisse in der agilen Welt auf dem Laufenden.
2. Es macht Sie mit agilen Methoden und Ideen vertraut, die Kollegen außerhalb ihrer eigenen Organisation anwenden.
3. Es zeigt, dass du dich dafür einsetzt, Agile als Karriereziel zu praktizieren — was, wie wir bald sehen werden, wichtig für den Bewerbungsprozess für einen zertifizierten Agile-Coach ist.

Du kannst agile Communities finden örtlich oder entfernt.

Formelles agiles Training

Wenn du als Agile-Coach eingestellt werden möchtest, ist es eine gute Idee, einige agile Zertifizierungen anzustreben. Die bekanntesten Schulungen werden angeboten von Scrum-Allianz. Je nach Ihrem Interesse können Sie zwei Wege einschlagen, um ein zertifizierter Agile Coach zu werden — Zertifizierter Teamcoach (CTC) oder Zertifizierter Unternehmenscoach (CEC). Es gibt Unterschiede zwischen diesen beiden Tracks, die es zu verstehen gilt:

• Ein CTC arbeitet mit mehreren agilen Teams zusammen und coacht Scrum Master, Product Owner und Unternehmensmanager. Ein CTC bleibt im Allgemeinen dabei, einen Bereich einer Organisation zu betreuen, beispielsweise die Softwareentwicklung.
• Ein CEC coacht in der Regel auf der Führungsebene einer Organisation. Ein CEC ist ein Agile-Coach für Unternehmen, dessen Ziel es ist, eine Organisation dabei zu unterstützen, eine vollständige agile Transformation erfolgreich zu erreichen.

Sie fragen sich wahrscheinlich... wie hoch ist die Verpflichtung, eine Zertifizierung zu erhalten? Wir werden es nicht beschönigen — es ist bedeutsam. Dieses Engagement kann jedoch dazu führen, dass Sie Ihr ganzes Berufsleben lang in der Lage sind, spürbare Auswirkungen auf Teams und Organisationen zu haben. Kurz gesagt, Folgendes benötigen Sie, um ein CTC oder CEC zu werden:

• Sei ein Aktiver Zertifizierter Scrum Professional
• Reichen Sie eine erste Bewerbung ein, in der Ihre Agile-Erfahrung beschrieben wird, einschließlich Team- und Organisationscoachings, der Teilnahme an agilen Community-Aktivitäten und Ihrer Anwendung agiler Praktiken
• Reichen Sie eine zweite Bewerbung ein, die Ihr Wissen, Ihre Denkweise und Ihre Herangehensweise als Coach bewertet und Empfehlungen von Mentoren und Kunden erfordert
• Eine jährliche Zertifizierungsgebühr
• Weiterbildungsanforderungen zur Aufrechterhaltung Ihrer Zertifizierung

Gute Agile Coaches lernen weiter

Es kann lange dauern, die Erfahrung zu sammeln, um ein agiler Coach zu werden. Danach ist es wichtig, mit den zentralen agilen Konzepten und deren Beziehung zu aktuellen Trends in der Softwareentwicklung auf dem Laufenden zu bleiben, um genügend Wissen zu haben, um Ihre Qualifikationen aufrechtzuerhalten.

Wir glauben, dass unsere agilen Ressourcen für die Weiterbildung so gut sind, wie Sie es nur finden können. Hier sind einige Beiträge, die einige der wichtigsten Bereiche hervorheben, über die wir zuvor gesprochen haben:

• Was ist der Unterschied zwischen Kanban und Scrum?
• Lernen Sie zuerst Agile — dann lernen Sie, wie Sie es skalieren
• Warum große Unternehmen das Scaled Agile Framework (SAFe) benötigen, nicht Agile auf Teamebene

Aber warte... es gibt noch mehr! Gehen Sie rüber zu unserem Blog für unseren Schatz an Ressourcen — und wenn Sie es leid sind zu lesen, setzen Sie Ihre Kopfhörer auf und hören Sie unsere Podcast-Folge mit einem agilen Coach.

Dieser Leitfaden befasst sich mit den vier Zeremonien die eines der beliebtesten Frameworks von Agile bieten, Gedränge, zum Leben.

Erfahren Sie, wie jedes agile Ritual dazu beiträgt, Teams zu stärken und die Leistung zu steigern, und geben Sie einige Tipps heraus, mit denen Ihr Unternehmen das Beste aus Ihren Zeremonien herausholen kann.

Auf einen Blick:

• Die vier agilen Zeremonien sind Sprint-Planung, Tägliches Aufstehen, Sprint-Rückblick und Sprint-Rückblick
• Zeremonien in Agile ermöglichen Sichtbarkeit, Transparenz und Zusammenarbeit.
• Jede Zeremonie hat eine klare Struktur und ein klares Ziel.
• Klare Kommunikation, Flexibilität und kulturelle Ausrichtung sind die Schlüssel zu erfolgreichen Zeremonien.

Was sind die wichtigsten agilen Zeremonien?

Agile Zeremonien beziehen sich auf die vier Ereignisse, die während einer Scrum Sprint. Andere Formen der agilen Entwicklung, wie Kanban und Schlank, haben auch ähnliche Praktiken.

Das Liste agiler Zeremonien beinhaltet:

1. Sprint-Planung
2. Tägliches Aufstehen
3. Sprint-Rückblick
4. Sprint-Rückblick

Obwohl jede Zeremonie anders ist, dienen sie doch dem gleichen Gesamtzweck. Die Zeremonien bringen Teams mit einem gemeinsamen Ziel in einem regelmäßigen Rhythmus zusammen und helfen den Teams, Dinge zu erledigen.

„Unternehmen stehen heute unter erhöhtem Druck, schnell auf die Bedürfnisse ihrer Kunden und Stakeholder zu reagieren. Daher müssen sie neue Produkte schneller auf den Markt bringen und Verbesserungen vorhandener Lösungen und Dienstleistungen beschleunigen. „- Bericht zum Stand von Agile

Warum sind agile Zeremonien wichtig?

Agile Zeremonien helfen Organisationen, sich an Veränderungen anzupassen und erfolgreich zu sein. Da die Arbeit in kleineren Portionen und über kürzere Zeiträume geplant wird, helfen sie Teams dabei, schnell die Richtung zu ändern und bei Bedarf Kurskorrekturen vorzunehmen. Sie sind ein wichtiger Bestandteil des umfassenderen agilen Ansatzes, der heute in Unternehmen auf der ganzen Welt weit verbreitet ist.

Mit agilen Zeremonien können Teams in Ihrer Organisation von folgenden Vorteilen profitieren:

• Verbesserte Fähigkeit, sich ändernde Prioritäten zu verwalten
• Beschleunigung der Softwareentwicklung
• Steigerung der Teamproduktivität
• Bessere Abstimmung von Geschäft und IT

Es ist wichtig, sich daran zu erinnern, dass Zeremonien zwar ein wesentlicher Bestandteil von Scrum sind, aber nur eines von vielen Ritualen, die dazu beitragen, agile Teams und Arbeitsplätze zu schaffen. Um die wahren Vorteile von Agile zu nutzen, müssen Sie mehr tun, als eine oder mehrere der Zeremonien in Ihre Wasserfall-Projekt.

1. Sprint-Planung

Die Sprint-Planungszeremonie bereitet die Teams auf Erfolgskurs vor, indem sichergestellt wird, dass jeder die Sprintziele versteht und weiß, wie sie erreicht werden können.

• Struktur - Der Product Owner bringt das Produkt-Backlog mit, um es mit dem Entwicklungsteam zu besprechen. Der Scrum Master erleichtert. Zusammen nimmt das Scrum Team Schätzungen des Aufwands oder der Story Point vor. Das Produkt-Backlog muss alle Details enthalten, die für die Schätzung erforderlich sind. Der Product Owner sollte in der Lage sein, alle Zweifel bezüglich des Produkt-Backlogs zu klären.

• Teilnehmer - Das gesamte Scrum-Team (das Entwicklungsteam, der Scrum Master und der Product Owner).‍

• Zeitlicher Ablauf - Zu Beginn jedes Sprints.‍

• Dauer - Ein bis zwei Stunden Iteration pro Woche. Wenn Sie also einen zweiwöchigen Sprint planen, sollte Ihre Sprint-Planung zwei bis vier Stunden dauern. ‍

• Agiles Framework - Gedränge. Kanban-Teams planen zwar auch, aber weniger formell und pro Meilenstein, nicht iterativ.

Ergebnisse

Nach einigen Teamverhandlungen und Diskussionen sollten Sie bis zum Ende der Sprint-Planung eine klare Entscheidung darüber haben, welche Arbeit das Entwicklungsteam während des Sprints erledigen kann. Dies ist bekannt als Sprintziel.

Das Sprintziel ist eine Erhöhung der gesamten Arbeit, und jeder sollte sich der Verpflichtung sicher sein.

Das Produkt-Backlog definiert Prioritäten, die sich auf die Reihenfolge der Arbeiten auswirken. Dann wandelt der Scrum Master diese Entscheidung um in Sprint-Backlog.

Die besten Tipps

• Konzentrieren Sie sich auf Zusammenarbeit statt auf Wettbewerb.
• Teilen Sie Benutzerberichte in Aufgaben auf, um die Dinge für das Entwicklungsteam operationeller zu gestalten. Wenn Zeit zur Verfügung steht, weisen Sie diese Aufgaben während der Veranstaltung zu.
• Berücksichtigen Sie Feiertage und die Freizeit oder Ferien aller Teammitglieder.
• Behalten Sie das Tempo Ihres Teams im Auge — eine Erfolgsbilanz der Zeit, die für die Implementierung ähnlicher User Stories benötigt wurde, wäre hilfreich.
• Konzentrieren Sie sich auf das Produkt-Backlog und nichts anderes in Bezug auf die Arbeit für den Sprint.

2. Tägliches Aufstehen

Das tägliche Stand-up bringt das Team zusammen und bereitet alle auf den Tag vor. Das Team nutzt diese Zeit, um Blocker zu identifizieren und Pläne für den Tag auszutauschen.

• Struktur - Dies ist ein informelles, ständiges Treffen. Alle Mitglieder des Entwicklungsteams informieren alle darüber, was sie am Vortag getan haben und was sie heute tun. Die Mitglieder besprechen alle Blockaden, die sie haben, und bitten das Team bei Bedarf um Hilfe. Aus Zeitgründen sollten die Updates kurz sein.

• Teilnehmer - Entwicklungsteam, Scrum Master, Product Owner (optional).

• Zeitlicher Ablauf - Täglich, normalerweise morgens.

• Dauer - Kurz und scharf. Nicht länger als 15 Minuten.

• Agiles Framework - Scrum und Kanban.

Ergebnisse

Der Scrum Master sollte alle Blockaden beseitigen, die das Entwicklungsteam verlangsamen oder daran hindern, Ergebnisse zu liefern. Infolgedessen muss sich der Entwicklungsprozess möglicherweise ändern.

Dieser tägliche Pulscheck hält das Team auf dem Laufenden und hilft, Vertrauen aufzubauen. Gemeinsam findet die Gruppe Wege, sich gegenseitig zu unterstützen und zu helfen.

Die besten Tipps

• Verwenden Sie einen Timer, um dieses Meeting auf 15 Minuten zu beschränken.
• Halte deinen Stand jeden Tag zur gleichen Zeit.
• Besprechen Sie nur die Arbeit für den kommenden Tag.
• Wenn das Team verteilt ist, verwenden Sie Videokonferenzen mit eingeschalten Kameras.
• Nach der Veranstaltung sollten lange Diskussionen stattfinden.
• Da der Stand-up den Fortschritt fördert, sollte jeder ein Update bereitstellen und sich jeder sollte sich verantwortlich fühlen.

3. Bewertung im Sprint

Der Sprint Review ist die Zeit, um die abgeschlossenen Arbeiten des Teams zu präsentieren und Feedback von Stakeholdern einzuholen. Eine Vielzahl von Teilnehmern von außerhalb des Teams bietet wertvolle Einblicke aus unterschiedlichen Blickwinkeln. Diese Veranstaltung trägt auch dazu bei, Vertrauen sowohl bei externen als auch bei internen Interessengruppen aufzubauen.

• Struktur - Der Scrum Master übernimmt die Logistik der Eventvorbereitung. Der Product Owner sollte den Stakeholdern Fragen stellen, um so viel Feedback wie möglich zu erhalten. Sie sollten auch alle Fragen ihrer Stakeholder beantworten.

• Teilnehmer - Entwicklungsteam, Scrum Master, Product Owner. Wahlweise Management, Kunden, Entwickler und andere Interessengruppen.

• Zeitlicher Ablauf - Am Ende des Sprints.

• Dauer - In einem einwöchigen Sprint dauert der Sprint Review eine Stunde.

• Agiles Framework - Scrum und Kanban. Kanban-Teams führen diese Überprüfungen nach den Team-Meilensteinen durch, nicht nach Sprints.

Ergebnisse

Nach dieser Zeremonie muss der Product Owner möglicherweise das Produkt-Backlog anpassen oder ergänzen. Möglicherweise veröffentlichen sie auch Produktfunktionen, wenn diese bereits vollständig sind.

Die besten Tipps

• Planen Sie vor dem Meeting genügend Zeit für die Proben ein, damit Ihr Team selbstbewusst auftreten kann, insbesondere wenn externe Stakeholder anwesend sind.
• Präsentieren Sie keine unvollständigen Arbeiten. Überprüfe deine Sprint-Planung und die ursprünglichen Kriterien, wenn du dir nicht sicher bist, ob die Arbeit abgeschlossen ist.
• Konzentrieren Sie sich neben der Produktfunktionalität auf Benutzererfahrung, Wert für den Kunden, und die gelieferten geschäftlicher Wert.
• Überlegen Sie, wie Sie eine feierliche Atmosphäre schaffen können, um die Leistung des Teams anzuerkennen.

4. Sprint-Rückblick

In dieser letzten Scrum-Zeremonie in der Sequenz blickst du auf die Arbeit zurück, die du gerade geleistet hast, und findest heraus, wie du die Dinge beim nächsten Mal besser machen kannst. Die Sprint-Retrospektive ist ein Tool zur Risikominderung in zukünftigen Sprints.

• Struktur - Die Teams besprechen, was während des gesamten Sprints gut gelaufen ist und was schief gelaufen ist. Der Scrum Master sollte das Entwicklungsteam ermutigen, sich zu äußern und nicht nur Fakten, sondern auch seine Gefühle mitzuteilen. Ziel ist es, schnelles Feedback für eine kontinuierliche Verbesserung des Prozesses zu erhalten. Es ist auch eine Gelegenheit, bewährte Verfahren hervorzuheben, die das Team übernommen hat und wiederholen sollte.

• Teilnehmer - Entwicklungsteam, Scrum Master, Product Owner (optional).

• Zeitlicher Ablauf - Am Ende des Sprints.

• Dauer - 45 Minuten pro Sprintwoche.

• Agiles Framework - Scrum und Kanban (gelegentlich).

Ergebnisse

Nach dieser Sitzung sollte das Team die Probleme und Siege, die während der Iteration erzielt wurden, klar verstehen. Gemeinsam erarbeitet die Gruppe Lösungen und einen Aktionsplan, um Prozessprobleme im nächsten Sprint zu verhindern und zu identifizieren.

Die besten Tipps

• Konzentrieren Sie sich sowohl auf Fakten als auch auf Gefühle
• Sammeln Sie Informationen, die Ihnen helfen, sich auf kontinuierliche Verbesserungen zu konzentrieren — dazu können Tools und Beziehungen gehören
• Seien Sie ehrlich und fördern Sie Ideen, die prozessbezogene Probleme lösen
• Auch wenn alles gut gelaufen ist, sollten Sie dieses Meeting abhalten — Rückblicke geben fortlaufende Hinweise für den nächsten Sprint.

„Angesichts der Tatsache, dass sich die Geschwindigkeit des Wandels voraussichtlich fortsetzen wird, war der Bedarf an einem Betriebsmodell, das Schritt hält, noch nie so groß wie heute. „- McKinsey

Agile Lektionen, nach denen man leben kann

Als Team von erfahrenen agilen Praktikern haben wir einige wichtige Erkenntnisse darüber gewonnen, was es braucht, um das Beste aus Ihren agilen Zeremonien herauszuholen und die Grundlagen für eine wirklich agile Organisation zu schaffen.

Hier sind unsere Top-Tipps, um Ihre Zeremonien zum Erfolg zu führen:

• Sei bewusst präsent - Denken Sie daran, sich während der Zeremonien einen Moment Zeit zu nehmen, um innezuhalten und sich daran zu erinnern, warum Sie dort sind. Zeigen Sie anderen, dass Sie anwesend sind, indem Sie ihnen volle Aufmerksamkeit schenken und Ihre Körpersprache verwenden. Richten Sie Ihre Kamera aus der Ferne so aus, als ob Sie ihnen gegenüber sitzen würden, schauen Sie regelmäßig in das Objektiv und verwenden Sie einen ablenkungsfreien Hintergrund.
• Übe aktives Zuhören - Denke darüber nach, was die Person sagt, wer sie ist und was sie von dir braucht. Suchen sie nach einem Resonanzboden, brauchen sie deine Hilfe oder Meinung oder suchen sie nach einer emotionalen Verbindung?
• Motive verstehen - Verstehe die Beweggründe deiner Teamkollegen, bevor du sprichst. Überlege, warum sie sich für das, was du sagst, interessieren sollten, indem du deine Botschaft mit ihren eigenen Beweggründen verbindest. Bieten Sie nach Möglichkeit einen Kontext an, damit sie wissen, warum Ihre Botschaft wichtig ist.
• Sei flexibel - Es ist wichtig, sich daran zu erinnern, dass es für agile Arbeitsweisen kein Patentrezept gibt. Was für ein Team funktioniert, funktioniert möglicherweise nicht für ein anderes. Sie müssen also experimentieren, um herauszufinden, was funktioniert, und dann die Prozesse an die Bedürfnisse Ihres Teams anpassen.
• Kulturelle Ausrichtung schaffen - Die besten Prozesse der Welt werden nicht das liefern, was Sie brauchen, wenn Sie nicht über die Kultur verfügen, die sie unterstützt. Agile Zeremonien müssen von einer Kultur unterstützt werden, in der sich die Mitarbeiter aktiv engagieren, selbstbewusst sind, Probleme anzusprechen, und Wert auf kontinuierliche Verbesserung legen.

Agile Zeremonien führen zu besseren Ergebnissen

Es kann zwar einige Zeit dauern, bis sich Teams, die noch nicht mit Agile vertraut sind, an agile Zeremonien gewöhnt haben, aber sie sind die Mühe wert. Durch die Bereitstellung einer klaren Struktur und erreichbarer Ergebnisse tragen sie dazu bei, dass sich alle Beteiligten auf das Produkt, die Kommunikation und die Prioritäten konzentrieren.

Das Ergebnis? Agile Teams, die schneller qualitativ bessere Produkte liefern — und echte Geschäftsergebnisse liefern.

Wo auch immer sich Ihr Unternehmen auf Ihrem Weg zur Agilität befindet, es lohnt sich zu bedenken, dass jedes Team und jede Produktsuite anders sind. Es gibt also kein einheitliches Erfolgsrezept. Die gute Nachricht ist, dass auch Sie Ihre agilen Zeremonien im Laufe der Zeit wiederholen und verbessern können, indem Sie innerhalb der Denkweise der kontinuierlichen Verbesserung arbeiten, die das agile Framework fördert.

Bereit loszulegen?

Einfacher agiler Teamrhythmus unterstützt die agilen Praktiken deines Teams in Jira. TeamRhythm unterstützt dein Team von der Planung bis hin zur Retrospektive und hilft dir dabei, besser zusammenzuarbeiten, um deinen Kunden einen Mehrwert zu bieten.

Zu den Funktionen gehören:

• Agiles Tool zur Sprint- und Versionsplanung - Die Planung ist schnell und einfach, wenn Sie Probleme auf der Storymap erstellen und abschätzen. Sieh dir deine Arbeit unter Initiativen und Epen an und sieh dir die Swimlane-Statistiken auf einen Blick an. So stellst du sicher, dass die Teamkapazitäten voll, aber nicht überlastet sind
• Agiles Story-Mapping - Bilden Sie die Kundenreise anhand von Initiativen, Epen und Geschichten zusammen mit Ihren agile Jira-Boards. Fügen Sie der Story-Map schnell und einfach neue oder vorhandene Geschichten hinzu. Ziehen Sie per Drag-and-Drop, um Prioritäten nach dem Wert für den Kunden zu setzen.
• Verfeinerung des Produktbestands - Entfliehen Sie Ihrem flachen Backlog und sehen Sie sich Ihre Arbeit in der Storymap-Matrix an. Ziehen Sie Probleme per Drag-and-Drop, um sie zu priorisieren oder zu planen. Mithilfe der Inline-Bearbeitung können Sie Zusammenfassungen und Schätzungen zu Storypoints im Handumdrehen aktualisieren, um den Backlog zu verbessern.
• Team-Retrospektiven - Feiern Sie Erfolge, gewinnen Sie Erkenntnisse und teilen Sie Ihre Erkenntnisse mit Team-Retrospektiven für Scrum und Kanban. So fördern Sie Zusammenarbeit und Transparenz, sodass Sie und Ihr Team kontinuierlich besser werden.

Ist Agile jetzt verteilt?

Es ist kein Geheimnis, dass sich unsere Arbeit in den letzten zwei Jahren komplett verändert hat. In der heutigen Arbeitsumgebung haben sich Unternehmen zu einer hybrides oder vollständig dezentrales Geschäftsmodell, wobei Studien zeigen, dass nur 4% der Arbeitsplätze kehren in Vollzeit ins Büro zurück.

Im Agilen Manifest heißt es in einem der ursprünglichen Prinzipien: „Individuen und Interaktionen statt Prozessen und Tools“. Auch wenn das immer noch zutrifft, wissen wir heute mehr denn je, dass unsere Tools unsere Interaktionen stärken und unsere Prozesse erleichtern.

In mehreren Branchen, die das agile Framework eingeführt haben, ist eine Zunahme verteilter agiler Teams zu verzeichnen. In der Tat, laut der 15. Bericht zum Stand von Agile, 89% der agilen Teams sind verteilt. Nur 3% dieser Teams werden nach COVID in Vollzeit ins Büro zurückkehren. Dies liegt daran, dass Mitarbeiter im Homeoffice besserer Fokus und Produktivität, sind es ist weniger wahrscheinlich, dass sie ihren Job verlassen, und kostet das Unternehmen weniger.

Distributed Agile ist kein neues Konzept mehr, sondern unsere gelebte Realität.

Wie bereiten wir uns auf agile Zeremonien wie PI Planning vor, die ursprünglich als Präsenzveranstaltung konzipiert waren? Wie behalten wir das wertvollste Element der persönlichen Kommunikation bei, ohne Absprachen zu treffen?

Die Herausforderungen von PI Planning mit einem verteilten Team

Traditionell sind Aktivitäten wie PI Planning in Agile so konzipiert, dass Teammitglieder im selben Raum persönlich interagieren können.

PI Planning ist eine zweitägige Veranstaltung, an der alle Mitglieder eines Agile Release Train (ART) zusammen, um ihren nächsten zu planen Programminkrement (PI).

Wie der 15. State of Agile Report zeigte, 89% der agilen Teams sind jetzt verteilt. Für ein verteiltes Team haben Sie die Möglichkeit, Mitarbeiter für jede PI Planning-Sitzung einzuziehen oder eine verteilte PI-Planungssitzung zu unterstützen.

Das ist zwar nett, kann aber für jedes Unternehmen eine teure (und störende) Übung sein, insbesondere wenn Sie es 4 oder 5 Mal im Jahr tun müssen.

Die Durchführung einer verteilten PI-Planung ist auch bei der Verwendung einer physischen Programmplatine mit einer Herausforderung verbunden. Diejenigen, die zu Hause sind, können nicht auf dieselbe Weise auf das physische PI Planning Board zugreifen oder dazu beitragen wie ihre Kollegen, die am selben Ort arbeiten. Infolgedessen können ihre Ideen ungehört verhallen und ihre Möglichkeiten, zum Programmausschuss beizutragen, sind begrenzt.

Verteilte PI-Planung — Best Practice

Anstatt Ihr Remote-Team an einen zentralen Standort zu bringen, um PI Planning persönlich auszuführen, werden bei der verteilten PI-Planung Cloud-basierte Tools verwendet, um Ihr nächstes Program Increment virtuell zu planen und auszuführen.

Auch wenn sich die Methoden ein wenig von der verteilten PI-Planung unterscheiden, sind der Prozess und die gewünschten Ergebnisse dieselben:

• Ein hochrangiger Vertreter erörtert den aktuellen Stand des Geschäfts
• Das Produktmanagement präsentiert die aktuelle Programmvision
• Product Owner und Teams setzen sich getrennt zusammen, um zu besprechen, wie sie die gewünschten Ergebnisse erzielen können
• Teams identifizieren und visualisieren teamübergreifende Abhängigkeiten und arbeiten daran, Blockaden zu beseitigen
• Alle kommen zusammen, um sich über Ihren Programmvorstand auf einen verbindlichen Plan zu einigen

6 Tipps für die Einrichtung einer verteilten PI-Planung

Distributed PI Planning ist keine vorübergehende Ausnahme mehr. Unabhängig davon, ob PI Planning verteilt ist oder nicht, müssen wir sicherstellen, dass wir die gleiche Qualität und die gleichen Ergebnisse beibehalten, die PI Planning anstrebt — wir müssen alle Teams innerhalb des Agile Release Train aufeinander abstimmen.

Um Ihnen dabei zu helfen, haben wir die folgenden 6 Tipps vorbereitet, die Ihnen bei der Vorbereitung auf die verteilte PI-Planung helfen sollen.

Diese Tipps sind nicht Dinge, über die wir uns gerade Gedanken gemacht haben. Wir haben diese Dinge gelernt, als wir mit unseren Kunden gesprochen haben, indem wir die Foren durchsucht und mit Experten auf diesem Gebiet gesprochen haben.

1. Machen Sie die Grundlagen richtig

Die drei Grundlagen sind Kommunikation, Vorbereitung und Ausführung.

Lassen Sie uns zunächst über Kommunikation und Vorbereitung sprechen. Es ist wichtig, für jede Phase des PI-Planungsprozesses geeignete Tools für Online-Interaktionen bereitzustellen: Produktmanager müssen zusammenarbeiten, und Moderatoren, um den Prozess zu verwalten — sowohl im Vorfeld als auch während der Veranstaltung. Wir müssen auch sicherstellen, dass die Teammitglieder auf alle relevanten aktuellen Informationen zugreifen, mühelos zusammenarbeiten und auf Support zugreifen können.

Agiles Skalieren empfiehlt zu haben Pre-PI-Planung Besprechungen, die je nach Komplexität Ihres Lösungsprozesses zwischen 2 und 6 Wochen im Voraus geplant sind.

Lassen Sie uns abschließend über die Hinrichtung sprechen. Die Hinrichtung sollte ablaufen, wenn wir gut kommunizieren und vorbereitet sind. Aber wir müssen darauf vorbereitet sein, dass einige Dinge immer noch schief gehen können. Die Technologie wird uns im Stich lassen. Die Leute können immer noch Probleme haben, auf die Tools zuzugreifen, die wir eingerichtet haben. Die Ausführung wird nicht immer reibungslos ablaufen, aber Iteration ist ein Prinzip der Agilität.

2. Legen Sie die Tagesordnung früh fest, so früh wie möglich

Warum ist das so? Nun, denken Sie an Ihre Mitarbeiter, die von zu Hause aus arbeiten. Sie arbeiten mit ihren Haustieren oder ihrer Familie zusammen, und wenn sie wissen, dass sie PI Planning haben, müssen sie wissen, was von ihnen erwartet wird.

Dies gibt den Mitarbeitern Zeit, ihre Familien über ihre Verpflichtungen für diesen Tag zu informieren, einen Raum ohne Ablenkungen einzurichten und mental auf einige Planungstage vorbereitet zu sein.

Lassen Sie uns auch nicht die Tagesordnung mit all den Veranstaltungen vollstopfen, die wir abhalten müssen. Stellen wir sicher, dass wir genug Zeit haben, um mehrere Pausen im Laufe des Tages einzuplanen, da Studien zeigen, dass Menschen dies eher tun erleben Sie nach einem Tag voller Videokonferenzen eine mentale Erschöpfung.

Es ist zwar wichtig, die Technologie zu verwenden, aber es kann ein bisschen viel werden. Lege Regeln fest, wer sprechen kann und wann du die Stummtaste benutzen musst. Dadurch werden Störungen und Hintergrundgeräusche vermieden, die die Konzentration Ihres Teams stören.

3. Wählen Sie Ihre Werkzeuge mit Bedacht

Verteilte agile Teams können das Beste aus der persönlichen Erfahrung simulieren, indem sie Tools auswählen, die für verteilte und hybride Teams entwickelt wurden: Videokonferenzplattformen, Team-Chat, virtuelle Programmboards und interaktive Bereiche für die Zusammenarbeit.

Für welche Tools Sie sich auch entscheiden, der Schlüssel liegt darin, Lösungen zu finden, mit denen sich Kollegen in Echtzeit verbinden können, egal ob im selben Raum oder auf der anderen Seite der Welt.

Richten Sie die Tools ein, testen Sie sie und stellen Sie sie allen Teilnehmern vor der PI Planning-Sitzung vor. Um Überlastung und Verwirrung zu vermeiden, wählen Sie Tools aus, die nahtlos zusammenarbeiten.

4. Praxis

Wir werden das nicht gleich beim ersten Mal richtig machen. Wir werden proben müssen. Wir müssen herausfinden, wie wir Dinge wie Vertrauensabstimmungen durchführen. Verwenden wir die Umfragefunktion auf Zoom oder verwenden wir Slack?

Jeder zieht es vor, früh fertig zu werden, als die Zeit davonzulaufen. Lassen Sie uns etwas Spielraum in die Tagesordnung einbauen.

Erkennen Sie an, dass es immer Verbesserungspotenzial gibt, und bauen Sie dies in unsere Planung ein. Geben wir unseren Mitarbeitern die Möglichkeit, mit uns zu kommunizieren, sei es durch Rückblick oder indem Sie einen Kanal für Feedback öffnen. Wir erhalten nicht nur Feedback darüber, wie die letzte Planungssitzung verlaufen ist, sondern auch darüber, wie wir die Zusammenarbeit im Allgemeinen finden.

5. Machen Sie es zugänglich

Wenn Sie mit verschiedenen Zeitzonen zu tun haben, sollten Sie die PI-Planungsagenda von 2 Tagen auf 3-4 Tage verlängern, um sicherzustellen, dass alle wichtigen Teile der PI-Planungssitzung zu einem für alle Zeitzonen angemessenen Zeitpunkt stattfinden.

Richten Sie jedes Meeting über Google Kalender oder ein anderes Kalendergerät ein, das Ihr Team möglicherweise bereits verwendet. Stellen Sie sicher, dass jedes Meeting benannt ist, gefolgt von einer Beschreibung, damit die Teilnehmer wissen, was sie vorbereiten müssen und welche Tools für dieses Meeting relevant sind. Stellen Sie sicher, dass die richtigen Teilnehmer vor der Veranstaltung alle Einladungen zum Forum erhalten haben.

Wir werden Probleme haben, die Leute mit neuen Tools vertraut zu machen und ihnen den Zugriff auf die benötigten Ressourcen zu ermöglichen. Es wäre großartig, wenn bei PI Planning technischer Support verfügbar wäre. Das wird für manche Menschen einfacher sein als für andere. Aber es ist entscheidend, wenn etwas schief geht.

Wir werden ein Backup brauchen. Ihre Tools müssen zuverlässig sein, und Sie benötigen technischen Support, um sie schnell zu reparieren.

Wir werden mehr Moderatoren als normalerweise benötigen, um all diese Fragen die ganze Woche über beantworten zu können.

Manche Leute sind vielleicht nicht daran gewöhnt, die Tools zu verwenden, die wir ihnen vorschlagen. Gibt es also Schulungen, die ihnen helfen, sich auf den neuesten Stand zu bringen?

6. Bringe die menschliche Erfahrung auf ein neues Niveau

Ergreifen Sie Gelegenheiten, um sicherzustellen, dass agile Teams das Gefühl haben, zusammenzuarbeiten, auch wenn sie tatsächlich getrennt sind, sodass sich die Mitglieder als Teil einer Community sehen mit:

• Gemeinsames Verständnis — Klarheit über Vision, Mission, Zweck und Überblick darüber, was die Teammitglieder tun, wodurch Lernschleifen zwischen den Kollegen erleichtert werden.
• Geteilte Empathie — Der Aufbau menschlicher Verbindungen zu unserem Stamm schafft die psychologische Sicherheit, um zu lernen, zu wachsen und sich weiterzuentwickeln.
• Gemeinsames Erlebnis — Schaffung eines Gefühls von Teamfähigkeit, Identität und gemeinsamem Bauen.

So zeichnen Sie sich bei verteilter PI-Planung mit Easy Agile Programs und Welo aus

Der schwierigste Teil der verteilten PI-Planung ist Bereitstellung der positiven Aspekte der persönlichen Erfahrung für ein verteiltes Team: flüssige Bewegung in und zwischen Räumen, um zusammenzuarbeiten, einfache Möglichkeiten, zu Brainstorming-Sitzungen beizutragen und Whiteboards auf dem neuesten Stand und zugänglich zu halten, und natürliche soziale Interaktionen, die Vertrauen und Kameradschaft aufbauen.

Einfache agile Programme bietet eine komplette PI-Planungslösung, die eine skalierte teamübergreifende Planung und Ausführung einfach macht. Mit einer nahtlosen Jira-Integration ist es ein leistungsstarkes und dennoch einfach zu bedienendes Tool, mit dem Sie die Planung skalieren und die Abstimmung zwischen verteilten, hybriden oder Remote-Teams während der Planung und während der gesamten Ausführung sicherstellen können.

Nun bietet interaktive Räume für die Zusammenarbeit, die die menschliche Erfahrung für verteilte und hybride Teams verbessern. Es repliziert das persönliche Erlebnis flüssiger Interaktionen, müheloser Zusammenarbeit und menschlicher Verbindungen zwischen Kollegen — und das über das isolierte Video hinaus. Die visuelle Orientierung von Welo ermöglicht es jeder Person, im Kontext des Raums präsent zu sein und sich so zu orientieren, dass sie nach Belieben mit Menschen und Gruppen zusammen sein kann.

Mit diesen beiden Tools können Sie Ihren Agile Release Train für den Erfolg von PI Planning vorbereiten. So geht's:

Wählen Sie professionell gestaltete virtuelle Räume

Bringen Sie die besten stationären Räume, die Sie für die persönliche PI-Planung genutzt haben, online — von Plenarräumen über Pausenräume bis hin zu Orten, an denen Sie ungezwungen Kontakte knüpfen können.

Anstatt sich auf ein statisches Rechteck beschränkt zu fühlen, sehen die Mitarbeiter sich selbst und andere im Kontext, bewegen sich in und zwischen Räumen, um vor, während und nach Veranstaltungen von PI Planning mit Kollegen in Kontakt zu treten.

Welo Spaces bieten PI-Teilnehmern auch direkten Zugriff auf aktuelle, relevante Ressourcen wie Jira- und Easy Agile-Apps, die bei allen Veranstaltungen verwendet werden.

Stellen Sie den Geschäftskontext her

Alle Agile Release Train-Mitglieder können auf Informationen über das Programm zugreifen in Einfache agile Programme. Im Abschnitt „Ziele“ unten könnten Sie beispielsweise auf ein vorab aufgezeichnetes Video verlinken, in dem der Geschäftsinhaber die Ziele auf Unternehmensebene anspricht. Daher wissen die Teams, dass ihre Ziele auf Teamebene dazu beitragen müssen. Dadurch wird sichergestellt, dass alle Mitglieder des Agile Release Trains Ihren Geschäftsinhaber auf diese verteilte Weise von Angesicht zu Angesicht sehen und dass sie während der gesamten PI-Planung immer Zugriff auf dieses Video haben.

Nachdem der Produktmanager die Informationen über das Programm gelesen hat, kann er vor dem PI Planning-Event Funktionen in Jira erstellen, die in der Planung besprochen und aufgeschlüsselt werden. Easy Agile Programs lässt sich nahtlos in Jira integrieren, sodass Sie die Arbeit nicht doppelt erledigen müssen. Sie sind bereit, anhand einer visuellen Zeitleiste zu planen, sodass jeder sehen kann, wofür sich das Team während der PI-Planung verpflichtet hat.

Richten Sie Ihr SAFe Program Board ein

Das SAFe Program Board ist ein wichtiges Tool und Ergebnis von PI Planning. Es ist eine visuelle Zusammenfassung von Funktionen oder Zielen, teamübergreifenden Abhängigkeiten und anderen Faktoren, die sich auf deren Umsetzung auswirken. Dies trägt nicht nur zur Transparenz bei, sondern erhöht auch die Flexibilität, wodurch Verzögerungen und schädliche Abhängigkeiten minimiert werden.

Stellen Sie sicher, dass Sie vor der PI-Planungssitzung ein digitalisiertes SAFe-Programmboard eingerichtet haben. Easy Agile Programs repliziert das physische Programmboard. Ein Board, auf das jeder die gleiche Ansicht hat und auf das jeder zugreifen kann. Erfahren Sie, wie Sie mit Easy Agile Programs ein SAFe Program Board einrichten hier.

Bereite deine Teamplanungstafel vor

Das Team Planning Board ist ein Scrum- oder Kanban-Board, das im Programm enthalten ist. Hier planen die Teams ihre Arbeit in den Team-Breakout-Sitzungen während der PI-Planung.

Wenn Sie Ihr Program Board mit Easy Agile-Programmen eingerichtet haben, bereiten Sie die Team-Planungstafeln vor, indem Sie jedes Team vor der PI-Planung zum Programm hinzufügen. Sobald Teams hinzugefügt wurden, werden die Planungstafeln automatisch erstellt und sind bereit für Team-Breakout-Sitzungen. Teams können PI-Ziele auf Teamebene festlegen, Funktionen in Benutzerberichte unterteilen, Probleme abschätzen, um die Kapazität zu verstehen, und Abhängigkeiten zu anderen Teams herstellen.

Vorwärts

Mit verteilter PI-Planung Realität für fast 90% der agilen Teams, die gute Nachricht ist, dass neue Lösungen entwickelt werden, die mit Ihren aktuellen Tools funktionieren. Sie fördern das Mitarbeiterengagement, die reibungslose Zusammenarbeit und effiziente Prozesse, die für erfolgreiche Ergebnisse und berufliche Zufriedenheit entscheidend sind.

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

Nehmen Sie an einer Demo teil