Einführung in das Produkt-Backlog

Sobald du dir über die Ergebnisse im Klaren bist, kann das Team zusammenkommen und auf taktischer Ebene über die Produktideen nachdenken, die bei der Umsetzung helfen werden. Der erste Schritt auf dem Weg dorthin ist die Erstellung eines Produkt-Backlogs.

Bei unserer Arbeit hatten wir oft mit Produktteams zu tun, die ein einziges Jira-Backlog verwendet haben, um alles zu erfassen: Funktionsanfragen, kleine und große Möglichkeiten, Tasks und Sub-Tasks, Bugs und dringende Vorgänge und Ideen für die Zukunft des Produkts.

Ausnahmslos alle erzählten uns dieselbe Geschichte. Das Backlog gerät außer Kontrolle, die Ticketliste wird immer länger und verursacht Angst und Sorgen. Diese unorganisierten, überwältigenden Backlogs lassen auf keiner Ebene eine Priorisierung zu, von taktischen Änderungen bis hin zu großen Neuinvestitionen.

Am Ende haben die Teams diese Diskussionen in Tabellen verschoben, aber in jedem Quartal passierte immer dasselbe: Einblicke gingen verloren, Entscheidungen wurden nicht aufgezeichnet und Ressourcen wurden unter Zeitdruck zugewiesen, basierend auf Bauchgefühl oder starken Meinungen.

Es gibt einen besseren Weg: ein spezielles Produkt-Backlog, das um Ergebnisse herum aufgebaut ist und sich vom Umsetzungs-Backlog für die tägliche Arbeit unterscheidet.

Was ist ein Produkt-Backlog?

Im Produkt-Backlog werden Ideen entwickelt, priorisiert und in Roadmaps geteilt, die mit Ergebnissen und Zielen verknüpft sind. Es enthält alle Produktideen, Einblicke, Möglichkeiten und Lösungen und gehört dem Produktteam. Hier wird nicht die Ausführung bestimmter Aufgaben geplant. Vielmehr ist es ein Ort für die Diskussion "In was sollten wir investieren und warum?". Stakeholder des gesamten Unternehmens können zu diesem Backlog eingeladen werden, um gemeinsam an Prioritäten und Roadmaps zu arbeiten und den Fortschritt laufender Produktinitiativen auf hoher Ebene zu besprechen.

Stell dir das Produkt-Backlog als Zuhause für das Produktteam vor, das mit Mitarbeitern aus dem gesamten Unternehmen geteilt wird. Es ist ein ausgewiesener Bereich für alles, was verfolgt werden soll – von vagen Ideen bis hin zu voll ausgearbeiteten Möglichkeiten. Im Laufe der Zeit erfolgen Verfeinerungen basierend auf Erkenntnissen, Kundenfeedback oder sich ändernden übergeordneten Zielen.

Produkt-Backlog im Vergleich zum Umsetzungs-Backlog

Das Produkt-Backlog und das Umsetzungs-Backlog sind separate Dinge, die jeweils einem bestimmten Zweck dienen. 

Im Umsetzungs-Backlog werden Umsetzungsarbeiten verwaltet, Umsetzungspläne erstellt und Fortschritte verfolgt. Es enthält die Aufschlüsselung der Aufgaben (Epics, Storys, Aufgaben und Unteraufgaben) zur Erfüllung von Verpflichtungen und gehört dem Entwicklerteam. Hier trifft sich das gesamte Team und arbeitet zusammen, um Fragen zur Umsetzung zu klären: Sequenzierung, Abhängigkeiten, Kapazitäten, technische Meilensteine.

Natürlich sind die Produkt- und Umsetzungs-Backlogs eng miteinander verknüpft. Die Arbeit im Umsetzungs-Backlog führt zu Ideen im Produkt-Backlog, die wiederum mit den gewünschten Ergebnissen verbunden sind. Das gibt Führungskräften, Managern und Entwicklern einen Überblick darüber, wie das Team auf Ergebnisse hinarbeitet und sich dabei durch die Zyklen der Ideenfindung und Umsetzung iteriert.

Im Gegensatz zum Produkt-Backlog sind alle Artikel im Umsetzungs-Backlog als konkrete Pläne gedacht, die irgendwann abgeschlossen werden sollen. Das Produkt-Backlog dagegen dient neben der Planung auch der Ideenfindung und dem Brainstorming. Manche Produktideen werden niemals priorisiert werden und schaffen es nicht auf die Roadmap. Das ist völlig in Ordnung.  

Indem Teams übergeordnete Produktanliegen von der Umsetzungsplanung und -verfolgung trennen, können sie effektiver Prioritäten setzen, Arbeit mit Ergebnissen verknüpfen und außer Kontrolle geratene Backlogs vermeiden, die es allen recht machen wollen.

Vorteile eines Produkt-Backlogs

Separate Backlogs für Produkt und Umsetzung bieten viele Vorteile:

• Einen sicheren Ort für das Produktteam, um potenzielle Ideen zusammen mit den verfügbaren Daten zu besprechen, ohne sich Gedanken über Machbarkeit oder Definition machen zu müssen. 

• Sämtliche Produktdiskussionen finden an einem Ort statt und Teams können im Laufe der Zeit Wissen aufbauen, ohne Dutzende von Tabellen durchsuchen zu müssen.

• Eine gemeinsame Informationsquelle und ein gemeinsames Verständnis der Produktprioritäten. Das bekämpft ein Problem, mit dem Produktteams oft konfrontiert sind: Entscheidungen nach dem Bauchgefühl oder der lautesten Kunden- und Stakeholderstimmen zu treffen. 

• Transparenz bei der Diskussion um die Priorisierung, da Mitarbeiter des gesamten Unternehmens in einem gemeinsamen Bereich zusammenkommen. Das beseitigt viel Reibung bei der Zusammenarbeit mit Stakeholdern und Teams mit Kundenkontakt.

• Durch die Verbindung zur Umsetzungsarbeit veralten Roadmaps nicht und sie bleiben ehrlich, da Einschränkungen bei der Umsetzung berücksichtigt werden.

Den Produkt-Backlog organisieren

Ideen, Möglichkeiten, Probleme, Lösungen: Das Produktteam muss darüber entscheiden, was in den Produkt-Backlog aufgenommen werden soll. Es sollten die Dinge sein, die priorisiert werden sollen und es sollte dargestellt werden, wie das Team über Produktinvestitionen und Prioritäten denkt.

Es ist sehr wichtig, dass das Produktteam den Inhalt und die Struktur zur Kategorisierung und Priorisierung des Produkt-Backlogs kontrolliert. Andernfalls riskiert man, dass das Backlog in die Unübersichtlichkeit abdriftet, die eigentlich verhindert werden sollte.

Externe Stakeholder sollten eingeladen werden, um das Backlog zu kontrollieren. Sie sollten nur vordefinierte Beiträge leisten und keine Elemente erstellen oder bearbeiten können. Diese Beiträge könnten zum Beispiel Kommentare sein, Abstimmungen über Ideen oder das Taggen von Kunden, die eine Funktion angefordert haben.

Zwei empfohlene Frameworks für die Strukturierung eines Produkt-Backlogs sind unten aufgeführt: Felsbrocken, Steine und Kieselsteine sowie lange, mittlere und kurze Listen. Wir empfehlen, das Produkt-Backlog nach diesen drei Bereichen und diesen Aktivitäten zu organisieren.

In Jira Product Discovery erfolgt dies durch die Konfiguration bestimmter Ansichten, um die richtigen Ideen anzuzeigen, und der Auswahl der angezeigten Felder, um die Diskussion zu unterstützen (Auswahl, Bewertung) und zur Zusammenarbeit einzuladen (Einblicke, Abstimmung, Kommentare, Reaktionen).

Felsbrocken, Steine und Kieselsteine

Viele Produktteams haben nur einen Objekttyp: „Idee“. Aber das Backlog kann Elemente mit unterschiedlicher Form, Größe und Granularität enthalten, von großen neuen Vorhaben bis hin zu kleinen Produktverbesserungen. 

Eine gängige Praxis ist es, ein Backlog mit drei Kategorien von Elementen zu strukturieren: 

• Boulders (Felsbrocken): große Investitionen, strategische Möglichkeiten und große neue Vorhaben

• Rocks (Steine): mittlere Investitionen, substanzielle Produktverbesserungen, die zu Ergebnissen führen

• Pebbles (Kieselsteine): kleine Investitionen, wie das Beheben einfacher Bugs und UX-Probleme

Am besten richtet man hierfür im Produkt-Backlog separate Bereiche ein und denkt darüber nach, die Investitionen auf die drei Bereiche zu verteilen, wobei für jeden Bereich ein Platz in Budget und Roadmap reserviert werden sollte. Insbesondere Kieselsteine lassen sich ohne diese Art von Intentionalität nur schwer priorisieren. Ein großes neues Vorhaben ist aufregend, aber die negativen Auswirkungen von Kleinigkeiten auf das Benutzererlebnis häufen sich mit der Zeit an. 

Weitere Informationen zu diesem Framework findest du im Abschnitt Ideen.

Lange Liste, mittlere Liste und kurze Liste

Eine weitere einfache, pragmatische Strukturierungsmethode für ein Produkt-Backlog stammt von Brent Johnson, einem der ersten Anwender von Jira Product Discovery. Brent beschrieb Produktarbeit als die ständige Arbeit mit 3 Bereichen: der langen Liste, der mittleren Liste und der kurzen Liste.

Das Produktteam verschiebt Ideen aus der langen, mittleren und kurzen Liste zum Produkt-Backlog und lädt Stakeholder aus dem gesamten Unternehmen zur Zusammenarbeit ein.

• Die lange Liste enthält alles: "Eines Tages vielleicht"-Ideen, Probleme, Möglichkeiten oder Lösungen. Es können über 200 Ideen auf dieser Liste stehen. 

  • Das Produktteam kuratiert diese lange Liste und nutzt sein Wissen über den Markt, strategische und betriebliche Belange sowie Kunden- und Geschäftsanforderungen, um daraus eine mittlere Liste zu machen.

• Die mittlere Liste ist eine Vorauswahl potenzieller Prioritäten: attraktive Möglichkeiten, in die das Team legitim investieren könnte. Aus einer langen Liste von 200 Ideen schaffen es vielleicht 10 bis 20 auf die mittlere Liste.

  • Das sind die Ideen, die wie gute Vorhaben aussehen, weil sie strategisch wichtig sind, häufig in Kundengesprächen auftauchen oder großes Potenzial haben, Benutzer zu begeistern. Sie müssen zu einer kurzen Liste priorisiert werden, in der Regel mit Beiträgen verschiedener Stakeholder aus dem Unternehmen. 

    • Weitere Informationen findest du unter Priorisierung.

• Die kurze Liste ist im Grunde die Produkt-Roadmap: Ideen, deren weitere Entwicklung das Produktteam beschlossen hat. Diese Aufgaben setzen Möglichkeiten, Probleme oder Lösungen in die Tat um, um ein Produkterlebnis zu schaffen oder ein bestehendes zu verbessern. 

  • Das Team überprüft diese Liste regelmäßig auf der Grundlage dessen, was es gelernt hat, und hält sie auf dem neuesten Stand. Von dieser Liste kann der Rest des Unternehmens am häufigsten eine Aktualisierung erwarten.

    • Weitere Informationen findest du unter Roadmapping.

In Jira Product Discovery ein Produkt-Backlog erstellen

Wir haben Jira Product Discovery geschaffen, um Produktteams einen Ort zu bieten, an dem sie ihre Ideen sammeln, sie gemeinsam bearbeiten und Prioritäten setzen können. In Jira Product Discovery kannst du ein oder mehrere Produkt-Backlogs erstellen, sogenannte "Discovery-Projekte". 

Im Allgemeinen ist es am besten, Personen, die täglich zusammenarbeiten, demselben Projekt zuzuweisen (z. B. ein Team oder mehrere Teams). Einige Jira Product Discovery-Kunden verwenden jedoch ein einziges Projekt für mehrere Teams und Produkte. Das ist besonders nützlich, wenn ein hohes Maß an Zusammenarbeit zwischen diesen Teams erforderlich ist.

In dieser Demo erfährst du, wie das funktioniert:

Mit dem Jira Product Discovery Premium-Tarif kannst du Ideen aus mehreren Projekten an einem zentralen Ort visualisieren. Dazu erstellst du Ansichten, die Ideen aus mehreren Projekten enthalten und eine Übersicht der Produktpläne einer Organisation bieten.

Was kommt als Nächstes?

Im restlichen Teil dieses Handbuchs erklären wir im Detail, wie ein Produkt-Backlog für Folgendes verwendet wird:

• Ideen vom Grundgedanken bis zur Umsetzung führen

• Feedback-Kanäle einrichten und Einblicke erfassen, um Ideen zu validieren

• Priorisierung der Ideen, die etwas bewegen

• Erstellung von Roadmaps, an denen sich dein Team und deine Stakeholder orientieren können

Wir geben dir Beispiele dafür, wie wir das im Jira Product Discovery-Team mit Jira Product Discovery und anderen Produkten machen.