Backlog Refinement

Stellen Sie sich vor, Sie versuchen, ein komplexes Möbelstück ohne die visuelle Bedienungsanleitung zusammenzubauen - nur eine lange Liste von Schritten. Frustrierend, oder? Genau so fühlen sich viele Teams, wenn sie von einem flachen Produkt-Backlog aus arbeiten. Sie haben Listen mit Funktionen und Anforderungen, aber sie haben die gesamte Customer Journey aus den Augen verloren.

Das ist wo Zuordnung von Benutzergeschichten kommt rein. Es hilft uns, den Wald zu sehen, bevor wir uns in den Bäumen verirren.

Die Macht des narrativen Flusses bei der Produktentdeckung

Das User Story Mapping verändert die Art und Weise, wie Teams an die Produktentdeckung herangehen. Anstatt direkt auf die Funktionen einzugehen, hilft es Ihnen, die gesamte Reise zu visualisieren, die ein Kunde mit Ihrem Produkt von Anfang bis Ende durchläuft. Dieser Fokus liegt auf Kundenorientierung stellt sicher, dass Sie Funktionen erstellen, die wirklich wichtig sind.

Wie Jeff Patton, der Pionierarbeit beim User Story Mapping geleistet hat, erklärt, sind traditionelle flache Backlogs so, als würde man versuchen, ein Buch zu verstehen, indem man eine Liste von Sätzen in zufälliger Reihenfolge liest. Sicher, der gesamte Inhalt ist da, aber die Geschichte — die Reise des Nutzers — geht verloren.

„Das User Story Mapping ist ein moderiertes, kuratiertes Gespräch, das alle mit auf die Reise nimmt. Es ist eine Gelegenheit für den Produktmanager, seine Erkenntnisse (der Tag für Tag tief in diesem Zeug steckt) zu analysieren und sie in die Köpfe des Teams zu übertragen, das im Begriff ist, sie umzusetzen. „- Nicholas Muldoon, Mitbegründer und CEO von Easy Agile

Erstellen Sie Ihre erste User Story Map

Sehen wir uns die Erstellung einer User Story Map für einen Streaming-Dienst wie Netflix oder Apple TV an. Wir werden sehen, wie ihre Teams das Nutzererlebnis beim Ansehen eines Films abbilden könnten.

Schritt 1 — Fangen Sie mit dem Gesamtbild an

‍

Identifizieren Sie zunächst die Hauptaktivitäten, die Ihre Nutzer durchmachen — was Jeff Patton das „Rückgrat“ oder den „Erzählfluss“ Ihrer Storymap nennt. Stellen Sie sich diese als Kapitelüberschriften in der Story Ihres Benutzers vor.

Für unser Beispiel für einen Streaming-Dienst könnte das Backbone so aussehen:

• Wählen Sie einen Film
• Film kaufen
• Film anschauen
• Film rezensieren/empfehlen

‍

🎯 Teamübung: Stellen Sie Ihr Team zusammen und fragen Sie: „Was sind die wichtigsten Schritte, die unsere Benutzer unternehmen, um ihr Ziel zu erreichen?“ Schreiben Sie jeden Schritt auf eine Karte oder eine Haftnotiz und ordnen Sie sie in chronologischer Reihenfolge von links nach rechts an.

Schritt 2 — Benutzeraufgaben hinzufügen

Jetzt kommen die vielen Details. Fügen Sie unter jeder Hauptaktivität die spezifischen Aufgaben hinzu, die Benutzer erledigen müssen. Diese werden zu Ihren Benutzergeschichten. Der Schlüssel liegt darin, sich weiterhin auf den Nutzernutzen und nicht auf die technische Umsetzung zu konzentrieren.

Im obigen Beispiel könnten dies Ihre User Stories für die Aktivität „Film auswählen“ sein:

• Freitextsuche
• Nach Genre durchsuchen
• Nach Neuzugang durchsuchen
• Nach den beliebtesten durchsuchen
• Sortiere nach den beliebtesten nach Genre
• Nach Neuzugang nach Genre durchsuchen

💡 Profi-Tipp: Schreiben Sie diese Aufgaben aus der Sicht des Benutzers. Anstatt „Suchfunktion implementieren“ zu schreiben, schreiben Sie „Nach bestimmten Filmen suchen“.

‍

Schritt 3 — Master-Backlog-Priorisierung

Hier glänzt das User Story Mapping im Vergleich zu flachen Backlogs wirklich. Sie organisieren Ihre Storys sowohl horizontal (in der Reihenfolge) als auch vertikal (nach Priorität). Dieser Ansatz hilft sowohl bei der Priorisierung von Funktionen als auch bei der Sprint-Planung.

Horizontal: Ordne Geschichten von links nach rechts in der Reihenfolge an, in der Benutzer sie natürlich aufführen würden.

Vertikal: Ordnen Sie die Geschichten von oben nach unten in der Reihenfolge ihrer Priorität an, und zwar nach dem Wert, den sie für den Nutzer haben. Sie können den Wert anhand von Gesprächen mit Nutzern, Analysen von Nutzungsmustern oder einer anderen Form von Erkenntnissen, die für Ihr Produkt geeignet sind, ermitteln.

Stell es dir vor, als würdest du ein Haus bauen. Das Fundament (Must-Haves) kommt zuerst, dann die Wände (sollte man haben) und schließlich die dekorativen Details (Nice-to-Haves).

Vorrangiger Rahmen:

HOCH (Muss sein)

• Kernfunktionen, die für die grundlegende Benutzererfahrung unerlässlich sind
• Kritische Nutzerbedürfnisse wurden aus der Forschung identifiziert
• Beispiel: Einfache Suche, Filmwiedergabe, Zahlungsabwicklung

MEDIUM (hätte sein sollen)

• Wichtige Funktionen, die das Benutzererlebnis verbessern
• Bestätigte Benutzerwünsche anhand von Feedback
• Beispiel: Genrefilterung, Empfehlungen, Bewertungsanzeige

NIEDRIG (Schön zu haben)

• Zusätzliche Funktionen für mehr Vergnügen
• Mögliche zukünftige Verbesserungen
• Beispiel: Teilen in sozialen Netzwerken, Erweiterte Empfehlungen, mehrere Beobachtungslisten

‍

Schritt 4 — Identifizieren Sie Ihre Veröffentlichungen

Zeichnen Sie nach dem Layout Ihrer Karte horizontale Linien, um Ihre Karte in Abschnitte zu unterteilen. Jedes Segment sollte ein vollständiges, wertvolles Nutzererlebnis bieten.

Moderation von User Story Mapping-Sitzungen

Um eine effektive User Story Mapping-Sitzung durchzuführen, müssen Sie mehr als nur die oben genannten Schritte ausführen. Ganz gleich, ob Ihr Team am gleichen Standort oder über mehrere Zeitzonen verteilt ist, wie Sie diese Sitzungen produktiv und ansprechend gestalten können:

Checkliste vor der Sitzung

• Laden Sie die richtigen Personen ein (Product Owner, Entwickler, Designer, Fachexperten)

• Bereiten Sie Erkenntnisse und Daten aus der Kundenforschung vor

• Richten Sie einen physischen oder digitalen Raum für die Zusammenarbeit ein

• Definieren Sie klare Sitzungsziele

• Planen Sie ausreichend Zeit ein (in der Regel 2-4 Stunden für die erste Kartierung)

Checkliste während der Sitzung

• Beginnen Sie mit dem Kundenkontext (teilen Sie Forschungsergebnisse, Personas)

• Konzentrieren Sie sich auf die Benutzerperspektive

• Dokumentieren Sie Fragen und Annahmen

• Machen Sie Fotos/Screenshots von laufenden Arbeiten

• Erfassen Sie Aktionspunkte und Entscheidungen

User Story Mapping für Teams am selben Standort

Stellen Sie sicher, dass der physische Raum für die perfekte User Story-Mapping-Sitzung gut ausgestattet ist.

• Große Wandfläche oder Whiteboard
• Viele Haftnotizen in verschiedenen Farben
• Marker für alle
• Raum für Teambewegung und Diskussion

User Story Mapping für Remote-Teams

Viele Teams müssen oft dirigieren User Story Mapping-Sitzungen aus der Ferne. Die Prinzipien bleiben zwar dieselben, die Ausführung erfordert jedoch einige zusätzliche Überlegungen:

1. Digitaler Arbeitsplatz:
   • Wählen Sie Tools für die Zusammenarbeit wie Easy Agile TeamRhythm
   • Vorlage vorher einrichten
   • Stellen Sie sicher, dass jeder Zugriff hat und mit den Tools vertraut ist
2. Engagement-Techniken:
   • Nutzen Sie kleinere Pausenräume für ausführliche Diskussionen
   • Nutzen Sie digitale Wahlen zur Priorisierung
   • Verwenden Sie zeitgesteuerte Aktivitäten, um die Energie aufrechtzuerhalten
   • Planen Sie kürzere Sitzungen mit klaren Pausen ein
   • Nehmen Sie Sitzungen für Teammitglieder in verschiedenen Zeitzonen auf

So funktioniert Remote User Story Mapping für Sie

Während der Pandemie wandte sich Lyft an Easy Agile TeamRhythm Story-Mapping von Benutzern aus der Ferne um ihre Teams zu verbinden und konzentriert zu halten, während sie von zu Hause aus arbeiten. Dieses Tool erleichterte es ihren verteilten Teams, zusammenzuarbeiten, Kundenreisen zu visualisieren und Prioritäten im Auge zu behalten — auch wenn alle voneinander getrennt waren.

Das Ergebnis? Eine Steigerung der Effizienz um 20% und eine reibungslosere, besser abgestimmte Teamarbeit. Es ist ein gutes Beispiel dafür, wie das richtige Tool dafür sorgen kann, dass sich die Arbeit im Home-Office viel weniger fernab anfühlt.

Bereit es auszuprobieren? Lassen Sie uns den Erfolg Ihres Teams mit folgenden Daten abbilden Einfacher agiler Teamrhythmus!

Häufige Fallstricke, die es zu vermeiden gilt

1. „Wir verlieren das große Ganze“

Lösung: Halten Sie Ihr Rückgrat jederzeit sichtbar. Treten Sie regelmäßig einen Schritt zurück und gehen Sie die gesamte Benutzerreise durch.

2. „Technische Diskussionen bringen uns aus der Patsche“

Lösung: Schaffen Sie einen „Parkplatz“ für technische Diskussionen. Konzentrieren Sie sich zunächst auf die Erfahrung des Benutzers und befassen Sie sich dann in separaten Sitzungen mit den Einzelheiten der Implementierung.

3. „Teilnehmer aus der Ferne engagieren sich nicht“

Lösung: Verwenden Sie Round-Robin-Techniken, um sicherzustellen, dass jeder seinen Beitrag leistet. Schaffen Sie explizite Gelegenheiten für Beiträge von Teammitgliedern an verschiedenen Standorten.

4. „Unsere Landkarte ist veraltet“

Lösung: Planen Sie regelmäßige Überprüfungssitzungen ein. Machen Sie die Aktualisierung der Karte zu einem Teil Ihrer Sprint-Zeremonien.

Halten Sie Ihre Storymap am Leben

Ihre User Story Map sollte keine einmalige Übung sein, die weggepackt wird. Sie sollte sich weiterentwickeln, wenn sich Ihr Verständnis von Benutzern vertieft. Halten Sie es lebendig und relevant, indem Sie:

1. Es sichtbar machen

• Präsentieren Sie es gut sichtbar in Ihrem Teambereich
• Halten Sie es in Ihren digitalen Tools zugänglich
• Verweisen Sie in Planungssitzungen darauf

2. Regelmäßige Aktualisierung

• Fügen Sie neue Erkenntnisse aus Kundenfeedback hinzu
• Passen Sie die Prioritäten auf der Grundlage der Erkenntnisse an
• Erledigte Artikel markieren
• Beachten Sie Änderungen der Benutzerbedürfnisse oder des Benutzerverhaltens

3. Verwenden Sie es zur Ausrichtung

• Referenz bei der Sprint-Planung
• Mit Stakeholdern teilen
• Wird für das Onboarding neuer Teammitglieder verwendet

Erfolgsmessung

Achten Sie abschließend auf diese Indikatoren, um festzustellen, ob Ihr Story-Mapping effektiv ist. Besondere Requisiten für dich und das Team, wenn du sie alle auf den Punkt bringst.

✓ Die Teammitglieder beziehen sich bei Diskussionen natürlich auf die Karte

✓ Kundenfeedback entspricht Ihrer Priorisierung

✓ Releases bieten kohärente Benutzererlebnisse

✓ Weniger unüberschaubare Funktionen und überlastete Funktionen

✓ Verbesserte Teamausrichtung auf Prioritäten

✓ Bessere Sprint-Planungssitzungen

Denken Sie daran, dass es beim User Story Mapping nicht darum geht, ein perfektes Dokument zu erstellen — es geht darum, bessere Gespräche über die Bedürfnisse der Nutzer zu führen und sicherzustellen, dass wir die richtigen Dinge in der richtigen Reihenfolge erstellen.

‍

Sie möchten tiefer in die Entwicklung kundenorientierter Produkte eintauchen? Laden Sie unser kostenloses E-Book „Understanding Customer Value in Agile“ herunter um zu lernen:

• Wie Sie der „Build-Falle“ entkommen und sich auf echte Kundenergebnisse konzentrieren
• Praktische Techniken, um Ihre Kunden tief zu verstehen
• Frameworks für die Erfassung und Umsetzung von Kundeninformationen
• Schrittweise Anleitung zur Erstellung aussagekräftiger Personas und Reisekarten
• Ein konkreter 30-60-90-Tage-Plan, um die Art und Weise zu verändern, wie Ihr Team den Kundennutzen versteht und erbringt

Laden Sie Ihr kostenloses Exemplar herunter hier und beginnen Sie Ihre Reise zu einer wirklich kundenorientierten agilen Entwicklung.

‍

Das siebte Prinzip des Manifests für agile Softwareentwicklung lautet:
Funktionierende Software ist das wichtigste Maß für den Fortschritt.
Keine Storypoints, keine Geschwindigkeit, keine Schätzungen: funktionierende Software.

Jason Godesky, Bessere Programmierung

Schätzungen sind eine häufige Herausforderung für agile Softwareentwicklungsteams. Die erwartete Größe und Komplexität einer Aufgabe ist alles andere als objektiv; was für eine Person einfach ist, ist es für eine andere möglicherweise nicht. Story Points sind zur wichtigsten Kennzahl geworden, um den Aufwand abzuschätzen, der mit der Erledigung einer Aufgabe verbunden ist, und werden häufig zur Leistungsmessung verwendet. Aber hat das einen echten Wert und welche Risiken bestehen, wenn man sich zu sehr auf die Geschwindigkeit als Richtwert verlässt?

Agile Schätzung

Als Menschen sind wir im Allgemeinen schlecht darin, große Dinge in Einheiten wie Zeit, Entfernung oder in diesem Fall Komplexität genau zu messen. Wir sind jedoch hervorragend darin, relative Vergleiche anzustellen — wir können feststellen, ob etwas größer, kleiner oder genauso groß ist wie etwas anderes. Hier kommen Story Points ins Spiel. Story Points sind eine Möglichkeit, den relativen Aufwand für eine Aufgabe abzuschätzen. Sie sind nicht objektiv und können je nach Erfahrung des Teams und gemeinsamen Referenzpunkten schwanken. Je länger ein Team jedoch zusammenarbeitet, desto effektiver werden sie in Bezug auf die relative Größe.

Die Teams, die ich coache, hatten alle Probleme mit der Schätzung von Nutzergeschichten. Die historischen Daten zeigen uns, dass, sobald eine Story 5 Storypoints überschreitet, die Variabilität bei der Bereitstellung zunimmt. In der Regel gilt: Je mehr die Schätzung 5 Punkte überschreitet, desto stärker weicht die Darstellung von der Schätzung ab.

Robin D Bailey, Agiler Coach, GoSourcing

Referenzskala

Story Points sind zwar als Abstraktion für Planung und Schätzung nützlich, sollten aber nicht überanalysiert werden. In einem neu gebildeten Team werden die Storypoints wahrscheinlich stark schwanken, aber in einem Team, das schon viele Releases zusammen fertiggestellt hat, kann man mehr Vertrauen in die Zuverlässigkeit von Schätzungen haben. Zwei verschiedene Teams werden jedoch unterschiedliche Referenzskalen haben.

Auf Unternehmensebene bestand der wichtigste Wert, nach dem ich bei Story Points gesucht habe, darin, alle systemischen Probleme zu verstehen. Damals zum Beispiel, als Atlassian vierteljährlich auf Server veröffentlichte, gingen die Sprints vor einer Veröffentlichung schnell über die Bühne und verfehlten den üblichen Grad der Fertigstellung von Storypoints. Es stellte sich heraus, dass die Hauptursache ein massiver Anstieg kritischer Fehler war, die durch hochwertige Blitztests aufgedeckt wurden. Indem wir früher und regelmäßiger bessere Tests durchgeführt haben, haben wir die Last verteilt und auch dazu beigetragen, das Risiko der Veröffentlichungen zu verringern. Rückblickend klingt das einfach, aber es waren neue Erkenntnisse für unsere Teams zu der Zeit, die aufgedeckt werden mussten.

Mat Lawrence, COO, Easy Agile

Selbst bei gut etablierten Teams kann die Geschwindigkeit durch Faktoren wie erhöhte Komplexität bei gemeinsam geplanten Abhängigkeiten oder auch nur durch die durchschnittliche Anzahl von Story Points pro Ticket beeinflusst werden. Wenn ein Team viele Tickets mit geringer Komplexität geplant hat, reicht sein Prozess möglicherweise nicht für den erforderlichen Durchsatz aus. Wenn andere Teammitglieder weniger Tickets mit hoher Komplexität haben, könnte dies den Aufwand, den andere Teammitglieder zur Überprüfung der Arbeit benötigen, drastisch erhöhen. Beide Situationen könnten sich auf die Geschwindigkeit auswirken, aber beide stellen Engpässe dar.

Jede gemessene Änderung der Geschwindigkeit könnte auf eine Reihe anderer Faktoren zurückzuführen sein, z. B. auf Kapazitätsverschiebungen aufgrund von Änderungen der Mitarbeiterzahl, bei denen Teammitglieder aufgrund von Krankheit oder geplantem Urlaub abwesend sind. Die Realität ist, dass die Umgebung selten steril und kontrolliert ist.

Relative Geschwindigkeit

Viele Unternehmen fühlen sich vielleicht versucht, über Storypoints zu berichten, und Velocity-Berichte sind in Jira leicht verfügbar. Dennoch sollten sie mit Vorsicht betrachtet werden, wenn sie in einem „Team von Teams“ verwendet werden, z. B. in einem Agile Release Train. Aufgrund der unterschiedlichen Referenzskalen in den einzelnen Teams können Storypoints bedeutungslos werden. Was ein Team als 8-Punkte-Aufgabe ansieht, kann für ein anderes eine 3-Punkte-Aufgabe sein.

Für viele Manager bedeutet das Vorhandensein einer Schätzung, dass es einen „tatsächlichen“ Wert gibt. Dies bedeutet, dass Sie Schätzungen mit Istwerten vergleichen und sicherstellen sollten, dass Schätzungen und Istwerte übereinstimmen. Wenn sie das nicht tun, bedeutet das, dass die Mitarbeiter lernen sollten, besser abzuschätzen.

Wenn also das Vorhandensein einer Schätzung dazu führt, dass das Management den Blick von der Wertschöpfung abwendet und sich stattdessen auf die Verbesserung der Schätzungen konzentriert, lenkt es die Aufmerksamkeit vom zentralen Zweck ab, nämlich schnell einen echten Wert zu liefern.

‍Ron Jefferies
Mitautor des Manifests für agile Softwareentwicklung
Story Points überarbeitet

Ich suche Wert

Story Points sind jedoch immer noch ein wertvolles Werkzeug, wenn sie richtig eingesetzt werden. Storypoints dem Team, das sie verwendet, zu melden und Einblicke in ihre einzigartigen Trends zu geben, könnte ihnen helfen, mehr Selbstbewusstsein zu gewinnen und häufige Fallstricke zu vermeiden. Teams, die ihre Arbeitsweise verbessern möchten, möchten möglicherweise ihre Geschwindigkeit im Laufe der Zeit überwachen, während sie neue Strategien umsetzen.

Sicherlich werden Teams, die über einen längeren Zeitraum zusammenarbeiten, zu einem gemeinsamen Verständnis davon gelangen, wie sich eine 3-Story-Point-Aufgabe für sie anfühlt. Und die Diskussion und Erkundung, die erforderlich sind, um zu einem Punkt des gemeinsamen Verständnisses zu gelangen, sind wertvoll. Das Argument für 8 Storypoints im Gegensatz zu 3 kann eine Komplexität aufdecken, die bisher nicht berücksichtigt wurde, oder es kann eine neue Perspektive aufzeigen, die dazu beiträgt, die Arbeit effektiver aufzuschlüsseln. Es könnte sich auch die Frage stellen, ob es sich lohnt, die Arbeit überhaupt fortzusetzen, und deutlich machen, dass ein neuer Ansatz erforderlich ist.

Der Wert von Story Points für mich (als Entwickler und Gründer) sind die Gespräche, in denen das Thema von Menschen mit unterschiedlichen Perspektiven diskutiert wird. Velocity ist nur in langfristigen Teams mit hoher Mitarbeiterbindung relativ genau.

Dave Elkan, Co-CEO von Easy Agile

Auf Unternehmensebene können Story Points verwendet werden, um systemische Probleme zu verstehen, indem Trends im Zeitverlauf beobachtet werden. Diese Berichterstattung bietet zwar keine objektive Messgröße, kann aber Einblicke in die Fortschritte innerhalb eines Agile Release Trains geben. Der Abschluss eines Story Points als Maßstab für die Leistung von Einzelpersonen oder Teams sollte jedoch mit großer Vorsicht betrachtet werden.

Story Points sind ein nützliches Schätzinstrument, um den relativen Aufwand zu vergleichen. Sie hängen jedoch von gemeinsamen Bezugspunkten ab, und verschiedene Teams haben unterschiedliche Skalen. Selbst etablierte Teams können im Laufe der Zeit Geschwindigkeitsänderungen feststellen. Aus diesem Grund können Geschwindigkeitsberichte zwar Aufschluss über den Fortschritt des Teams geben, es darf jedoch nicht vergessen werden, dass Story Points eher zur Einschätzung des Aufwands als zur Messung konzipiert wurden. Und am Ende des Tages ist es unser Geschäft, großartige Software zu erstellen, keine großartigen Schätzungen.

Sie möchten Ihr Team auf Verbesserungen konzentrieren? Easy Agile TeamRhythm hilft dir dabei, Erkenntnisse in die Tat umzusetzen — mit Team-Retrospektiven, die mit deinem Agile-Board in Jira verknüpft sind. So kannst du deine Arbeitsweise verbessern und dein nächstes Release besser machen als das letzte. Verwandeln Sie ein Aktionselement mit nur wenigen Klicks in ein Jira-Problem und planen Sie dann die Arbeit auf der User Story Map, um sicherzustellen, dass Ihre Ideen am Ende der Retrospektive nicht verloren gehen.

Vielen Dank an Satvik Sharma, John Folder, Matthew Lawrence, David Elkan, Henry Seymour, und Robin D. Bailey dafür, dass Sie ihr Fachwissen und ihre Erfahrung in diesen Artikel eingebracht haben.

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

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

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

Was ist falsch an flachen User Story Backlogs?

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

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



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



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

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

Mängel eines flachen Produktrückstands

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

Story-Maps von Benutzern

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

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

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

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

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

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

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

Einfacher agiler Teamrhythmus

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

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.

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

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

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

Warum User Stories schreiben?

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

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

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

Was ist eine User Story?

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

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

Eine User Story = das „Was“

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

User Stories unterteilen Funktionen in Geschäftsprozesse.

Eine Aufgabe = das „Wie“

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

Aufgaben sind einzelne Arbeiten.

Wie schreiben wir User Stories?

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

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

Lassen Sie uns das weiter aufschlüsseln;

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

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

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

Schauen wir uns ein paar einfache Beispiele an;

Als Internetbanking-Kunde

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

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

ODER

Als Administrator

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

Also das Ich kann Aufgaben effizienter delegieren

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

Um erfolgreiche User Stories zu schreiben:

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

Akzeptanzkriterien

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

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

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

Ziele der Akzeptanzkriterien

Die Akzeptanzkriterien sollten:

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

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

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

Akzeptanzkriterien:

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

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

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

Die Akzeptanzkriterien sollten NICHT Folgendes beinhalten:

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

Warum?

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

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

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

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

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

Konzentrieren Sie sich auf Ihre Kunden

Einfacher agiler Teamrhythmus

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.

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

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

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

Was ist agile Sprint-Planung?

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

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

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

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

Wie die Sprint-Planung in den Scrum-Prozess passt

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

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

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

Scrum-Rollen: Die Menschen

In einem Scrum-Team gibt es drei Hauptrollen.

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

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

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

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

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

Artefakte: Was wird gemacht

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

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

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

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

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

Scrum-Zeremonien: Wo Sprint Planning passt

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

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

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

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

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

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

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

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

Die Vorteile der agilen Sprint-Planung

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

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

So bereiten Sie sich auf ein Sprint-Planungstreffen vor

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

Verfeinerung des Backlogs

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

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

Tipps zur Aufrechterhaltung eines gesunden Backlogs:

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

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

Sei konsistent

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

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

So führen Sie ein Sprint-Planungsmeeting durch

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

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

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

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

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

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

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

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

3. Definieren Sie klare Ziele und Ergebnisse

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

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

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

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

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

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

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

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

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

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

5. Richten Sie Sprintziele mit Produktzielen aus

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

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

Was passiert als Nächstes?

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

Tägliches Scrum (oder Stand-up)

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

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

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

Sprint-Bewertung

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

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

💡 Erfahre mehr: Einführung in Sprint Reviews

Sprint-Rückblick

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

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

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

Fehler bei der agilen Sprint-Planung

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

Unrealistische Erwartungen

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

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

Fehlender Kontext

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

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

Vernachlässigen Sie Ihren Backlog

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

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

Ein gut verwaltetes Backlog ist TIEF:

• Angemessen detailliert
• Geschätzt
• Aufstrebend
• Priorisiert

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

Keine Anpassung des Plans

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

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

Stakeholder nicht verstehen

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

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

Wählen Sie keine Tools mit einem kundenorientierten Ansatz

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

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

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

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

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

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

Virtuelle oder persönliche Sprint-Planung

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

Tipps für die virtuelle Sprint-Planung:

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

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

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

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

Zusätzliche agile Ressourcen

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

📚 Füge diese zu deiner Liste hinzu:

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

Verwenden von Easy Agile zur Verbesserung der Sprint-Planung

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

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

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

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

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

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.

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!