3 Beispiele für ein gelungenes Product Backlog (+ Was man vermeiden sollte)
Haben Sie schon einmal auf Ihr Backlog geschaut und sich gewünscht, alles zu löschen und von vorn zu beginnen? Nun, dieses Gefühl kenne ich nur zu gut, denn das Erstellen und Pflegen von Produkt-Backlogs ist keine leichte Aufgabe. Damit Sie sehen, wie Backlogs richtig gemacht werden und Sie motiviert werden, Ihr eigenes aufzuräumen, möchte ich vier außergewöhnliche Beispiele für Produkt-Backlogs mit Ihnen teilen.
Worum geht es beim Product Backlog in Agile und Scrum?
Das Product Backlog ist ein lebendes Dokument, das alle Punkte enthält, an denen das Produktteam, der Scrum Master und das Entwicklerteam arbeiten möchten, um ihr Produkt zu bauen.
Es beinhaltet alles, was Sie benötigen, um Ihr Produkt zu entwickeln und zu pflegen – darunter neue Features, Aufgaben im Zusammenhang mit technischer Schuld, technische Prozessverbesserungen aus Ihrem letzten Retrospektive, Aufgaben für die Testautomatisierung und mehr.
Du willst mehr vom The CPO Club?
Registriere dich für eine kostenlose Mitgliedschaft, um diesen Artikel vollständig zu lesen:
Have an account? Log In
Das zentrale Merkmal eines Product Backlogs ist, dass es sich um eine priorisierte Liste handelt, bei der die obersten Einträge die höchste Priorität haben und vom Team als Erstes bearbeitet werden sollten – entweder bei der Sprint-Planung oder wenn auf dem Kanban-Board Platz frei ist.
Product Backlog vs. Sprint Backlog vs. Product Roadmap: Wo liegen die Unterschiede?
Im agilen Projektmanagement und speziell in der Scrum-Methodik ist das Product Backlog nicht die einzige Liste mit Aufgaben, die der Product Owner für Ihr Entwicklungsteam erstellt. Es gibt außerdem das Sprint Backlog und die Product Roadmap. Doch worin unterscheiden sie sich? Finden wir es heraus.
Sprint Backlog: Dies ist eine Teilmenge des übergeordneten Backlogs und enthält nur jene Punkte, die das Scrum-Team in den nächsten Sprint oder eine andere Iteration nach einem Sprint Planning Meeting aufgenommen hat. Die Einträge hier sind in der Regel gut aufbereitet und enthalten Story Points.
Product Roadmap: Dies ist ein strategisches Dokument auf hoher Ebene, das die wichtigsten Features und Meilensteine für das Produkt darstellt. Im Gegensatz zum Backlog, das eher taktisch ist und genaue Feature-Beschreibungen enthält, dient die Product Roadmap dazu, den Teammitgliedern und Stakeholdern aufzuzeigen, wohin das Produkt steuert und welche Bereiche aktuell im Fokus stehen.
Nachdem Sie und die wichtigsten Begriffe nun ordentlich eingeführt wurden, springe ich direkt dazu, zu erklären, wie Sie Ihr Product Backlog (und wie Sie es, äh, besser nicht machen) managen.
Wie man es NICHT richtig macht: Ein erschreckendes Produkt-Backlog-Beispiel
Die Anti-Patterns beim Erstellen und Pflegen von Produkt-Backlogs zu verstehen, ist vermutlich genauso wichtig wie das Erlernen der Best Practices. Der Grund: Wenn Sie nicht wissen, dass etwas ein Anti-Pattern ist, riskieren Sie, es in Ihrem Backlog aufzunehmen und es für normal und alltäglich zu halten.
Um ein paar der Praktiken durchzugehen, die die Qualität Ihres Backlogs stark beeinträchtigen können, schauen wir uns folgendes Beispiel an.
Zurück zum Beispiel. Bitte nehmen Sie sich Zeit, es genau zu untersuchen.
Sieht furchtbar aus, oder? Tatsächlich empfinden die meisten von uns beim Anblick dieses Backlogs gleich zwei Dinge:
- Ekel angesichts des Chaos in diesem Backlog.
- Schuldgefühl, denn seien wir ehrlich: Jede:r von uns hatte schon einmal ein Backlog, das so aussah (ich natürlich auch).
Gehen wir nun die Probleme durch, die in diesem Backlog zu finden sind.
Überfrachtung mit Product-Backlog-Einträgen
Ist Ihnen aufgefallen, dass dieses Backlog 665 Einträge hatte? Nun, das größte Backlog, das ich jemals „freudig" verwalten durfte, hatte über 2.500 Einträge.
Das Problem eines überladenen Backlogs ist, dass Sie sich so gut wie nie daran erinnern können, was jedes einzelne Item überhaupt ist und warum Sie es auf eine bestimmte Position/Priorität gesetzt haben. Da Sie oftmals nicht mehr wissen, worum es bei diesen Aufgaben geht, nehmen Sie sie selten mit in die nächste Verfeinerungssitzung, sprechen über Details oder planen sie für den anstehenden Sprint ein.
So landet man mit einem riesigen, unübersichtlichen Durcheinander, das sich ins Unendliche auftürmt.
Unzureichende Priorisierung des Backlogs
Ein weiteres Problem, das dir auf dieser Backlog-Liste vielleicht aufgefallen ist: Es befinden sich Arbeitspakete mit „Niedrigster“ und „Niedriger“ Priorität ganz oben—sogar über Elementen mit „Höchster“ Priorität.
Das ist ein typischer Fall dafür, dass dein Backlog nicht richtig priorisiert ist. Dafür kann es viele Gründe geben, aber am wahrscheinlichsten ist, dass du ein Element mit „Hoher“ Priorität durch das Verschieben weiter nach unten de-priorisiert hast, dabei aber vergessen hast, das Prioritätsfeld anzupassen.
Mangel an Details
Ist dir das Element aufgefallen: „Ich möchte nahtlose Integration mit allen sozialen Medien-Plattformen“? LOL. Das ist nicht einmal eine richtige User Story, wenn man den riesigen Umfang betrachtet, den sie abdeckt. Der Umfang ist so groß, dass du in der Praxis mehrere Epics daraus machen solltest, wobei jeder Epic die Stories für eine Social-Media-Plattform enthält.
Neben dem riesigen Umfang ist das Problem bei diesem Element (eigentlich bei jedem Eintrag in diesem Backlog) seine Unklarheit. User Stories sollen eine spezifische Benutzererfahrung und Handlung beschreiben.
Stell dir vor, du bringst diese Story ins Backlog-Grooming-Meeting mit deinem Agile-Team. Du würdest mit einer Flut von Fragen zu nahezu jedem Aspekt dieser Story konfrontiert.
„Was meinst du mit nahtlos?“ „Wie sieht die Integration aus?“ „Mit welchen sozialen Medien integrieren wir uns überhaupt?!“
„Ich will alles – und zwar sofort“
Ein weiteres Warnsignal, das dir im Backlog vielleicht aufgefallen ist: 70 % der dort gelisteten Einträge haben die Priorität „Höchste“. Das ist eine weitere Standardsituation, die entsteht, wenn du dich rein auf die Meinungen deiner Stakeholder bei der Priorisierung verlässt (und jeder Stakeholder seine Items für wichtig hält), ohne zu versuchen, sie objektiv zu bewerten und ihre Wichtigkeit mit den anderen zu vergleichen.
Jetzt, da wir geklärt haben, wie ein schlechtes Backlog aussieht, lass es uns verbessern und vier gute Backlog-Beispiele besprechen...damit du dein Backlog wieder großartig machen kannst.
3 Beispiele für richtig geführte Backlogs
Bevor ich dir diese Beispiele zeige, möchte ich eines klarstellen: Es gibt nicht DEN einen richtigen Weg, ein gutes Backlog zu erstellen. Das Erscheinungsbild deines Backlogs hängt von der Art deines Produkts, dem Reifegrad, der Größe deines Unternehmens/Teams usw. ab.
In der Realität ist ein großartiges Backlog eines, das Klarheit und Einigkeit bei allen Beteiligten darüber schafft, was aktuell und in naher Zukunft im Produkt ansteht.
Es gibt allerdings generische Methoden, mit denen du dein Backlog organisierter und für alle verständlicher machen kannst. Jedes der folgenden Beispiele stellt eine solche Best Practice dar.
Beispiel #1: Ein Backlog mit Abschnitten
Es ist fast nie in Ordnung, ein Backlog mit Hunderten oder Tausenden von Einträgen zu befüllen. Allerdings sind etwa 100 Einträge im Backlog ganz üblich – und normal. Aber selbst mit hundert Backlog-Items ist es leicht, die Übersicht zu verlieren oder sie lange Zeit unbearbeitet zu lassen, ohne sie in die nächsten Sprints hinzuzufügen.
Um dein Backlog übersichtlicher zu gestalten, kannst du es in verschiedene Abschnitte unterteilen.
Manche Produktmanager gruppieren Einträge gerne nach Fokusbereichen oder Meilensteinen. Ich persönlich nutze lieber die Tags Version, Epic und Komponente an Aufgaben dafür und unterteile mein Backlog in Abschnitte nach dem Umfang der kommenden Sprints.
So kannst du den allergrößten Teil der Aufgaben im Backlog einem Sprint (oder zumindest einer groben Umsetzungszeit) zuweisen und sicherstellen, dass keine Aufgabe vernachlässigt bleibt.
Eine weitere gängige Methode zur Verwaltung des Backlogs mithilfe von Abschnitten besteht darin, die Einträge nach ihrem Verfeinerungsstatus beziehungsweise Workflow zu gruppieren (dabei kann KI im Backlog-Management unterstützen). In diesem Fall optimierst du deinen Prozess mit den folgenden Abschnitten:
- Aktueller Sprint
- Bereit für die Planung
- Bereit für den Feinschliff
- Backlog
In diesem Fall arbeitest du daran, für die Backlog-Einträge Produktanforderungen und Beschreibungen hinzuzufügen. Sobald die Anforderungen fertig sind, verschiebst du sie in den Abschnitt „Bereit für den Feinschliff“, der als Grundlage für dein nächstes Refinement-Meeting dient.
Nachdem ein Eintrag verfeinert wurde, verschiebst du ihn in den Abschnitt „Bereit für die Planung“, was anzeigt, dass er bereit ist und das Team ihn im nächsten Sprint einplanen kann.
Beispiel Nr. 2: Ein Backlog mit sinnvoll platzierten Komponenten, Epics und Versionen
Die Segmentierung deines Backlogs macht es auf jeden Fall übersichtlicher und strukturierter. Die Einschränkung bei einer reinen Segmentierung ist jedoch, dass du dein Backlog immer nur nach einem Kriterium organisierst (z. B. Sprints, Status im Feinschliff usw.).
Glücklicherweise bieten moderne Produkt-Backlog-Tools zahlreiche Optionen, um deine Aufgabenliste für die Produktentwicklung nach mehreren Kriterien zu organisieren. Schau dir nur einmal dieses schön organisierte Backlog an.
Sieht das nicht gut organisiert und angenehm für das Auge aus? In diesem konkreten Fall haben wir folgende Funktionen genutzt, um unser Backlog überschaubarer zu machen:
Komponenten
Dieses Feld beziehungsweise Merkmal beschreibt traditionell den Bereich des Produkts, in dem du die betreffende Funktion hinzufügen möchtest. Im obigen Beispiel sind die Komponenten die einzelnen Produkte, aus denen Grammarly besteht.
Eine weitere gängige Möglichkeit, Komponenten zu nutzen, besteht darin, Stories/Aufgaben auf Grundlage der für die Umsetzung erforderlichen Technologie zu organisieren. Bei Webanwendungen kannst du z. B. Frontend-/Backend-Komponenten definieren, um die Arbeit und die Abhängigkeiten zwischen auf Client- oder Serverentwicklung spezialisierten Ingenieurteams besser zu strukturieren.
Versionen/Releases
Mit diesem Merkmal dokumentierst du alle Features und Fehlerbehebungen, die dein Scrum-Team mit einer bestimmten Produktversion veröffentlichen wird. Die Versionsverfolgung im Backlog bringt zwei äußerst wertvolle Vorteile mit sich.
- Sie hilft dir bei der Sprint- und Releaseplanung. Wenn du beispielsweise ein Release in zwei Wochen planst, solltest du beim Planungsmeeting alle für diese Version vorgesehenen Aufgaben in den Sprint aufnehmen.
- Du kannst alles dokumentieren, was dein Team in eine bestimmte Version eingebracht hat, und bei Problemen in der Produktion schnell nachverfolgen, woher etwas stammt.
Nehmen wir an, die Nutzer erhalten plötzlich Captcha-Fehler im Anmeldeprozess der aktuellen Version 1.3.2. Wenn du nach der Aufgabe suchst, auf deren Basis dein Team die Captcha-Konfiguration geändert hat, siehst du, dass sie zur Version 1.3.1 gehört. Das bedeutet, du musst entweder auf Version 1.3.0 zurückgehen oder einen Hotfix durchführen.
Epics
Nun, ich denke, ich muss nicht erklären, was ein Epic ist und welche Vorteile dessen Nutzung bringt. Aber wenn du tiefer in Best Practices und Details zu Epics eintauchen möchtest, findest du in unserem Epic-Guide (Wortspiel beabsichtigt) alles dazu.
Beispiel Nr. 3: Ein Backlog mit dem richtigen Maß an Details je Abschnitt
Diese Best Practice bist du sicherlich in vielen Büchern und Theoriebeiträgen über Agile und Produktmanagement schon begegnet. Obwohl man theoretischen Konzepten mit steigender Erfahrung immer skeptischer gegenübersteht, ist gerade dieses in der Praxis tatsächlich hilfreich.
Die Idee dahinter: Die Einträge an der Spitze des Backlogs sollten möglichst detailliert sein, idealerweise hast du sie mindestens einmal durch ein Backlog Refinement geführt. Die Einträge im unteren Bereich des Backlogs hingegen sollten wenig Details enthalten, denn die Wahrscheinlichkeit ist hoch, dass du noch Neues über dein Produkt und deine Nutzer:innen lernst und dieser Eintrag somit hinfällig wird.
Das bedeutet, wenn der Eintrag ganz oben in deinem Backlog so aussieht (oder sogar noch ausführlicher):
Die Stories am Ende deines Backlogs sollten deutlich weniger Details enthalten und so aussehen:
Und welche Stories und Initiativen du auch immer in der Mitte deines Backlogs hast, sie werden ein mittleres Detailniveau aufweisen.
Beispiel Nr. 4: Ich weiß, es ist offensichtlich, aber ... ein sauberes Backlog
Ich weiß, dass es nicht einfach ist, dein Backlog sauber zu halten. Ich war schon oft in dieser Situation und weiß, dass sich das wie eine lästige Pflicht anfühlt. Das Nicht-Überprüfen aller Einträge im Backlog und das Vergessen, veraltete Elemente zu entfernen, sind jedoch entscheidende Faktoren für die Qualität deines Backlogs.
Es ist nicht immer leicht, Dinge aus deinem Backlog zu löschen. Es gibt richtig nette Features, die du irgendwann mal umsetzen möchtest (meistens Dinge, die „nice-to-have" sind), und manchmal willst du dich einfach nicht davon trennen. Aber irgendwann musst du dir eingestehen, dass du sie sowieso nie implementieren wirst. Und selbst wenn doch, würde das bedeuten, dass du keine wichtigen Features mehr übrig hast – was generell kein gutes Zeichen ist.
Manchmal sind es deine Stakeholder, die solche veralteten Punkte im Backlog erstellt haben. Bevor du diese entfernst, fragst du sie, ob ihre Anfrage noch aktuell ist – und meistens sagen sie „ja". Tja, wenn die Anfrage älter als 6 Monate ist und sie sowieso schon vergessen wurde, dann überzeug sie einfach davon, dass es nichts Dringendes ist (wenn es dringend wäre, hätten sie mehrfach nachgehakt) und lösche sie.
Ein großartiges Backlog ist das, was für dich am besten funktioniert
Wenn du alle hier genannten Best Practices berücksichtigst, hast du dann ein großartiges Backlog? Sie helfen dir sicherlich weiter, garantieren den Erfolg aber nicht.
Vergiss nicht: Der Sinn des Backlogs ist es, eine zentrale Informationsquelle für alle zu sein. Neben diesen Best Practices musst du daher auch die Bedürfnisse und die Arbeitsweise deines Teams und deiner Stakeholder berücksichtigen und das Backlog so gestalten, dass alle auf demselben Stand bleiben.
Dieser Leitfaden zu großartigen Backlogs ist Teil einer umfassenden Serie zu Agile-Themen. Abonniere unseren Newsletter, um weitere Leitfäden und Insights wie diesen alle zwei Wochen direkt in dein Postfach zu bekommen!
