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

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.

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!

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.