Keine Artikel gefunden.

Verwenden Sie ein Sprint-Burndown-Diagramm, um Ihr Produkt auf Kurs zu halten

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

Die Stakeholder auf dem Laufenden zu halten, ist eine der Hauptaufgaben eines Product Owners. Hinter den Kulissen wird eine Menge Arbeit geleistet, bevor den Stakeholdern Informationen über die Ergebnisse und den Zeitplan eines Produkts präsentiert werden können. Wenn Sprints Ihr Framework für die Erledigung der Arbeit und die Prognose von Lieferterminen sind, muss das agile Entwicklungsteam sicherstellen, dass es den Produkt-Backlog im richtigen Tempo abarbeitet. Das Sprint-Burndown-Diagramm kann Ihnen den Weg weisen.

In diesem Beitrag werden wir darüber sprechen, wie Sie anhand eines Sprint-Burndown-Diagramms überwachen können, ob Ihr Team auf dem richtigen Weg ist, seine Arbeit abzuschließen, und wie die Einbindung von User Stories in Sprints und Epics mithilfe von User Story Maps zu noch besseren Erkenntnissen führt.

Was ist ein Sprint-Burndown-Diagramm?

screenshot of sprint burndown chart

Bildquelle: Atlassian

Zuerst eine Bewertung: A Sprint ist ein fester Zeitraum — in der Regel zwischen zwei und vier Wochen —, den ein agiles Softwareentwicklungsteam verwendet, um eine definierte Reihe von Arbeiten abzuschließen.

Ein Sprint-Burndown-Diagramm ist ein visueller Vergleich, wie viel Arbeit während eines Sprints abgeschlossen wurde und wie viel Arbeit insgesamt noch übrig ist. Es hilft dabei, den Fortschritt eines Scrum-Teams zu messen, und es bietet einen einfachen Überblick darüber, ob das Team Anpassungen vornehmen muss, um seine Arbeit für die aktuelle Sprint-Iteration abzuschließen.

Ein Burndown-Diagramm ist ein Graph mit einer Y-Achse und einer X-Achse 📉. Die vertikale Achse misst den Gesamtaufwand an Arbeit, den das Team nach Schätzungen im aktuellen Sprint erledigen wird. Die horizontale Achse zeigt die Anzahl der verbleibenden Tage bis zum Ende des Sprints. Auf dem Diagramm befinden sich zwei Linien: die tatsächliche Arbeitslinie (eine Linie, die den Fortschritt des Teams darstellt) und die ideale Arbeitslinie (eine gerade Linie vom oberen Ende der Y-Achse bis zum Ende der X-Achse).

Sie möchten, dass Ihre tatsächliche Arbeitslinie Ihrer idealen Arbeitslinie so genau wie möglich folgt. Das würde bedeuten, dass die Arbeit schrittweise und mit einer solchen Geschwindigkeit abgeschlossen wird, dass sie bis zum Ende des Sprints abgeschlossen werden kann. Sprintziel erreicht. 👍

Für den Product Owner eines Teams empfiehlt es sich, das Burndown-Diagramm täglich zu überprüfen. Auf diese Weise können Sie feststellen, ob während des Sprints Fortschrittsprobleme auftreten. Wenn Ihre tatsächliche Arbeitslinie beispielsweise tendenziell über der idealen Arbeitslinie liegt, bleibt zu viel Arbeit übrig, um bis zum Ende des Sprints im aktuellen Tempo erledigt zu werden. Wir werden später in diesem Beitrag einige Gründe aufschlüsseln, warum das passieren könnte. 😉

Das Sprint-Burndown-Diagramm ist auch ein großartiges Tool für die Verwendung während einer Sprint-Rückblick. Wenn man das als Team betrachtet, kann das helfen, Diskussionspunkte zu den drei wichtigsten Fragen der Sprint-Retrospektive zu generieren: Was lief im Sprint gut? Was lief nicht so gut, wie wir es uns erhofft hatten? Wie können wir im nächsten Sprint besser werden?

Eine Einführung in Schätzmethoden

sprint burndown chart: group of people discussing something

Um den Kraftaufwand auf der vertikalen Achse zu messen, müssen wir eine Metrik wählen.

In der Vergangenheit nutzten traditionelle Softwareteams Zeit, um den Aufwand abzuschätzen, der für die Fertigstellung einer Aufgabe oder eines Projekts erforderlich war. Zum Beispiel: „Ich denke, ich werde drei Tage brauchen, um diese User Story fertigzustellen.“ Dieser Ansatz kann jedoch riskant sein, weil Menschen neigen dazu, zu unterschätzen die Zeit, die benötigt wird, um ein Projekt abzuschließen.

Die Maßeinheit auf der Y-Achse Ihres Sprint-Burndown-Diagramms hängt von Ihrem ab Schätzungsmetrik nach Wahl. Sehen wir uns zwei gängige Methoden an, die von agilen Sprint-Teams eingesetzt werden.

Ideale Tage

Ein idealer Tag ist eine Schätzung eines Softwareentwicklers, wie viele ununterbrochene Tage es dauern wird, eine Aufgabe zu erledigen. Unter der Annahme, dass ein idealer Arbeitstag aus acht Stunden unterbrechungsfreier Arbeit besteht, könnte die Schätzung wie folgt ausgedrückt werden: „Für diese Benutzergeschichte brauche ich idealerweise zwei Tage.“ Ein Vorteil dieses Ansatzes besteht darin, dass Arbeitsunterbrechungen berücksichtigt werden. Er kann jedoch problematisch sein, da Schätzungen häufig als Best-Case-Szenarien betrachtet werden.

Story-Punkte

Agile Teams nutzen Storypoints als relative Schätzung des Aufwands im Gegensatz zu einem zeitbasierten Ansatz. Anstatt zu sagen: „Ich glaube, ich werde zwei Tage brauchen, um diese Aufgabe zu erledigen“, würden Sie sagen: „Ich denke, diese Aufgabe ist zwei Storypoints wert.“ Bei dieser Schätzmethode sind zwei Storypoints doppelt so viel Aufwand wie ein Storypoint.

Teams können ideale Tage als Grundlage verwenden, um ihre Story-Point-Schätzungen zu kalibrieren. Ein idealer Tag kann beispielsweise einem Story Point entsprechen, zwei ideale Tage zwei Story Points usw.

Ein Hauptvorteil der Verwendung Storypoints Eine Schätzung bedeutet, dass Teams sich so auf den relativen Aufwand konzentrieren können, anstatt darüber nachzudenken, wie lange es dauern wird, eine Aufgabe zu erledigen.

Warum dein Sprint-Burndown aus dem Ruder laufen könnte

woman looking at sticky notes posted on the glass wall

Eine perfekte echte Burndown-Linie ist wie Bigfoot — wenn sie beobachtet wurde, ist es wahrscheinlich ein Scherz. 😂

Kein Team kann seine Arbeit perfekt einschätzen und sich genau in dem Tempo entwickeln, das die Ideallinie vorgibt. Wenn Sie jedoch große Unterschiede zwischen Ihrer tatsächlichen Linie und der Ideallinie feststellen (d. h., Ihre tatsächliche Linie ist viel höher oder niedriger als die Ideallinie), können eine Reihe von Dingen passieren:

  • Das Team hat sich zu viel oder zu wenig mit dem Arbeitsaufwand bei der Sprint-Planung beschäftigt
  • Story Points wurden dem Sprint hinzugefügt oder daraus entfernt, nachdem er gestartet wurde (Scope Creep)
  • Der geschätzte Aufwand für einige User Stories ist falsch

Wenn Sie als Product Owner nach Ihrer täglichen Überprüfung Ihres Diagramms feststellen, dass etwas an Ihrer Linie nicht stimmt, sollten Sie dies Ihren Teammitgliedern gegenüber erwähnen. Das tägliche Stand-up ist der perfekte Zeitpunkt dafür.

User Stories und Epen liefern das große Ganze

Geschichten von Nutzern beschreiben, wie ein funktionaler Teil eines Produkts aus der Sicht eines Benutzers funktionieren wird. Das übliche Format einer User Story lautet: „Als [Benutzerrolle] möchte ich [Benutzeraktivität], damit ich [Benutzerziele] erreichen kann.“ Zum Beispiel könnte man lesen: „Als neuer Kunde möchte ich mich für dieses Produkt registrieren, damit ich mein Profil erstellen kann.“

User Stories werden in Sprints platziert, um zu zeigen, welche Arbeiten (aus Nutzersicht) bis wann abgeschlossen sein werden. Sie können auch platziert werden Epen um sie innerhalb eines Produkts nach Themen zu gruppieren. Epics werden häufig von agilen Teams verwendet, um die Aktivitäten auf hohem Niveau darzustellen, die Benutzer bei der Verwendung eines Produkts ausführen.

In unserem Beispiel oben kann ein Epic alle Nutzerberichte erfassen, die sich auf die Benutzerregistrierung beziehen, z. B. die Registrierung, das Hinzufügen von Zahlungsinformationen, das Erstellen eines Benutzerprofils und das Konfigurieren von Benachrichtigungseinstellungen.

Wenn der Sprint-Burndown darauf hindeutet, dass das Team bei einem bestimmten Sprint nicht auf der Strecke ist, kann dir eine kombinierte Ansicht von Sprints und Epen dabei helfen, herauszufinden, welche Auswirkungen das auf das Gesamtbild haben könnte. Und wie wir als Nächstes sehen werden, kann eine interaktive User Story Map das Problem lösen.

User Story Maps: Ein Überblick über Epen und Sprints

screenshot of story map by Easy Agile

Ein Sprint-Burndown-Diagramm ist eines der praktischsten Tools, die ein agiles Softwareentwicklungsteam verwenden kann, um sicherzustellen, dass es in einem soliden Tempo arbeitet und liefert. Das Burndown-Diagramm zeigt, ob Anpassungen an Ihrem Sprint vorgenommen werden müssen.

User-Story-Maps bieten weitere Einblicke in den Teamfortschritt, indem Sie:

  • Sprints als vertikale Schwimmbahnen anzeigen
  • Anzeige von Epen als Spalten, die die Benutzerreise durch das Produkt darstellen

Diese Kombination aus Swimlanes und Columns verringert deinen Sprint-Backlog. Es visualisiert, was das Team liefern wird und bis wann.

Mit Einfache Agile User Story Maps für Jira, kannst du deine Fähigkeit verbessern, Anpassungen an deinem Sprint vorzunehmen. Es kann dir helfen:

  • Neue User Stories erstellen
  • Story Points in einer User Story bearbeiten
  • Ordne Gegenstände im Backlog einem Epic und einem Sprint zu

Mit diesem Tool können Teams ihre Sprint-Statistiken auf einen Blick einsehen und Maßnahmen ergreifen. Sie können sicherstellen, dass sie sich nicht zu sehr verpflichten und dass sie auf dem richtigen Weg sind, ihre Sprintziele zu erreichen. Es ist die umfassendste User-Story-Map-Lösung der Jira-Marktplatz dafür, dass Sie Maßnahmen ergriffen haben, um Ihre Sprints aus der Sicht des Gesamtbildes anzupassen.

Keine Artikel gefunden.

Verwandte Artikel

  • Workflow

    Bringen Sie eine Produkteinführung mit Ihrem Produktmanagement-Framework zum Erfolg

    Die perfekte Produkteinführung ist ein schwer fassbares Biest. Wenn der Starttermin näher rückt, steigt der Druck, während sich der Produktmanager mit Änderungen in letzter Minute, Bugs auf dem Jira-Board und einigen Netzwerk- oder Serverproblemen befasst, die alles zu ruinieren drohen. Sie haben vielleicht das perfekte Produktmanagement-Framework, doch die Reise zur Ziellinie ist normalerweise alles andere als elegant.

    Egal, ob Sie ein neues Produkt auf den Markt bringen oder ein neues Feature veröffentlichen, Produktmanager leben von der Aufregung, dem Hochgefühl — und der Erschöpfung! — die mit dem Job einhergehen, insbesondere im Zusammenhang mit wichtigen Veröffentlichungen. Selbst bei sorgfältiger Planung, einer exquisiten Produkt-Roadmap und einem sorgfältig verfeinerten Backlog scheinen die letzten Momente vor der Markteinführung immer in einem Kampf bis zum Ende zu enden.

    Bevor Sie Ihrem Produktmanagement-Framework oder, schlimmer noch, Ihrem Produktteam die Schuld geben (Nee, das würden Sie niemals tun!) , treten Sie einen Schritt zurück und atmen Sie ein. Wir stellen Ihnen einige Ideen vor, wie Sie das Chaos am Tag der Markteinführung etwas lindern können. (Seien wir ehrlich, kein Drama am Tag der Veröffentlichung wäre nur ein bisschen enttäuschend.)

    Planung vor dem Start

    product management framework: woman showing sticky notes to her co workers

    Wenn Sie eine agile Produktentwicklungsmethode wie Scrum oder Kanban verwenden, sind Sie in Bezug auf die Planung bereits einen Schritt voraus. Erfahrene PMs verfügen über eine Roadmap mit Epen in T-Shirt-Größe und Geschichten, die sorgfältig unter Verwendung etablierter Methoden entworfen wurden Methoden zur Priorisierung.

    Basierend auf Ihrer Produktstrategie können Sie sich dafür entscheiden, nach jeder Iteration neue Produktfunktionen für die Produktion freizugeben. Aber manchmal erfordert der Produktmarketingplan einen größeren Aufschwung. In diesem Fall können Sie Pressemitteilungen, große Werbeveranstaltungen oder andere Marketingmöglichkeiten mit hoher Sichtbarkeit nutzen.

    Die Planung, wie Sie das Produkt veröffentlichen möchten, ist genauso wichtig wie die Entscheidung, was Teil der Veröffentlichung sein wird. Die Produktentwicklungsteams müssen sich mit dem Produktmarketing abstimmen, um Folgendes zu berücksichtigen:

    • Wirst du einen Soft-Launch für ein begrenztes Publikum durchführen?
    • Müssen Sie bestimmte Komponenten vorab veröffentlichen, um Preise, Marketingtexte oder Benutzerfreundlichkeit zu testen?
    • Wirst du die Vorveröffentlichungen bis zur Veröffentlichung in der Wildnis lassen oder testest du sie für einen bestimmten Zeitraum und ziehst sie dann zurück?
    • Haben Sie ein festes Datum, an dem Sie die Veröffentlichung vornehmen müssen (z. B. Super Bowl-Sonntag), oder gibt es eine gewisse Flexibilität beim Timing?

    Antworten auf diese Fragen bestimmen die Release-Strategie, die dann in Ihrem Release-Plan und Ihrer Ausführung berücksichtigt wird.

    Wenn es darum geht, zu entscheiden, welche Funktionen in Ihre Produkteinführung aufgenommen werden sollen, können Sie aus einer Vielzahl von Produktmanagement-Frameworks wählen oder einen hybriden Ansatz verwenden und die Methoden so kombinieren, dass sie zu Ihrer Situation passen.

    Das Modell Kano, AARRR Theorie (Akquisition, Aktivierung, Kundenbindung, Weiterempfehlung und Umsatz) und OKRs (Ziele und Hauptergebnisse) bieten alle Rahmenbedingungen für das Produktmanagement. Diese helfen Produktverantwortlichen bei der Planung neuer Funktionen, die auf die Produktvision abgestimmt sind, und bei der Umsetzung der Rentabilitätsziele.

    Denken Sie daran: Es ist immer eine gute Idee, einen Plan B oder sogar einen Plan C zu haben, um unerwartete Ereignisse oder Probleme zu berücksichtigen, die häufig kurz vor einer Markteinführung auftauchen. Atlassian hat eine großartige Vorlage für die Produkteinführung um dir den Einstieg zu erleichtern, wenn du an deinem ersten Release arbeitest.

    Planung des Starttages

    Eine Checkliste für den Launch-Tag ist dein bester Freund am Tag der Markteinführung. Vielleicht möchtest oder brauchst du sogar mehr als eine Liste. Eine Produkteinführung hat zu viele bewegliche Teile in zu vielen Teams, als dass Sie sich allein auf das Gedächtnis verlassen könnten. Ihre Marketing-, IT- und Produktteams spielen alle eine Rolle bei der Markteinführung und führen die für ihre Aufgaben erforderlichen Aktivitäten durch.

    Vor allem, wenn dies die erste Produkteinführung in Ihrem Startup sein könnte, helfen Checklisten den Produktteams dabei, Details lange vor dem Launch-Tag mit klarem Kopf zu durchdenken. Der beste Plan ist, jedes Team zu bitten, seine Checkliste zu erstellen, und sich dann als Gruppe zu treffen, um den Zeitplan der einzelnen Aufgaben abzustimmen und zu koordinieren. Einige Aufgaben am Tag der Markteinführung sind unabhängig voneinander und können jederzeit in Angriff genommen werden. Im Gegensatz dazu sind andere zeitkritischer oder hängen davon ab, dass etwas anderes passiert.

    Für Teams, die bereits einige Markteinführungen hinter sich haben, enthalten diese Checklisten die Lehren aus früheren Versionen. Wenn sie nach jeder Markteinführung aktualisiert werden, verwandeln sie Ihr Team in eine reibungslose Maschine zur Produkteinführung.

    Planung nach der Markteinführung

    Wie Sie wissen, ist eine Produkteinführung nicht das Endspiel. Sobald sich der Staub gelegt hat und alle etwas geschlafen haben, müssen Sie messen, wie das Produkt funktioniert. Wenn Sie planen, wie die ersten Kennzahlen des Produkts gemessen werden sollen, können Produktmanager die Ergebnisse frühzeitig und so oft wie nötig an die Stakeholder weitergeben.

    Die Messung wichtiger Produktkennzahlen nach einer Markteinführung bestätigt Ihre Entscheidung über die Produktfunktionen, bestätigt, dass Sie das richtige Produkt für den Markt entwickelt haben, und hilft Ihnen, die richtigen Fragen zu stellen und zu beantworten, wenn Sie weitere Feature-Builds und Marketingstrategien planen.

    Wichtige Produktindikatoren nach der Markteinführung können den Gesamtumsatz, die wichtigsten Attributionskanäle, Aktivierungsstatistiken und Affinitätsverkäufe umfassen. Wenn Sie eine neue Funktion in einem bestehenden Produkt einführen, sollten Sie auch die Kundenbindungszahlen im Auge behalten. Ein Anstieg der Abwanderungsraten könnte auf ein Problem mit der Benutzererfahrung oder der zugrunde liegenden Technologielösung hinweisen.

    Sie müssen nicht nur die Ergebnisse Ihrer Veröffentlichung messen, sondern auch die nächsten Schritte vorbereiten. Nachdem Ihr Entwicklungsteam ein wenig die Augen geschlossen hat, macht es sich wieder an die Arbeit und sucht nach seinem nächsten Auftrag. Sie benötigen Ihre Rückstand bereit für die nächste Sprint-Planungszeremonie, und dann geht es wieder wie gewohnt weiter. Möglicherweise gibt es auch sofortiges Kundenfeedback, das umgesetzt werden muss.

    Sobald du dein Team auf den Weg zum nächsten Release gebracht hast, ist es an der Zeit, einen Blick auf deine Roadmap zu werfen. Sie werden wahrscheinlich neue Informationen entdecken, wenn Kunden anfangen, Ihr neues Produkt oder Ihre neue Funktion zu nutzen. Es ist eine gute Idee, in der Roadmap etwas Platz zu lassen, um Arbeiten zu übernehmen, die in den ersten Wochen Ihrer Markteinführung entdeckt wurden.

    Dann gibt es noch eine letzte Sache — FEIERN!! Sie und Ihr Team haben hart gearbeitet und etwas wirklich Cooles erreicht! Es ist leicht, sich auf dem Weg zur nächsten Veröffentlichung in den Alltagstrott zu verwickeln. Nehmen Sie sich etwas Zeit, um sich selbst für eine gut gemachte Arbeit auf die Schulter zu klopfen.

    Nutzen Sie Ihr Produktmanagement-Framework, um den Launch-Tag wie ein Rockstar anzugehen

    Mit etwas Planung und Flexibilität können Sie Ihr Produktteam so zusammenstellen, dass der Tag der Markteinführung wie ein Spaziergang im Park aussieht. Und je eher du darin gut wirst, desto besser. Sie werden während des gesamten Produktlebenszyklus immer etwas auf den Markt bringen, vom ersten MVP über neue Funktionen bis hin zum Ende des Produktlebenszyklus.

    Gründlich Straßenkartierung bietet Ihnen einen soliden Start, und je näher Sie dem Starttag kommen, desto mehr wichtige Details werden Sie herausfinden, um sicherzustellen, dass Sie nichts verpassen. Teamübergreifende Koordination ist unerlässlich, und Checklisten helfen dabei, Kommunikationskanäle zu öffnen und das gesamte Team auf den gleichen Stand zu bringen.

    Eine frühzeitige Berichterstattung über Ergebnisse schafft Vertrauen bei den Stakeholdern und ist auch eine hervorragende Möglichkeit, Ihrem Team die Ergebnisse seiner Bemühungen zu zeigen.

    Genießen Sie den Adrenalinrausch am Tag der Markteinführung, aber versuchen Sie, ein wenig vom Chaos und Stress abzuschalten. Sobald Sie gestartet sind, ist es Zeit, mit der nächsten Sache fortzufahren. Das liegt in der Natur der Produktentwicklung, und deshalb lieben wir sie.

  • Agile Best Practice

    DEEP: Die 4 Merkmale eines guten Produkt-Backlogs

    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.