Ein Product Backlog beschreibt eine Liste aller Aufgaben, Funktionen und Elemente, die nach der Priorität geordnet sind und erledigt werden müssen, um das Ziel des Projekts erreichen zu können. Erfahren Sie hier anhand von einem Product Backlog Beispiel, welche Elemente integriert werden müssen und wie Sie einen Product Backlog erstellen können.
Update: Bei vielen Projekt-Teams schleichen sich Angewohnheiten ein, die zu einer nicht optimalen Nutzung eines Product Backlogs führen. Im neuen Update erfahren Sie, worauf Sie achten sollten.
Ein Product-Backlog ist eine geordnete Liste aller Aufgaben, Funktionen oder Elemente, die als Teil Ihres Projektstrategieplans erledigt werden müssen.
Am Anfang jeder Produktentwicklung steht eine Idee. Um diese Idee auch erfolgreich umzusetzen, braucht es ein wirklich engagiertes Team. Ja, sogar das iPhone war irgendwann einmal nur ein Prototyp, der – mithilfe des richtigen Teams – seine heutige Popularität erlangt hat. Wenn Sie ein Scrum-Team im Entwicklungsbereich managen, wissen Sie bestimmt schon, dass eine gute Organisation das A und O für den Erfolg Ihres Produkts ist.
Wie kann ein Entwicklungsteam aber gut organisiert bleiben und seine Ziele erreichen? Am besten eignen sich dafür altbewährte To-do-Listen. Und genau genommen ist ein Produkt-Backlog nichts anderes als eine spezialisierte To-do-Liste. Wenn Ihr Team mit der Agile-Methodik arbeitet, können Sie Projekte mithilfe eines Product-Backlogs in kleinere Arbeitsschritte aufteilen und feststellen, welche Aufgaben vorrangig zu erledigen sind.
Im folgenden Artikel erfahren Sie, was genau in einem Product-Backlog erfasst wird und wie Sie selbst für Ihr Team ein Product Backlog erstellen.
Im Grunde ist ein Produkt-Backlog eine Liste mit Elementen oder Funktionen, die nach ihrer Priorität gereiht werden und die Sie benötigen, um Ihre Ziele zu erreichen und realistische Erwartungen zu stellen. Außerdem unterstützt ein Backlog Ihr Team bei der Erfassung aller Aufgaben. Generell gilt, dass Sie für jedes Produkt, das Sie entwickeln, einen Product-Backlog erstellen sollten. Für jeden Product-Backlog sollte wiederum ein bestimmtes Team zuständig sein.
Manchmal, besonders wenn Sie an einem größeren Produkt arbeiten, kann es mehrere Produkt-Backlogs und mehrere Teams geben. Hier ein Beispiel zur besseren Vorstellung: Die Creative Cloud von Adobe ist ein Produkt, das mehrere kleinere Produkte wie Photoshop, Illustrator und After Effects umfasst. Für jedes dieser kleineren Produkte wurde ein eigener Produkt-Backlog mit einem eigens zugewiesenen Entwicklungsteam erstellt.
Das Product-Backlog leitet sich von Ihrem Produktfahrplan ab, der alle Maßnahmen zur geplanten Entwicklung des Produkts beschreibt. Entwickler nutzen die Aufgaben im Product-Backlog, um das gewünschte Ergebnis so schnell wie möglich zu erreichen.
Agile Teams haben die Aufgabe, Produkte zu erstellen und sie im Laufe eines Projektes immer wieder weiterzuentwickeln. Agiles Projektmanagement sieht vor, dass die Aufgaben im Produkt Backlog nicht in Stein gemeißelt sind und auch nicht alle darin erfassten Elemente immer abgeschlossen werden müssen. Im Laufe eines Projektes wird Ihr Entwicklerteam die notwendigen Aufgaben priorisieren und so den Product-Backlog Schritt für Schritt weiterentwickeln. Dies erhöht die Agilität und wirkt sich folglichermaßen positiv auf den Erfolg des Projekts aus.
Üblicherweise werden in einem Product-Backlog Funktionen, Fehlerbehebungen, technische Schulden und erworbenes Wissen erfasst. Bei diesen Einträgen im Product-Backlog handelt es sich um Arbeitsschritte, die umgesetzt werden müssen, um das gewünscht Produkt zu erhalten. Folgende Product Backlog Items findest du üblicherweise:
Product Backlog User Stories bezeichnet eine Funktion des Produkts, die dem Produktnutzer hilfreich erscheint. Eine User Story kann entweder komplex (in diesem Fall werden sie oft als „Epics“ bezeichnet) oder einfach sein. Durch die Erstellung von Product Backlog User Stories kann Ihr Team besser feststellen, was der Nutzer vorrangig benötigt.
Die Fehlerbehebung muss nicht groß erklärt werden. Ihr Scrum-Team sollte Fehler schnell beheben, damit die Leistung und das Ansehen des Produkts nicht beeinträchtigt werden. Manche Fehlerbehebungen können so dringlich sein, dass Ihr Team seinen aktuellen Sprint unterbrechen muss, während die Behebung anderer wiederum erst im nächsten Springt erfolgen kann. Grundsätzlich gilt für Fehler aber, dass sie in Ihrem Product Backlog ganz oben stehen sollten, damit Ihr Team sie nicht vergessen kann.
Kostenlose Vorlage zur FehlerverfolgungBei technischen Schulden ist es wie bei finanziellen Schulden: Wenn sie ignoriert werden, sammeln sich Zinsen an. Wenn Entwickler technische To-dos im Backlog weiter nach unten verschieben, häufen sie sich an und es wird immer schwieriger, sie abzuarbeiten. Ihr Team kann eine Ansammlung technischer Schulden aber durch gute Organisation und laufendes Erledigen kleiner, täglicher Aufgaben verhindern.
Hierbei geht es darum, Informationen zu sammeln, die Sie für die Erledigung zukünftiger Aufgaben benötigen. Es kann zum Beispiel vorkommen, dass Ihr Team für die Entwicklung einer Funktion erst bestimmte Informationen benötigt. In solch einem Fall würden Sie eine Aufgabe für die Recherche erstellen. Das kann ein Prototyp, Experiment oder Proof of Concept sein. Wichtig ist, die Informationen zu erhalten, die Sie für die Entwicklung der Funktion brauchen.
Ein Product Backlog ist mehr als nur eine einfache To-do-Liste. Sie können damit komplexe Aufgaben in mehrere einzelne, kleinere Arbeitsschritte aufgliedern und sie je nach Bedarf verschiedenen Teammitgliedern zuweisen. Im Folgenden zeigen wir Ihnen, wie Sie einen effektiven Product Backlog erstellen.
Der Produktfahrplan (auch Roadmap genannt) dient als Grundlage für den Product Backlog. Bevor Ihr Team einen Product Backlog erstellen kann, brauchen Sie einen Produktfahrplan, da dieser als eine Art Handlungsplan fungiert und beschreibt, wie sich Ihr Produkt im Laufe des Entwicklungsprozesses verändert. Der Produktfahrplan ist die langfristige Vision für Ihre Produktentwicklung, aber auch er kann im Laufe der Zeit an aktuelle Entwicklungen angepasst werden.
Auf Basis Ihres Produktfahrplans kann Ihr Team nun alle Einträge für den Product Backlog auflisten. Dabei kann es sich im To-dos mit hoher Priorität, aber auch um noch eher abstrakte Ideen handeln. In dieser Phase werden Sie sich auch mit Beteiligten austauschen, um deren Ideen für Produktverbesserungen zu berücksichtigen. Mithilfe einer Vorlage wird es einfacher, die einzelnen Einträge zeilenweise zu erstellen und sie dann bei Bedarf neu anzuordnen.
Nachdem Ihr Team alle Einträge für den Produkt-Backlog erfasst hat, ist es an der Zeit, sie zu sortieren und die wichtigsten Aufgaben zu priorisieren. Am besten lassen sich die Aufgaben mit höchster Priorität bestimmen, wenn Sie sich gedanklich in Ihren Kunden versetzen und überlegen, welche Einträge für ihn den größten Nutzen haben.
Bedenken Sie immer, dass es sich bei Ihrem Product Backlog um ein lebendes Dokument handelt. Ihr Team arbeitet die einzelnen Einträge Schritt für Schritt ab und Sie können im Laufe des Prozesses jederzeit neue Einträge hinzufügen oder bestehende neu priorisieren oder anpassen.
Die Priorisierung von Aufgaben ist ein wesentlicher Bestandteil bei der Verwaltung Ihres Produkt-Backlogs. Als Scrum-Master sollten Sie genau wissen, welche neuen Funktionen Beteiligte von Ihrem Produkt erwarten. Wir zeigen Ihnen einige Strategien, die Sie bei der Priorisierung Ihrer Backlog-Einträge nutzen können:
Versuchen Sie, Ihren Backlog nach Dringlichkeit und Wichtigkeit zu organisieren. Das Team sollte sich vorrangig um die Einträge im Product Backlog kümmern, die die Funktionalität des Produkts sowie die Nutzererfahrung verbessern.
Lesenswert: So priorisieren Sie Ihre wichtigsten AufgabenEs kann für Ihre Teammitglieder verführerisch sein, einfache Aufgaben zuerst zu erledigen, denn das erlaubt es ihnen, sie aus dem Product Backlog zu streichen und die Liste zu verkürzen. Allerdings wäre das aus der Perspektive des Projektmanagements nicht effizient. Es werden immer wieder neue Einträge im Product Backlog hinzukommen, daher ist es für die Produktentwicklung am effektivsten, komplexe Aufgaben zuerst zu erledigen.
Agile Teams erledigen ihre Arbeit im Rahmen zielgerichteter, zeitlich begrenzter Sprints. Mit dieser Herangehensweise kann die Produktivität besonders effektiv gefördert werden. Am Ende eines jeden Sprints überprüfen die für das Produkt verantwortliche Person und alle Beteiligten gemeinsam mit Ihnen und dem Entwicklerteam bei einem Sprint-Rückblick, ob alles planmäßig läuft.
Die Kommunikation zwischen Teammitgliedern ist ein wesentlicher Teil der Priorisierung Ihrer Backlog-Einträge. Damit Sie Ihren Backlog erfolgreich sortieren und die Einträge in einem angemessenen Zeitraum erledigen können, müssen Sie und Ihr Team zusammenarbeiten und sich an den Scrum Guide halten.
Lesenswert: 12 Tipps für eine effektive Kommunikation am ArbeitsplatzProdukt-Backlogs sehen von Projekt zu Projekt unterschiedlich aus, aber manche von ihnen beginnen gleich, nämlich mit einem Epic. Ein Epic ist ein übergeordnetes Problem, das Sie für einen Kunden lösen wollen. Sehen wir uns das am besten anhand von einem Product Backlog Beispiel an:
Epic: Als Marketingmanager möchte ich ein System für das Content-Management, das es mir ermöglicht, meinen Lesern qualitative Texte zu bieten.
Dieser Epic könnte die Entwicklung unterschiedlicher Produktfunktionen zur Folge haben, beginnend dabei, wie ein Nutzer Content im neuen System erstellt, bis hin zu Bearbeitungsfunktionen und der Möglichkeit, Inhalte mit Teammitgliedern zu teilen. Sehen wir uns das anhand unseres beispielhaften Product Backlogs an. Wir können den Epic in spezifischere User-Storys aufteilen:
Story 1: Als Content-Ersteller möchte ich ein Content-Management-System, das es mir ermöglicht, Inhalte zu erstellen, damit ich Kunden über unser Produkt informieren kann.
Story 2: Als Korrekturleser möchte ich ein Content-Management-System, das es mir ermöglicht, Inhalte vor deren Veröffentlichung zu überprüfen, damit ich sicherstellen kann, dass sie gut geschrieben und für Suchmaschinen optimiert sind.
Ausgehend von den Product Backlog User-Stories werden die für das Produkt verantwortliche Person, der Scrum-Master und das Entwicklerteam bestimmte Funktionen für die Entwicklung auswählen und je nach Wichtigkeit priorisieren.
Für Story 1 sollte das Produkt diese Funktionen umfassen:
Anmeldung beim Content-Management-System
Content-Erstellung
Content-Bearbeitung
Speichern der Änderungen
Zuweisung an einen Korrekturleser zur Überprüfung
Als Produktmanager orientieren Sie sich bei der Erstellung Ihres Produktfahrplans und Ihrer Backlog-Liste an Epics. Wie Sie an diesem Product Backlog Beispiel sehen, kann ein Epic zu mehreren User-Storys und Produktfunktionen führen.
Kostenfreie Asana-Vorlagen entdeckenEin Product Backlog verbessert die Organisation und Zusammenarbeit und lässt Ihr Team funktionieren wie eine gut geölte Maschine. Er ist das zentrale Tool für die Kommunikation, klärt Erwartungen und sorgt dafür, dass alle auf die gemeinsamen Ziele hinarbeiten.
Da alle Arbeitsvorgänge für ein Produkt in Ihrem Backlog erfasst werden, ist er auch die Basis für die Planung des iterativen Prozesses. Bei der Priorisierung der Aufgaben bekommt Ihr Team auch ein Gefühl dafür, wieviel Arbeit es in einem bestimmten Zeitfenster erledigen kann. Diese Zeitfenster werden Iterationen oder Sprints genannt.
Der Product Backlog fördert außerdem die Weiterentwicklung Ihres Agile-Teams, da er ein flexibles und dennoch produktives Arbeitsumfeld schafft. Aufgaben im Product Backlog sind nicht in Stein gemeißelt: Das Team kann sie nach Wichtigkeit sortieren und dann bestimmen, welche To-dos es zuerst in Angriff nimmt.
Lesenswert: Den iterativen Prozess verstehen (mit Beispielen)Wenn Sie ein Product Backlog erstellen möchten, sollten Sie auch beachten, dass dieses regelmäßig gepflegt wird. Ganz im Sinne der Agile-Methode sollte kein Product Backlog in Stein gemeißelt sein. Es bedarf einer ständigen Aktualisierung an die aktuellen Gegebenheiten. Folgende Situationen sollten idealerweise nicht bei Ihrem Team vorkommen:
Das Product Backlog wird nicht angepasst: Es ist die Aufgabe des Product Owners, sich im besten Fall vor jedem Meeting mit dem Product Backlog auseinanderzusetzen und zu überprüfen, ob die Priorisierung auch weiterhin so ist, wie auf dem Plan verzeichnet.
Das Product Backlog ist nicht für alle Beteiligten zugänglich: Wichtig ist aber auch, dass alle beteiligten Personen Einsicht darüber haben, welche Aktualisierungen am Product Backlog vorgenommen werden. Somit können diese auch ihre Arbeit anpassen.
Das Product Backlog wird zu schnell angepasst: Genauso wie es zu wenig Aktualisierungen geben kann, sind auch zu viele Aktualisierungen in einem kurzen Zeitrahmen nicht hilfreich. Wenn das Entwicklerteam mit einer Aufgabe begonnen hat, sollte der Product Owner die Veränderungen an dieser Aufgabe dementsprechend gering halten. Dies würde ansonsten den Workflow des Teams stören.
Sprint-Backlogs und Product Backlogs sind sich hinsichtlich ihres Aufbaus sehr ähnlich. Sprint-Backlogs sind eine Untergruppe von Product Backlogs und werden gezielt während Sprints genutzt.
Die für das Produkt verantwortliche Person ist für den Product Backlog zuständig, denn dieser sogenannte Product Owner begleitet das Produkt von Anfang bis Ende durch den gesamten Entwicklungsprozess. Das Entwicklerteam ist für die einzelnen Sprint-Backlogs verantwortlich, denn diese kleineren To-do-Listen, die sich vom Product Backlog ableiten, müssen von den Entwicklern in einem bestimmten Zeitrahmen erledigt werden.
Der Sprint-Backlog ist also vom Product Backlog abhängig und endet dann, wenn der Sprint endet. Mit dem Ende eines Sprints beginnen die nächsten Sprints und so weiter. Ein Sprint-Backlog hat auch ein eigenes Sprint-Ziel, das während der Sprint-Planung festgelegt wird. Beim Product Backlog geht es hingegen um das gesamte Ziel des Produkts – und alle Aufgaben werden auf Basis dieses übergeordneten Ziels priorisiert.
Das Product Backlog ist im Vergleich zum Sprint-Backlog flexibler und kann abhängig von den Kundenbedürfnissen unterschiedlich aussehen. Außerdem bleibt der Product Backlog bestehen, bis das Produkt vollständig entwickelt wurde und muss bis dahin auch laufend aktualisiert werden.
Werfen wir noch einmal einen Blick auf unser Product Backlog Beispiel. Wir können in diesem Fall nämlich auch einen beispielhaften Sprint-Backlog erstellen. Nehmen wir an, es soll eine Funktion für Automobile entwickelt werden, die es Menschen ermöglicht, ein Auto nur mit den Händen zu fahren. Eine Aufgabe im Product Backlog ist es, einen Prototypen für diese Funktion zu erstellen. Dieser Prototyp könnte in einem Sprint hergestellt werden, da einige Unteraufgaben für die erfolgreiche Abwicklung der Aufgabe notwendig sein werden.
Einträge im Sprint-Backlog für den Prototypen könnten sein:
Erstes Konzept erstellen
Virtuellen Prototyp entwickeln
Physischen Prototyp entwickeln
Hersteller für den Bau des Prototyps ausfindig machen
Diese Einträge im Sprint-Backlog würden auch im Product Backlog erfasst werden. Ein eigener Sprint-Backlog kann Entwickler aber beim Scrum-Prozess unterstützen, da sie so diese Aufgaben erledigen und den Prototyp schnell fertigen können.
Die erfolgreiche Erstellung eines Produkts ist einfacher, wenn Sie mit einem gut durchdachten Produkt-Backlog arbeiten. Asana unterstützt Sie dabei, agile Projekte mithilfe moderner Scrum-Software so effizient wie nur irgendwie möglich zu managen.
Agile Teams mit Asana managen