Was sind Backlogs?

Backlogs. Anforderungen agil definieren und umsetzen.

Was versteht man unter einem Backlog? Welche Arten von Backlogs gibt es und welche Vorteile bieten sie?

tooltip text
1

Große Unternehmen weisen oft große Abteilungen auf - und an der Softwareentwicklung können unterschiedliche Bereiche bzw. Domänen beteiligt sein, die unterschiedliche Anforderungen umsetzen müssen. Auf diese Weise entstehen Domänen Backlogs.

2

Die Reihenfolge der Umsetzung der Anforderungen ergibt sich aus der Priorisierung mit entsprechender Zuordnung zu den Release Backlogs.

3

Arbeiten Sie mit mehreren Teams, verteilen Sie die Anforderungen auf die Team Backlogs. Diese Organisation der Backlogs ist angelehnt an das Konzept von Scrum of Scrums. Wenn Sie mit einem einzigen Team arbeiten, ist nur ein Backlog notwendig. Das Release Backlog ist dann gleichzeitig das Team Backlog.

Ein Backlog ist kein Lastenheft

Wenn Sie an Anforderungen und Anforderungsmanagement in der Softwareentwicklung denken, dann fallen Ihnen wahrscheinlich sofort das Lasten- oder Pflichtenheft ein – Dokumente, in denen die geforderten Funktionalitäten vom Auftraggeber oder Softwarehersteller niedergeschrieben, dann überprüft und abgenommen werden. Fertig. Aber können sich Anforderungen an die Software nicht während der Entwicklung ändern, sodass das Projektteam diese entsprechend anpassen und anders priorisieren muss? Natürlich, deswegen haben sich in den vergangenen Jahren agile Projektmanagement-Methoden entwickelt und deswegen arbeitet diese mit anderen Hilfsmitteln: mit Backlogs.

Definition Backlog

Ein Backlog ist zunächst eine Liste von Aufgaben bzw. Anforderungen, die ein Team abarbeiten muss.

So managen Sie Backlogs einfach mit Tool

Probieren Sie es aus mit der
kostenlosen Trial objectiF RPM »

objectiF RPM

Product Backlog

Das Product Backlog (manchmal auch als Domäne Backlog bezeichnet: immer dann, wenn es pro Domäne ein Backlog gibt) ist der Kern eines Scrum-Projekts, denn es sammelt Anforderungen, die die Software erfüllen muss. Das können zum Beispiel Funktionalitäten oder Bugs sein, die das Team implementieren bzw. beheben soll. Meistens bedient man sich sogenannter User Stories, um sie zu beschreiben. Das heißt zum Beispiel, dass eine neue Funktionalität aus der Sicht der Zielgruppe definiert wird:

„Als Besucher der Website möchte ich eine Suchfunktion nutzen können, mit der ich die gesamte Seite durchsuchen kann, damit ich schnell Antworten auf meine Fragen finde.“

Doch nicht alle Anforderungen sind gleich wichtig oder gleich aufwändig: Sie erhalten eine Priorisierung und eine Aufwandsschätzung, wodurch sie entweder so schnell wie möglich umgesetzt oder erst einmal weiter nach hinten geschoben werden. Diese Aufgabe erledigt das Entwicklerteam zusammen mit dem sogenannten Product Owner, dem Ansprechpartner aller Stakeholder des Projekts: Während dieser typischerweise die Priorität der Anforderungen basierend auf Faktoren wie dem Geschäftswert abwägt, bewerten die Entwickler den Umsetzungsaufwand. Diese Schätzung entspricht zumeist keiner absoluten Größe wie z.B. „Diese Anforderung wird vier Personentage dauern“. Stattdessen bedient man sich relativer Werte wie Fibonacci-Zahlen: Eine Anforderung mit einem Aufwand von 2 ist schneller erledigt als eine mit einem Aufwand von 5. Am Ende entsteht eine Liste, in der die Anforderungen nach ihren Prioritäten sortiert sind.

Wenn ein Projekt mehrere Teams umfasst, können die Aufgaben den jeweiligen Teams zugeteilt und somit Team Backlogs geschaffen werden. Sollte es nur ein Team geben, dann entspricht das Product Backlog ebenfalls dem Team Backlog.

Lesen Sie hier, um mehr über Scrum zu erfahren »

Release Backlog

Ein Scrum-Projekt gliedert sich nach Sprints und Releases. Zum Beispiel erfolgt nach drei Sprints das erste Release der Software. Danach folgen drei weitere Sprints und ein weiteres Release. Anforderungen werden automatisch basierend auf ihren Prioritäten den jeweiligen Releases zugeordnet. Dafür setzt man sogenannte Prioritätsgrenzen ein: Beispielsweise gibt es vier Anforderungen mit den Prioritäten 100, 101, 102 und 103. Für das Release 1.2 bestimmt der Product Owner eine Untergrenze von 102. Dadurch landen lediglich die Anforderungen mit den Prioritäten 102 und 103 in dem Release. Gibt es noch weitere Anforderungen mit Prioritäten wie 105 oder 107, dann landen diese auch im Release 1.2. Auf diese Weise entstehen für die einzelnen Releases die sogenannten Release Backlogs.

So planen Sie Ihre Projekte mit Backlogs »

Sprint Backlog

Ist das erste Product Backlog erstellt, ordnet das Team die Anforderungen dem kommenden Sprint zu, d.h. der nächsten Iteration in der Entwicklung. Welche Anforderungen sollen zum Beispiel in den kommenden zwei Wochen umgesetzt werden? Das Team wählt aus dem Product Backlog die User Storys mit den höchsten Prioritäten aus – also Anforderungen, die ganz oben in der Liste stehen – während es gleichzeitig abschätzt, ob sie sich in dem Zeitraum realisieren lassen. Wenn eine User Story zu umfangreich ist, teilt es diese Story in kleinere Aufgaben – sogenannte Tasks – auf. Um dann noch einen Überblick zu über den aktuellen Stand der Umsetzung zu haben, bedient man sich oftmals eines Task Boards: Einzelne Tasks werden ähnlich wie Post-its behandelt, die man in die Spalte ihres jeweiligen Zustandes wie to do oder done „klebt“. In professionellen Softwarelösungen erfolgen diese Schritte elektronisch.

Agile Methoden wie Scrum unterscheiden verschiedene Arten von Backlogs: Product Backlog, Release Backlog und Sprint Backlog.

Priorisierung – aber wie am besten?

Umfangreiche Projekte schaffen umfangreiche Backlogs – und nicht immer ist klar, welche Anforderungen am wichtigsten sind oder wie sie im Vergleich zu ähnlichen zu bewerten sind. Daher lassen sich Methoden einsetzen, die eine Priorisierung erleichtern. Mit Hilfe des Kano-Modells klassifiziert man zum Beispiel Funktionen nach Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren. Diese Klassifikation basiert auf einer Umfrage unter den Anwendern:

Gibt es Funktionen, die ein Anwender in einem Kontext immer erwartet? Formatierungsoptionen in einem Text-Editor zum Beispiel? Dann weist diese Funktionalität einen hohen Basisfaktor auf und muss umgesetzt werden. Handelt es sich um eine zusätzliche Funktion, um die das Produkt erweitert wird, erzielt die Anforderung einen höheren Leistungsfaktor. Stellt sie aber, wie die Österreicher so schön sagen, “nur ein besonderes Schmankerl” dar, dann kann die Funktion den Anwender begeistern. Auf diese Weise wissen die Entwickler und der Product Owner, welche Anforderungen sie im aktuellen Projektkontext priorisieren sollten.

Ähnlich geht das MoSCoW-Prinzip vor. Denn es unterscheidet u.a. zwischen Funktionen, die Entwickler auf jeden Fall umsetzen sollten und welche, die sie nur implementieren könnten:

Must: Must-Have Funktionalitäten, die umgesetzt werden müssen
Should: Funktionalitäten, die nach den Must-Haves umgesetzt werden
Could: Funktionalitäten, die umgesetzt werden können, wenn sie keine Must-Haves oder Should-Funktionen damit beeinträchtigen
Won’t: Funktionalitäten, die erst einmal nicht umgesetzt werden.

Download Projektplanung und Projektkontrolle in agilen und hybriden Projekten Whitepaper

Wissen zum Mitnehmen

Alles über agile Projektplanung mit Backlogs

PDF zum Download »

Mehr Downloads rund ums Thema

  • Whitepaper
  • Tipps & Tricks
  • Software

Zum Downloadcenter »

Das Backlog verbindet das Entwicklerteam mit dem Product Owner. Er kann die Prioritäten der Anforderungen jederzeit anpassen, wenn es die Stakeholder verlangen.

Die Vorteile zusammengefasst

Der Product Owner passt also zusammen mit den Entwicklern das Product Backlog und damit Priorisierungen immer wieder an, um den aktuellen Umständen und Wünschen der Stakeholder gerecht zu werden. So passiert es auch, dass sie Anforderungen ganz verwerfen. Dieses Product Backlog Refining (auch Grooming genannt) ermöglicht es, auf Änderungen schnell und flexibel zu reagieren. Gleichzeitig haben die Entwickler stets eine klare Übersicht der Aufgaben, die sie abarbeiten müssen. Auf diese Weise gibt es nur eine Quelle der Informationen und Missverständnisse lassen sich reduzieren. Stakeholder wissen ebenfalls immer, an welchen Anforderungen das Team gerade arbeitet – und jeder Projekteilnehmer kann sich sicher sein, dass die wichtigsten Aufgaben aktuell bearbeitet werden. Zusammengefasst bieten Backlogs folgende Vorteile:

  • Backlogs erzeugen Transparenz über erfasste Features, Epics, Use Cases, Use Case Slices und User Stories.
  • Backlogs strukturieren die Entwicklung von Applikationen, Produkten und softwareintensiven Systemen sowohl inhaltlich als auch zeitlich.
  • Backlogs erfordern eine regelmäßige, eindeutige Priorisierung und sorgen in der Folge für eine hohe Akzeptanz der Stakeholder.
  • Backlogs sind ein sehr gutes Arbeitsmittel für die beteiligten Rollen und Mitarbeiter.
  • Backlogs sind stets aktuell und zeigen, woran gerade gearbeitet wird.