Die besten Ratschläge von Scrum- und Agile-Experten zur Handhabung Ihres Produkt-Backlogs

Lassen Sie uns zunächst das Produkt-Backlog klar definieren. Scrum organisiert Projekte in eine Reihe von konzentrierten Arbeitsperioden, die Sprints genannt werden. Jeder Sprint dauert normalerweise zwei Wochen. Bevor ein Sprint beginnt, erstellen das Team und der Scrum-Master (der als Coach fungiert) ihr Sprint-Backlog, d. h. eine Liste dessen, was sie im bevorstehenden Sprint zu erreichen gedenken. 

Der Sprint-Backlog wird aus dem größeren Produkt-Backlog abgeleitet, das eine vollständige Liste aller Funktionen und Funktionen enthält, die dem Produkt hinzugefügt werden müssen. Der Produktverantwortliche ist für die Priorisierung des Produkt-Backlogs verantwortlich. (Der Produktverantwortliche ist auch für die Bedürfnisse des Kunden und anderer Interessengruppen zuständig und leitet die Arbeit des Entwicklungsteams). Das Produkt-Backlog ist vertikal angeordnet, d. h. die wichtigsten Aufgaben stehen ganz oben, und das Scrum-Team wählt die Elemente des Backlogs in der Regel nach Priorität aus. Das Produkt-Backlog wird sich im Laufe der Zeit auf der Grundlage von Benutzeranfragen, Geschäftsanforderungen und allgemeinen Technologietrends ändern und weiterentwickeln.

Nebenbei sei bemerkt, dass Sie ein Produkt-Backlog auch in einem anderen Agile-Framework namens Kanban verwenden können. Obwohl Kanban auf der Beschränkung der laufenden Arbeiten (WIP) anstelle von Sprints mit fester Länge (Scrum) beruht, können die Informationen in diesem Artikel auch für Kanban-Projekte verwandt werden.

Ein gut aufgebautes Produkt-Backlog stellt sicher, dass Ihre Arbeit produktiv und wertvoll ist, dass das Produkt den Kundenbedürfnissen entspricht und dass es mit den Zielen Ihres Unternehmens übereinstimmt. Wie bei Ihrer persönlichen To-do-Liste müssen Sie auch Ihr Produkt-Backlog ständig pflegen. Dieser Prozess wird oft als Verbesserung oder Pflege des Produkt-Backlogs bezeichnet. Prioritäten ändern sich, Aufgaben werden erledigt und Ideen verworfen. Ohne Aktualisierung Ihres Backlogs wird es desorganisiert und hilft Ihnen nicht mehr, auf dem Laufenden zu bleiben.

Um mit der Erstellung eines Produkt-Backlogs zu beginnen, empfehlen einige Agile-Experten, mit einer Produkt-Roadmap zu beginnen. Dabei handelt es sich um einen strategischen Plan, der eine längerfristige Perspektive für Ihr Produkt aufzeigt.  Roman Pichler, ein Experte für Agile-Produktmanagement, sagt, dass sich viele Produktverantwortliche und -manager in ihren Roadmaps zu sehr auf die Details der Funktionen konzentrieren und zu wenig auf die Gesamtvision. Er entwickelte eine zielorientierte Roadmap-Vorlage, die das angestrebte Produktziel und die zur Erreichung dieses Ziels erforderlichen Funktionen hervorhebt.
 
Während Ihre Roadmap langfristige Ziele für mehrere Versionen enthalten kann, sollte sich das Produkt-Backlog auf eine detailliertere Aufzählung der Arbeiten für die nächste Version konzentrieren. Künftige Veröffentlichungen sollten weiter unten platziert und weniger detailliert formuliert werden. Anschließend werden die Informationen aus der Roadmap in Aufgaben und Arbeitsschritte umgesetzt. 

Jedes Produkt sollte über ein eigenes Backlog verfügen. Wenn Ihr Produkt recht umfangreich oder Teil einer Reihe miteinander verbundener Produkte ist, kann es verwirrend sein, zu bestimmen, was ein Produkt ist. Der Agile-Experte Kenneth Rubin, ein Berater bei Innolution, sagt, dass das Ziel darin besteht, die Anzahl der Komponententeams und Komponenten-Backlogs zu minimieren. Daher zieht er es vor, wenn möglich nur ein Backlog zu verwenden. Bei sehr großen Projekten mit zehn oder Hunderten von Teams ist dies jedoch nicht praktikabel. In diesen Fällen können hierarchische Backlogs mit einem Backlog für große Funktionen und einem separaten Backlog für jeden zugehörigen Arbeitsbereich verwendet werden.

Aufgaben im Produkt-Backlog werden häufig in sogenannten User-Storys ausgedrückt. Dabei handelt es sich um eine Beschreibung, wie die Funktion aus der Sicht des Benutzers funktioniert. Eine User-Story ist klein genug, um sie innerhalb eines Sprints umsetzen zu können. 

Chuck Kroll, ein Agile-Coach, der Teams bei Fidelity Investments geschult hat, empfiehlt eine traditionelle Formel für User-Storys:  „Als (Benutzertyp wie Kunde) möchte ich (Ziel) damit ich (Grund)“, sagt Kroll. „Dadurch wird klar, wer die Funktion nutzen wird, was sie mit sich bringt und welchen Geschäftswert sie bietet.”

User-Story vs. User-Epos: Wie detailliert sollten Backlog-Elemente sein?

Eine viel umfangreichere User-Story wird als „Epos“ bezeichnet und kann mehrere Sprints in Anspruch nehmen. Bevor die Arbeit beginnen kann, müssen Epen in Storys unterteilt werden. 

Mike Cohn, Gründer von Mountain Goat Software, ein Unternehmen, das Agile- und Scrum-Schulungen anbietet, führt dieses Beispiel für ein Epos an: Ein Hotelunternehmen möchte eine Anwendung zur Ermittlung des Höchstpreises für ein Hotelzimmer entwickeln, der von Variablen wie den Preisen der Konkurrenz, der Saison usw. abhängt. „Als Hotelbetreiber möchte ich den optimalen Tarif für Zimmer in meinem Hotel festlegen.“ Dies lässt sich in User-Storys wie „Als Hotelbetreiber möchte ich den optimalen Zimmerpreis auf der Grundlage der Vorjahrespreise festlegen“ und „Als Hotelbetreiber möchte ich den optimalen Zimmerpreis auf der Grundlage der Preise vergleichbarer Hotels festlegen" unterteilen.

Wenn Sie die User-Storys für das Produkt-Backlog vorbereiten, sollten Elemente mit höherer Priorität detaillierter sein, um das Team bei der korrekten Umsetzung zu unterstützen. Dies kann Diagramme enthalten, in denen der Arbeitsablauf einer Funktion angezeigt wird, oder eine Detailbeschreibung. 
„Der wichtigste Ratschlag, der meiner Meinung nach übersehen wird, ist, dass die Elemente des Produkt-Backlogs nicht alle gleich detailliert sein müssen“, so Cohn. „Elemente, die in den nächsten Sprint kommen, müssen angemessen detailliert sein. Weiter in der Zukunft liegende Elemente können hingegen weniger detailliert sein.“

Stellen Sie sich die folgende User-Story vor: Als Besucher der Webseite möchte ich in der Lage sein, ein Flugticket zum günstigsten Preis für den von mir gewünschten Flughafen oder für Flughäfen in der Nähe zu kaufen. Da sie diese Story am Anfang des Produkt-Backlogs befindet, sollten Sie der User-Story Einzelheiten hinzufügen, wie z. B: Die Funktion sollte die Tarife für alle Flughäfen innerhalb von 100 Meilen überprüfen. Sie sollte mir die Möglichkeit geben, die Tarife nach Entfernung vom gewünschten Flughafen sowie nach Preis zu sortieren. 

Pichler empfiehlt, dass der Produktlebenszyklus eine wichtige Rolle bei der Entscheidung über die Granularität des Produkt-Backlogs spielen sollte. Neue Produkte sollten kürzere, weniger detaillierte Backlogs haben, die es Ihnen ermöglichen, mit neuen Ideen zu experimentieren und Ihr Produkt häufig zu ändern, um es zu optimieren. Auf der anderen Seite profitieren ältere, stabilere Produkte von einem detaillierteren Backlog, weil Sie besser vorhersehen können, wie sich das Produkt entwickeln wird.

Der Freigabezyklus ist ein weiterer Faktor in Ihrem Produkt-Backlog. Wenn Sie mit der Arbeit an einer neuen Version oder einer großen Veröffentlichung beginnen, gibt es mehr Unbekannte. Und das, was Sie lernen, wird möglicherweise zu großen Änderungen in Ihrem Backlog führen. „Daher ist ein kürzeres, weniger detailliertes Produkt-Backlog zu Beginn des Veröffentlichungszyklus sinnvoll“, erklärt Pichler. 

Bill Wake, ein Agile-Berater, der jetzt für Industrial Logic Inc. arbeitet, hat ein weitverbreitetes Modell und eine Eselsbrücke für die Merkmale einer guten User-Story entwickelt, die er mit dem Akronym INVEST zusammenfasst:

I - Independent (unabhängig) - Die Storys sollten sich nicht überschneiden und können im Idealfall in beliebiger Reihenfolge umgesetzt werden.
N - Negotiable (verhandelbar) - Die Story erfasst das Wesentliche, aber nicht die Details, die zwischen den Beteiligten ausgehandelt werden.
V - Valuable (wertvoll) - Die Story bietet dem Kunden einen klaren Mehrwert. 
E - Estimable (einschätzbar) - Sie sind in der Lage, den damit verbundenen Aufwand abzuschätzen. Dabei kann es sich um eine Zeitschätzung oder um so genannte Story-Points handeln, eine willkürliche Maßeinheit zur Bewertung der relativen Komplexität (wie XS, S, M, L, XL oder 1, 2, 4, 8, 16). 
S - Small (klein) - „Gute Geschichten sind in der Regel klein“, erklärt Wake. Das bedeutet, dass die Geschichte in (höchstens) wenigen 40-Stunden-Wochen von einer engagierten Person oder aufgeteilt auf mehrere Team-Mitglieder fertiggestellt werden sollte. 
T - Testable (prüfbar) - „Die User-Story sollte in irgendeiner Weise messbar oder umsetzbar sein“, so Ulf Eriksson, Gründer und Produktverantwortlicher der IT-Testplattform ReQtest.

Cohn betont, dass nicht jedes Element im Backlog eine User-Story sein muss. „Ich treffe auf Teams, die glauben, dass jedes Produkt-Backlog-Element eine User-Story sein sollte. User-Storys sind großartig – wenn es Benutzer gibt. Aber einige Dinge, die zu einem Produkt-Backlog gehören, sind nicht direkt für Benutzer bestimmt. Diese Elemente müssen nicht als User-Storys geschrieben werden.“ 

Dazu gehören Arbeiten am Back-End oder an anderen Aufgaben, die von den Benutzern weit entfernt sind. Cohn empfiehlt, diese Aufgaben mithilfe der funktionsgesteuerten Entwicklungssyntax (Objekt + Ergebnis + Verb, z. B. „Kennwort eines Benutzers überprüfen”) zu beschreiben.
Die vier Arten von Elementen, die häufig in Scrum-Backlogs gefunden werden, sind Funktionen, Bugs, technische Arbeiten und Wissenserwerb. Funktionen eignen sich normalerweise dafür, als User-Storys ausgedrückt zu werden, während dies für andere Elemente nicht zutrifft. 

Wenn Sie gerade erst anfangen, brauchen Sie sich keine Sorgen zu machen: Sie müssen Ihr Projekt nicht mit einem perfekten Produkt-Backlog beginnen. Beginnen Sie mit einem Brainstorming der notwendigen Aufgaben, um genügend Informationen für Ihren ersten Sprint zu erhalten. Anschließend können Sie Ihr Produkt-Backlog erweitern, wenn Sie mehr über das Produkt, die Benutzeranforderungen und Rückmeldungen erfahren.

„Mein wichtigster Tipp in Bezug auf Produkt-Backlogs ist, sie einfach zu halten. Es ist nur ein geordneter Produktstrukturplan“, sagt Laurens Bonnema, ein Agile-Berater bei Xebia in den Niederlanden.

C.J. Boat, ein Agile-Teamleiter für den Versicherungsmarktplatz Ensurem, stimmte zu. „Schaffen Sie vernünftige Erwartungen! Wenn Sie Ihr Backlog zu umfangreich werden lassen oder Ihre Arbeit nicht richtig organisieren, können das Backlog und die Sprints so überladen werden, dass sie fehlschlagen“, sagt er. 

Nachdem Sie die Aufgaben hinzugefügt haben, ist es an der Zeit, das Produkt-Backlog zu ordnen. Legen Sie die wichtigeren Arbeiten über weniger wichtigere. Sie können dies auf der Grundlage Ihrer Prioritätseinstufung tun und dabei entscheiden, wie Sie Elemente mit der gleichen Prioritätseinstufung einordnen.

„Wenn Sie Aufgaben zu Ihrem Backlog hinzufügen, weisen Sie ihnen eine anfängliche Priorität zu“, sagt Kevin Lonergan, Principal Project Management Consultant bei PMIS Consulting in Großbritannien. „Eine einfache dreistufige Prioritätenliste ist ausreichend: 1 – entscheidend für die Erreichung der Geschäftsziele, 2 – nützlich, aber nicht kritisch, 3 – wäre ein Bonus, wenn diese Elemente erledigt werden.“

Einige Experten halten es für eine bessere Methode, die Liste nach anderen Kriterien zu ordnen, z. B. nach dem Risiko, dem Investitionswert (ROI), dem Kosten-Nutzen-Verhältnis, einem Eimermodell wie MoSCoW (muss, sollte, könnte, wird nicht), den Auswirkungen einer Story auf eine andere, der geschätzten Umsetzungszeit oder den Abhängigkeiten.

Bonnema von Xebia bevorzugt die Methode des Weighted Shortest Job First (WSJF), die von Donald Reinertsen in „The Principles of Product Development Flow“ beschrieben und von Dean Leffingwell, dem Entwickler von „Scaled Agile Framework“, weiterentwickelt wurde. Dabei handelt es sich um eine Formel für die Einstufung des Produkt-Backlogs auf Grundlage der Aufgabendauer und einer Gewichtung nach Verzugskosten. „Ich habe noch keine bessere Methode gefunden, um Backlogs auf jeder Ebene konsistent und korrekt zu priorisieren als mit WSJF“, sagt Bonnema. „Aufgaben bleiben im Produkt-Backlog, bis sie abgeschlossen sind oder bis der Produktverantwortliche entscheidet, dass sie nicht mehr benötigt wird. 

Um festzustellen, wann eine User-Story abgeschlossen ist und aus dem Backlog entfernt werden kann, sollten Teams eine standardisierte „Definition von erledigt“ entwickeln.” Dies sind die Akzeptanzkriterien für eine Funktion, das sicherstellt, dass alle Team-Mitglieder wissen, was von der Arbeit, die sie liefern, erwartet wird. Kelly Waters, der Autor von „All About Agile“, ist der Meinung, dass „erledigt“ versandfertig bedeuten sollte. Jeff Sutherland, CEO von Scrum Inc., verwendet den beliebten Agile-Ausdruck „done done“ was bedeutet, dass am Ende des Sprints die Codierung abgeschlossen wurde und Softwaretests auf Funktionsebene ebenfalls ohne Fehler abgeschlossen sind. Wenn die Definition Ihres Teams für "erledigt" feststeht, kann ein Element aus dem Produkt-Backlog in die Spalte "abgeschlossen" verschoben werden.

Da Sie nun wissen, was ein Produkt-Backlog ist und was in ein solches gehört und was nicht, finden Sie hier Ihre Checkliste für die Gestaltung Ihres ersten Produkt-Backlogs:

1. Der Produktverantwortliche ist für das Produkt-Backlog zuständig. Wenn Sie das sind, sind Sie für die Erstellung des Produkt-Backlogs verantwortlich, aber Sie müssen nicht die einzige Person sein, die daran beteiligt ist. Scrum-Team-Mitglieder und andere Beteiligte können sich ebenfalls beteiligen.
2. Denken Sie daran, dass das Produkt-Backlog die vollständige Liste aller User-Storys und anderer Aufgaben für das Produkt ist.
3. Denken Sie an jede mögliche Aufgabe, und schreiben Sie sie auf. Seien Sie so präzise wie möglich und bitten Sie um Beiträge aus allen relevanten Bereichen Ihres Unternehmens sowie um Kundenrückmeldungen.
4. Verfassen Sie Storys aus der Perspektive des Benutzers und fügen Sie eine Aktion und einen Grund hinzu. (Als _ möchte ich _, damit ich _.) Berücksichtigen Sie alle möglichen Benutzer. Schreiben Sie diese auf Karteikarten oder verwenden Sie ein Online-Werkzeug. Setzen Sie Tags, um die geplante Veröffentlichung zu kennzeichnen.
5. Berücksichtigen Sie Fehlerbehebungen, Wissenserwerb und technische Arbeiten.
6. Als Produktverantwortlicher bewerten Sie allein die Wichtigkeit der einzelnen Punkte für das Unternehmen von sehr hoch bis sehr niedrig oder gemäß einer anderen Methode. Sie können Benutzer befragen, um eine solide Grundlage für diese Entscheidungen zu erhalten. 
7. Geben Sie für jedes Arbeitselement auch eine Schätzung des Aufwands an, der damit verbunden ist.
8. Bewerten Sie das Produkt-Backlog. 
9. Die Arbeit, die das Team in einem Sprint in Angriff nehmen will, ist das Sprint-Backlog, das sich vom Produkt-Backlog unterscheidet. Der Sprint-Backlog ändert sich während des Sprints nicht. Elemente werden als abgeschlossen betrachtet und aus den Sprint- und Produkt-Backlogs entfernt, wenn sie „erledigt“ sind.
10. Wenn neue Aufgaben hinzukommen, fügen Sie sie dem Produkt-Backlog an der richtigen Position hinzu. Wenn Sie neue Informationen wie Rückmeldungen sammeln, können Sie Elemente löschen oder neu ordnen. 

Wenn Sie fertig sind, sollte das Ergebnis in etwa so aussehen:

An dieser Stelle sind Glückwünsche angebracht, wenn Sie erfolgreich Ihr erstes Produkt-Backlog erstellt und Ihr Scrum-Team dazu gebracht haben, in einem Sprint an einer Reihe wertvoller User-Storys zu arbeiten. Aber es ist noch nicht an der Zeit, sich zu entspannen. 

Nach der Erstellung muss das Produkt-Backlog ständig gepflegt und aktualisiert werden. Dieser Prozess, auch bekannt als Produkt-Backlog-Pflege oder -Optimierung, hält Ihr Backlog auf der Grundlage von Informationen aus dem Markt, von Benutzern, dem Produktteam und dem Management Ihrer Organisation auf dem aktuellen Stand. Indem Sie die Pflege des Backlogs im Auge behalten, stellen Sie sicher, dass sich das Entwicklungsteam immer auf die richtigen Aufgaben konzentriert, dass Sie für den nächsten Sprint bereit sind, dass Sie Ihre Ressourcen gut nutzen und Ihren Kunden das bestmögliche Produkt liefern. 

Eine einfache Möglichkeit, sich das Ziel des Optimierungsprozesses des Produkt-Backlogs zu merken, ist das DEEP-Akronym. Ihr Ziel ist es, sicherzustellen, dass Ihr Produkt-Backlog immer DEEP ist: 

D - Detailed (detailliert), sodass die Einträge am Anfang der Liste detaillierter sind als die am unteren Ende. 
E - Estimated (eingeschätzt) - Jedes Element des Produkt-Backlogs, oder zumindest die Elemente, die in die nächste Version einfließen, sollten nach Story-Points oder Zeitaufwand eingeschätzt werden. Je mehr Arbeit Ihr Team leistet, desto deutlicher wird seine Geschwindigkeit, mit der es Elemente des Produkt-Backlogs abschließt, und desto einfacher fällt die Schätzung.
E - Emergent (auftauchend) - Dies bedeutet, dass der Produkt-Backlog an neu auftauchende Elemente oder Informationen angepasst wird.
P- Prioritized (priorisiert) - Alle Elemente im Produkt-Backlog sind so angeordnet, dass die wichtigsten ganz oben stehen. 

Auch wenn Sie sich noch so sehr bemühen, Ihr Produkt-Backlog reibungslos zu verwalten, kann es zu Störungen kommen. Agile Experten, die mit vielen Teams und an einer Vielzahl von Projekten gearbeitet haben, geben Tipps zur Fehlerbehebung und Problemvermeidung.

Laut Agile-Coach Kroll sind die häufigsten Probleme, die er sieht, die mangelnde Beteiligung der Projektpaten, die täglich einbezogen werden müssen, und die Tendenz, das Team unter Druck zu setzen, um Zeitvorgaben zu erfüllen, die sich nicht am tatsächlichen Durchsatz des Teams orientieren. Die Lösung besteht darin, dass die Manager von einer traditionellen „Plan-Ist“-Denkweise zu einem Agile-Ansatz übergehen. 

Jonathan Roger, Projektmanager und Scrum-Master bei AndPlus, empfiehlt, am unteren Ende des Produkt-Backlogs einen „Eiskasten“ für nicht priorisierte und unausgegorene Ideen anzulegen. „Produktverantwortliche können die langfristig gewünschten Funktionen nachverfolgen, ohne dass der Druck entsteht, sie in einer Prioritätsreihenfolge zu halten. Teams können ihre Ideen für die Überprüfung des Produktverantwortlichen hinzufügen. Sie dient auch als guter Ausgangspunkt für Funktionsanfragen von Kunden oder Beteiligten.” 

Lonergan von PMIS Consulting empfiehlt eine sorgfältige Auswahl des Produktverantwortlichen als Schlüssel zum Erfolg. „Eine Person muss die Rolle des Produktverantwortlichen ausüben - und nicht ein Ausschuss“, betont er. „Nur diese Person ist für das Produkt-Backlog verantwortlich. Stellen Sie sicher, dass der Produktverantwortliche die Entwicklung des Backlogs vorantreibt.“ 

„Die Nummer 1 (Fehler) ist zweifellos die Ernennung der falschen Person zum Produktverantwortlichen aufgrund mangelnder Autorität, Fachwissen, Zeitmangel usw.“, fügt Lonergan hinzu. 

Von einfacher Aufgabenverwaltung und Projektplanung bis zu komplexem Ressourcen- und Portfoliomanagement hilft Ihnen Smartsheet, die Zusammenarbeit zu verbessern und das Arbeitstempo zu erhöhen – und befähigt Sie, mehr zu schaffen. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.