Lastenheft und Backlog: Anforderungen richtig festhalten

Rund um Anforderungen begegnen einem drei Begriffe. Sie beschreiben nicht dasselbe, hängen aber eng zusammen – und zwei davon gehören zur klassischen, einer zur agilen Welt:

Im klassischen Vorgehen beschreibt das Lastenheft die Wünsche des Auftraggebers, das Pflichtenheft die Antwort der Agentur darauf – beide möglichst vollständig und im Voraus. Im agilen Vorgehen tritt an ihre Stelle das Product Backlog: keine einmalige Spezifikation, sondern eine fortlaufend gepflegte Liste. Beide Welten halten dieselben inhaltlichen Anforderungen fest – nur in unterschiedlicher Form und zu unterschiedlichen Zeitpunkten.

Kurz gesagt:  Lastenheft (was der Auftraggeber will) und Pflichtenheft (wie die Agentur es umsetzt) gehören zur klassischen Welt. Das Backlog ist ihr agiles Gegenstück: eine lebende, priorisierte Liste. Der Inhalt der Anforderungen ist überall ähnlich – die Form unterscheidet sich.

in Lastenheft beschreibt aus Sicht des Auftraggebers vollständig und im Voraus, was das Projekt leisten soll. Es entsteht, bevor eine Agentur beauftragt wird, und bildet die Grundlage, auf der Agenturen ein Angebot kalkulieren und das Projekt später umsetzen. Der Grundgedanke: Erst wird zu Ende gedacht, was gebraucht wird, dann wird gebaut.

Seine große Stärke ist die Verbindlichkeit. Was im Lastenheft steht, ist vereinbart, kalkulierbar und einklagbar. Beide Seiten wissen von Anfang an, worüber gesprochen wird: Der Auftraggeber bekommt ein festes Angebot, die Agentur eine klare Grundlage für Aufwand und Preis. Das macht das Lastenheft besonders wertvoll, wenn ein fixes Budget eingehalten werden muss, wenn mehrere Agenturen vergleichbare Angebote abgeben sollen oder wenn, wie bei öffentlichen Ausschreibungen, eine formale, dokumentierte Grundlage vorgeschrieben ist.

Sein Preis ist die Starrheit. Ein Lastenheft ist nur so gut wie das Wissen zum Zeitpunkt, an dem es geschrieben wurde. Stellt sich mitten im Projekt heraus, dass eine Anforderung anders gedacht werden muss, bedeutet das Nachverhandlung, Change Request und meist zusätzliche Kosten. Wer noch nicht genau weiß, wohin die Reise geht, gießt mit einem detaillierten Lastenheft möglicherweise Annahmen in Beton, die sich später als falsch erweisen.

Wie ein Lastenheft aufgebaut ist

Ein Lastenheft ist typischerweise nach Themen gegliedert und arbeitet sich von den Zielen zum Detail vor. Eine bewährte Struktur:

• Ausgangslage und Ziele — warum das Projekt, was soll es erreichen

• Ist-Zustand — was bisher existiert und warum es abgelöst wird

• Zielgruppen und Anwendungsfälle — für wen und wofür

• Funktionale Anforderungen — was das System können muss

• Nicht-funktionale Anforderungen — Performance, Sicherheit, Barrierefreiheit, Datenschutz

• Technische Rahmenbedingungen — Systeme, Schnittstellen, Vorgaben

• Rahmen — Budget, Termine, Art der Zusammenarbeit

Die Checkliste weiter unten liefert genau diese Themen als abarbeitbare Punkte.

Wie Anforderungen im Lastenheft formuliert werden

Anders als die knappen User Stories eines Backlogs werden Anforderungen im Lastenheft meist in ganzen, präzisen Sätzen ausformuliert — oft mit dem Wort „muss" oder „soll", das den Grad der Verbindlichkeit anzeigt. Ein Beispiel:

Das System muss es Redakteurinnen ermöglichen, Bilder per Drag-and-drop hochzuladen. Unterstützt werden müssen die Formate JPG, PNG und WebP bis 10 MB.

Man sieht den Unterschied zur agilen User Story („Als Redakteurin möchte ich Bilder per Drag-and-drop hochladen, um Beiträge schneller zu bebildern"): Das Lastenheft beschreibt die Anforderung als Festlegung, die User Story die Anforderung als Bedürfnis mit Nutzen. Beide meinen dieselbe Funktion, aber das Lastenheft legt sie fest, die User Story lädt zum Gespräch darüber ein, wie sie am besten umgesetzt wird.

Ein häufiger Fehler an genau dieser Stelle: zu früh die Lösung statt des Ziels zu beschreiben. „Wir brauchen ein Akkordeon-Element auf der Startseite" ist eine Lösung — „Nutzer sollen häufige Fragen schnell überblicken können, ohne zu scrollen" ist das Ziel. Ein gutes Lastenheft beschreibt das Ziel und überlässt der Agentur die beste Umsetzung. Das ist zugleich die Brücke zur agilen Denkweise, wo genau dieser Nutzen-Fokus im Zentrum steht.

Im agilen Vorgehen wird nicht alles im Voraus spezifiziert. Stattdessen sammelt das Product Backlog alle Anforderungen als einzelne Einträge, sortiert nach Wichtigkeit. Die obersten, wichtigsten Einträge sind fein ausgearbeitet und kommen als Nächstes dran; weiter unten stehen gröbere Ideen, die später konkretisiert werden. Das Backlog ist nie „fertig“, es wird während des gesamten Projekts gepflegt, ergänzt und neu priorisiert.

User Stories: Anforderungen aus Nutzersicht

Die einzelnen Einträge eines Backlogs werden oft als User Stories formuliert, kurze Beschreibungen einer Anforderung aus Sicht der Nutzenden, meist nach dem Muster:

Als [Rolle] möchte ich [Ziel], um [Nutzen].

Ein Beispiel aus einem CMS-Projekt:

Als Redakteurin möchte ich Bilder per Drag-and-drop hochladen, um Beiträge schneller zu bebildern.

Der Vorteil: Jede Anforderung ist an einen konkreten Nutzen gekoppelt. Das hält den Blick auf dem Ziel, statt auf einer Funktionsliste, deren Zweck niemand mehr kennt. Ergänzt werden User Stories oft um Akzeptanzkriterien: klare Bedingungen, wann die Anforderung als erfüllt gilt.

Priorisierung: das Herz des Backlogs

Weil ein Backlog nie alles auf einmal umsetzt, ist die Reihenfolge entscheidend. Eine verbreitete Methode ist MoSCoW, die Anforderungen in vier Stufen einteilt:

• Must have: unverzichtbar – ohne diese Punkte funktioniert das Projekt nicht.

• Should have: wichtig, aber nicht überlebensnotwendig – sollte mit rein, wenn irgend möglich.

• Won’t have (for now): bewusst zurückgestellt – vielleicht später, aber nicht jetzt.

Kurz gesagt:  Ein Backlog ist eine lebende, priorisierte Liste von Anforderungen – oft als User Stories aus Nutzersicht formuliert und nach Wichtigkeit

• Vergleichbare Angebote: Nur wer klar beschreibt, was er will, bekommt Angebote, die sich wirklich vergleichen lassen.

• Weniger Nachforderungen: Was von Anfang an festgehalten ist – im Lastenheft ausformuliert oder im Backlog priorisiert –, führt später seltener zu Streit.

• Gemeinsames Verständnis: Beide Formen zwingen dazu, vage Ideen zu konkretisieren – oft der Moment, in dem interne Unklarheiten auffallen.

• Fairer Maßstab: Am Ende lässt sich prüfen, ob das Ergebnis dem entspricht, was vereinbart bzw. priorisiert war.

Kurz gesagt:  Egal ob Lastenheft oder Backlog – die inhaltlichen Fragen sind dieselben: Warum das Projekt, für wen, mit welchen Inhalten, Funktionen, welcher Technik und welchem Design. Nur Form und Zeitpunkt unterscheiden sich.

• Zu technisch statt zielorientiert: Beschreibt, was Ihr erreichen wollt, nicht wie es die Agentur bauen soll – die Lösung ist ihre Aufgabe.

• Keine Priorisierung: Wenn alles „Muss“ ist (oder im Backlog alles ganz oben steht), wird jedes Angebot teuer und unflexibel.

• Lückenhaft bei Inhalten und Schnittstellen: Inhaltsmigration und Systemanbindungen werden oft unterschätzt – und sind häufig die größten Aufwandstreiber.

• Form und Vorgehen passen nicht zusammen: Ein bis ins Detail betoniertes Lastenheft für ein agiles Projekt – oder ein vages Backlog, wo ein fester Kostenrahmen gebraucht wird – sorgt für Reibung.

Ein durchdachtes Lastenheft oder ein gut priorisiertes Backlog ist die beste Grundlage, um Agenturen anzufragen und Angebote zu vergleichen. Es zeigt der Agentur, dass Ihr wisst, was Ihr wollt – und macht die Zusammenarbeit von Anfang an konkreter. Der Agenturradar listet zertifizierte Implementierungsagenturen im DACH-Raum, filterbar nach System, Standort, Branche und Teamgröße.