User Stories oder Lastenheft: Wie du Anforderungen für ein Festpreis-Projekt formulierst

Ein Entwicklungspartner schlägt vor, deine Anforderungen als "User Stories" aufzunehmen. Ein anderer verlangt ein vollständiges Lastenheft. Beides ist ein legitimer Weg, Anforderungen festzuhalten, aber die beiden Formate haben unterschiedliche Stärken. Für ein Festpreis-Projekt ist die Frage konkret: Welches Format gibt dir und dem Dienstleister genug Klarheit, um einen verbindlichen Preis zu nennen, ohne dass dir später Nachträge drohen?

Was eine User Story ist

Eine User Story beschreibt eine Anforderung aus Sicht einer Person, die mit der Software arbeitet. Die gängige Form lautet:

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

Ein Beispiel: "Als Disponentin möchte ich offene Aufträge nach Lieferdatum sortieren, damit ich dringende Lieferungen zuerst sehe."

Der Vorteil liegt in der Verständlichkeit. Eine Story kommt ohne Fachsprache aus, benennt den Nutzen und lässt sich mit Fachabteilungen besprechen, die kein technisches Vokabular mitbringen.

Was eine User Story nicht leistet

Eine einzelne Story lässt Details offen: Welche Sortierungen gibt es außer Lieferdatum? Was passiert bei Aufträgen ohne Lieferdatum? Wie viele Aufträge muss die Liste gleichzeitig darstellen? Im agilen Vorgehen werden diese Fragen im Gespräch während der Umsetzung geklärt. Bei einem Festpreis fehlt dieser Spielraum, denn der Preis wurde schon vor der Umsetzung festgelegt. Offene Details sind dann der Ort, an dem Streit über den Leistungsumfang entsteht.

Eine Sammlung von Stories enthält außerdem keine Aussagen zu Anforderungen, die das ganze System betreffen: Antwortzeiten, Datenschutz, Verfügbarkeit, Browser- und Geräteunterstützung, Schnittstellen zu Bestandssystemen. Das Lastenheft führt solche nicht-funktionalen Anforderungen als eigenen Abschnitt. Welche Gliederung und Normen dafür gebräuchlich sind, beschreibt der Artikel IEEE 830 & Co: Welche Normen für Lastenheft und Pflichtenheft wirklich gelten.

Akzeptanzkriterien machen aus einer Story eine prüfbare Anforderung

Der Schlüssel zur Verbindlichkeit sind Akzeptanzkriterien: konkrete, prüfbare Aussagen, die erfüllt sein müssen, damit die Story als erledigt gilt. Weit verbreitet ist das Format Gegeben / Wenn / Dann:

Gegeben sind fünf offene Aufträge mit unterschiedlichen Lieferdaten,
wenn ich nach Lieferdatum aufsteigend sortiere,
dann steht der Auftrag mit dem frühesten Datum oben.

Weitere Kriterien zur Story decken die Randfälle ab: Aufträge ohne Lieferdatum stehen am Ende der Liste. Die Liste zeigt bis zu 500 Aufträge ohne Nachladen. Jedes Kriterium lässt sich beim Abnahmetest mit Ja oder Nein beantworten, und genau das macht die Story festpreisfähig.

Wann welches Format passt

Situation	Passendes Format
Klar umrissenes Projekt, fester Preis, feste Frist	Lastenheft mit Anforderungen, ergänzt um Akzeptanzkriterien
Produkt, dessen Funktionsumfang sich im Betrieb entwickelt	User Stories mit laufender Priorisierung, Abrechnung nach Aufwand
Festpreis für ein erstes Release, danach Weiterentwicklung	Lastenheft für Release 1, danach Stories für den Backlog
Fachabteilung ohne technisches Vorwissen formuliert Bedarf	Stories als Gesprächsgrundlage, dann Überführung ins Lastenheft

Die Wahl des Formats hängt also mit dem Vertragsmodell zusammen. Wie sich Festpreis und Abrechnung nach Aufwand unterscheiden, erklärt der Artikel Festpreis vs. Time & Material.

So kombinierst du beide Formate für ein Festpreis-Projekt

Ein Vorgehen, das beide Stärken nutzt:

Ziel und Rahmen ins Lastenheft. Beschreibe Ausgangslage, Ziel, beteiligte Rollen und systemweite Anforderungen wie Datenschutz, Performance und Schnittstellen.
Funktionen als User Stories formulieren. Jede Funktion bekommt eine Story mit Rolle, Ziel und Nutzen. Das zwingt dich, den Zweck jeder Funktion zu benennen, und deckt Funktionen auf, die niemand braucht.
Akzeptanzkriterien ergänzen. Zu jeder Story gehören die prüfbaren Kriterien inklusive der Randfälle. Fehlen Kriterien, ist die Story noch nicht preisbar.
Priorisieren. Teile die Stories in "muss zum Launch da sein" und "kann in Release 2". Das schafft Verhandlungsspielraum, ohne den Festpreis des ersten Releases zu gefährden.
Im Pflichtenheft gegenprüfen. Der Entwicklungspartner beschreibt, wie er jede Story umsetzt. Weicht seine Lesart von deiner ab, fällt das jetzt auf und nicht bei der Abnahme.

Lücken, auf die du bei Stories prüfen solltest

Prüfe eine Story-Sammlung auf diese Lücken:

Fehlerfälle fehlen. Es steht drin, was passiert, wenn alles klappt, nicht aber, was bei ungültigen Eingaben oder Verbindungsabbrüchen geschieht.
Rollen und Rechte sind unklar. Wer darf eine Aktion ausführen, wer darf sie nur ansehen?
Bestehende Daten fehlen. Eine Funktion zeigt Aufträge an, aber ob und wie die Altdaten aus dem bisherigen System migriert werden, steht nirgends.
Begriffe sind uneinheitlich. "Kunde", "Auftraggeber" und "Debitor" bezeichnen in einem Dokument dasselbe oder drei verschiedene Dinge.

Eine Liste dieser Punkte als Checkliste beim Schreiben spart später Nachtragsverhandlungen.

Fazit

User Stories und Lastenheft stehen nicht in Konkurrenz. Stories machen Anforderungen verständlich und nutzenorientiert, das Lastenheft liefert den Rahmen und die systemweiten Anforderungen, und Akzeptanzkriterien verbinden beides mit der Abnahme. Für einen Festpreis sollte jede Story prüfbare Kriterien haben, bevor der Preis feststeht.

Häufig gestellte Fragen

Kann ich ein Festpreis-Projekt nur mit User Stories beauftragen?

Ja, sofern jede Story prüfbare Akzeptanzkriterien hat und die systemweiten Anforderungen separat festgehalten sind. Ohne diese Ergänzungen bleiben zu viele Details offen, um einen verbindlichen Preis zu nennen.

Wie detailliert müssen Akzeptanzkriterien sein?

Detailliert genug, dass zwei Personen beim Test zum selben Ergebnis kommen. Wenn ein Kriterium Raum für Interpretation lässt, gehört es konkretisiert, etwa durch Zahlen, Beispiele oder Grenzwerte.

Ersetzt ein Pflichtenheft die User Stories?

Nein. Das Lastenheft beschreibt, was du brauchst. Im Pflichtenheft beschreibt der Dienstleister, wie er es umsetzt. Stories gehören zur Seite der Anforderungen und werden im Pflichtenheft aufgegriffen. Den Unterschied erklärt der Artikel Lastenheft vs. Pflichtenheft.

Wie viele User Stories braucht ein Projekt?

Das hängt vom Funktionsumfang ab. Wichtiger als die Anzahl ist, dass jede Funktion, für die du zahlst, durch mindestens eine Story mit Akzeptanzkriterien abgedeckt ist.