User Stories: Anforderungen aus Sicht der Nutzenden formulieren
https://bildung.social/@oerinformatik/
https://oer-informatik.de/user-stories
User Stories, Anforderungsanalyse, Connextra-Schablone, INVEST, Akzeptanzkriterien, Given When Then, Epic, Product Backlog, Scrum
tl/dr; (ca. 20 min Lesezeit): User Stories beschreiben Anforderungen in einem Satz aus Sicht der Nutzenden: Wer möchte was, und wozu? Der Artikel zeigt die Satzschablone, wer Stories schreibt, wie Du sie mit den INVEST-Kriterien und Akzeptanzkriterien prüfbar machst, wie Du sie aus Anwendungsfällen ableitest, zu große Stories schneidest und welche Rolle sie im Product Backlog spielen. Am Ende stehen die wichtigsten englischen Fachbegriffe für Aufgabentexte [AI-Assisted]. (Zuletzt geändert am 28.10.2026)
Dieser Artikel baut auf der Kann-Liste des Artikels Anforderungsanalyse auf. Wie Anforderungen in Lasten- und Pflichtenheft dokumentiert werden, zeigt der Artikel Anforderungen dokumentieren.
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Als Grundlagen zu User Stories kann ich nach Durchlesen des Artikels…
… erklären, was eine User Story ist und wozu sie in agilen Projekten dient.
… nennen, wer User Stories schreibt und wer für sie verantwortlich ist.
… den Aufbau einer User Story nach der Satzschablone „Als … möchte ich …, damit …“ erläutern und eigene User Stories formulieren.
… die sechs INVEST-Kriterien erläutern und eine User Story damit beurteilen.
… aus einem Anwendungsfall mit «include»- und «extend»-Beziehungen eine User Story ableiten.
… typische Fehler in User Stories erkennen und die Story verbessern.
… die Aufgabe des Product Backlogs erläutern und begründen, warum agile Projekte oft User Stories statt eines vollständigen Pflichtenhefts nutzen.
… englische Fachtexte zu User Stories verstehen und daraus Fragen beantworten.
Darüber hinaus kann ich als Expertenwissen zu User Stories…
… Akzeptanzkriterien im Format Given – When – Then formulieren und von der Definition of Done abgrenzen.
… zu große Stories (Epics) fachlich sinnvoll in kleinere Stories schneiden.
… nichtfunktionale Anforderungen so mit User Stories verbinden, dass sie prüfbar bleiben.
… die drei C (Card, Conversation, Confirmation) erklären.
Die Mindmap zeigt die Themen dieses Artikels im Überblick: Satzschablone, die drei C, INVEST, Akzeptanzkriterien, das Schneiden von Epics, den Weg vom Anwendungsfall zur Story und das Product Backlog.
Was ist eine User Story?
Eine User Story (deutsch etwa: Anwendergeschichte) ist eine kurze, informelle Beschreibung einer Anforderung aus Sicht der Personen, die das System nutzen. Sie ist in natürlicher Sprache geschrieben, passt auf eine Karteikarte und sagt drei Dinge: wer etwas möchte, was diese Person tun möchte und wozu sie das braucht.
Als Fachhändlerin möchte ich meine offenen Rechnungen im Portal sehen, damit ich keine Zahlungsfrist verpasse.
Eine User Story beschreibt also ein Bedürfnis, keine technische Lösung. Wie das Portal die Rechnungen anzeigt, welche Tabelle in der Datenbank sie enthält oder welches Framework zum Einsatz kommt, steht nicht darin. Das klärt das Team später, gemeinsam mit den Beteiligten.
User Stories stammen aus der agilen Softwareentwicklung (zuerst aus Extreme Programming, Ende der 1990er-Jahre) und werden heute vor allem in Scrum-Teams genutzt. Der Scrum Guide selbst schreibt User Stories übrigens nicht vor; sie sind aber die mit Abstand häufigste Form, Einträge im Product Backlog zu formulieren.
Eine Story ist ein Versprechen auf ein Gespräch: die drei C
Eine User Story ist bewusst unvollständig. Ron Jeffries hat das 2001 mit den drei C beschrieben:
Card (Karte): Die Story selbst ist so kurz, dass sie auf eine Karteikarte oder ein Ticket passt. Sie ist eine Erinnerung, worüber gesprochen werden muss.
Conversation (Gespräch): Die Details entstehen im Gespräch zwischen Nutzenden, Product Owner und Entwicklungsteam, zum Beispiel im Backlog Refinement.
Confirmation (Bestätigung): Akzeptanzkriterien halten fest, woran alle erkennen, dass die Story fertig umgesetzt ist.
Damit unterscheidet sich eine User Story deutlich von einer Anforderung im Pflichtenheft: Das Pflichtenheft versucht, vorab alles vollständig und verbindlich festzuschreiben. Die User Story hält nur das Wesentliche fest und lässt den Rest bewusst offen, bis die Story umgesetzt wird.
Wer schreibt User Stories?
Verantwortlich für die User Stories im Product Backlog ist in Scrum der Product Owner (in anderen Unternehmen auch Produktmanager*in oder Produktverantwortliche*r). Er oder sie entscheidet, welche Story ins Backlog kommt und in welcher Reihenfolge sie umgesetzt wird.
Schreiben darf eine Story aber grundsätzlich jede*r, die oder der das Produkt und seine Nutzenden kennt:
der Product Owner selbst,
Mitglieder des Entwicklungsteams, die im Gespräch mit Kund*innen einen Wunsch aufnehmen,
Stakeholder wie Fachabteilungen, Pilotkund*innen oder der Kundendienst, oft gemeinsam in einem Story-Workshop.
Wichtig ist: Wer eine Story schreibt, schreibt sie im Auftrag der Nutzenden (englisch: on behalf of the end-user) – also aus deren Blickwinkel, auch wenn sie oder er selbst nicht zu dieser Rolle gehört.
Der Aufbau: die Satzschablone
Die bekannteste Schablone entstand um 2001 bei der britischen Firma Connextra und heißt deshalb auch Connextra-Template:
As a <role>, I want <goal/capability>, so that <benefit>.
Auf Deutsch:
Als <Rolle> möchte ich <Funktion>, damit <Nutzen>.
| Teil | Frage | Hinweise | Beispiel |
|---|---|---|---|
| Rolle (role, type of user) | Wer möchte etwas? | eine konkrete Nutzergruppe, keine Einzelperson und nicht „das System“ oder „der Entwickler“ | Als Fachhändlerin |
| Funktion (goal, capability, task) | Was möchte die Person tun oder erhalten? | eine Tätigkeit aus Nutzersicht, keine technische Umsetzung | möchte ich meine offenen Rechnungen im Portal sehen, |
| Nutzen (benefit, reason) | Wozu braucht sie das? | der Mehrwert oder das Ziel; hilft, bei der Umsetzung die richtigen Entscheidungen zu treffen | damit ich keine Zahlungsfrist verpasse. |
Der Nutzen wird gern weggelassen oder mit einer leeren Floskel gefüllt („damit es funktioniert“, „damit die Zeit korrekt ist“). Genau dieser Teil ist aber oft der wertvollste: Er verrät, warum etwas gebraucht wird, und eröffnet manchmal eine bessere Lösung. Wer offene Rechnungen sehen will, um keine Frist zu verpassen, freut sich vielleicht noch mehr über eine Erinnerung per E-Mail.
Es gibt Varianten der Schablone, zum Beispiel „Um <Nutzen> zu erreichen, möchte ich als <Rolle> <Funktion>.“ (Nutzen zuerst) oder für technische Systeme „Als <Rolle> brauche ich <Funktion>, …“. In Aufgaben und im Betrieb gilt: Halte Dich an die Schablone, die vorgegeben ist.
Wann ist eine Story gut? Die INVEST-Kriterien
Bill Wake hat 2003 sechs Eigenschaften guter User Stories in dem Merkwort INVEST zusammengefasst:
| Buchstabe | Kriterium | Bedeutung | Prüffrage |
|---|---|---|---|
| I | Independent (unabhängig) | Die Story hängt möglichst nicht von anderen Stories ab und kann in beliebiger Reihenfolge umgesetzt werden. | Kann das Team diese Story umsetzen, ohne auf eine andere zu warten? |
| N | Negotiable (verhandelbar) | Die Story ist kein fester Vertrag. Details werden im Gespräch geklärt und können sich ändern. | Lässt die Story Raum für gemeinsame Lösungsideen? |
| V | Valuable (wertvoll) | Die Story bringt den Nutzenden oder dem Auftraggeber einen erkennbaren Mehrwert. | Würde jemand außerhalb des Teams merken, dass die Story fertig ist? |
| E | Estimable (schätzbar) | Das Team kann den Aufwand abschätzen, weil die Story verständlich und nicht zu vage ist. | Kann das Team sagen, ob die Story eher klein oder groß ist? |
| S | Small (klein) | Die Story ist so klein, dass sie innerhalb eines Sprints fertig wird. | Passt die Story bequem in einen Sprint? |
| T | Testable (testbar) | Es lässt sich eindeutig prüfen, ob die Story erfüllt ist. | Gibt es Akzeptanzkriterien, die man mit Ja oder Nein beantworten kann? |
Die Kriterien hängen zusammen: Eine zu große Story (nicht Small) ist meist auch schwer schätzbar (nicht Estimable); eine Story mit vagen Wörtern wie „schnell“ oder „benutzerfreundlich“ ist nicht Testable.
Wann ist eine Story fertig? Akzeptanzkriterien
Damit eine Story testbar wird, bekommt sie Akzeptanzkriterien (acceptance criteria). Sie beschreiben konkrete Bedingungen, die erfüllt sein müssen, damit der Product Owner die Story abnimmt. Bewährt hat sich das Format Given – When – Then aus dem Behaviour Driven Development (deutsch: Angenommen – Wenn – Dann):
Story: Als Fachhändlerin möchte ich meine offenen Rechnungen im Portal sehen, damit ich keine Zahlungsfrist verpasse.
Akzeptanzkriterium 1: Angenommen, ich habe zwei offene und eine bezahlte Rechnung, wenn ich die Seite „Rechnungen“ öffne, dann sehe ich nur die zwei offenen Rechnungen, sortiert nach Fälligkeit.
Akzeptanzkriterium 2: Angenommen, eine Rechnung ist in weniger als drei Tagen fällig, wenn ich die Liste ansehe, dann ist diese Rechnung farbig hervorgehoben.
Jedes Akzeptanzkriterium ist zugleich die Vorlage für einen Testfall – so wird aus „Testable“ ein konkreter Abnahmetest.
Nicht verwechseln solltest Du Akzeptanzkriterien mit der Definition of Done (DoD): Die DoD gilt für alle Stories gleich und beschreibt die Qualität, die jedes Ergebnis erreichen muss („Code reviewt, Unit-Tests grün, auf dem Testserver installiert, Dokumentation aktualisiert“). Akzeptanzkriterien gelten nur für eine Story und beschreiben ihr fachliches Verhalten.
Typische Fehler und wie Du sie behebst
| Fehler | Beispiel | Besser |
|---|---|---|
| System oder Team als Rolle | „Als System möchte ich nachts die Konditionen importieren.“ | Rolle der Nutzenden suchen, die davon profitiert: „Als Fachhändler möchte ich immer meine aktuellen Konditionen sehen, damit ich verlässlich kalkulieren kann.“ |
| technische Lösung statt Bedürfnis | „Als Kundin möchte ich eine MariaDB-Tabelle für Wunschlisten.“ | „Als Kundin möchte ich Artikel auf eine Wunschliste setzen, damit ich sie später schnell wiederfinde.“ |
| Nutzen fehlt oder ist leer | „…, damit es funktioniert.“ | den echten Grund nennen: „…, damit ich meine Tour planen kann.“ |
| mehrere Funktionen in einer Story | „… möchte ich bestellen, Rechnungen abrufen und Retouren anmelden …“ | in mehrere Stories aufteilen (siehe unten) |
| nicht prüfbar | „… möchte ich, dass die Seite schnell lädt …“ | messbares Akzeptanzkriterium: „Die Trefferliste erscheint in 95 % der Aufrufe in höchstens 2 Sekunden.“ |
| zu viele Details vorweg | Story mit Farbwerten, Pixelangaben und Datenbankfeldern | Details ins Gespräch und in Akzeptanzkriterien oder ein Mockup verlagern |
Zu groß für einen Sprint? Epics schneiden
Eine Story, die zu groß für einen Sprint ist, heißt Epic. Epics sind am Anfang eines Projekts normal („Als Fachhändler möchte ich alles, was ich bisher mit dem alten Bestellprogramm gemacht habe, im Portal erledigen.“). Bevor sie umgesetzt werden, schneidet das Team sie in kleinere Stories. Bewährte Schnitte:
nach Arbeitsschritten im Ablauf: bestellen – Bestellstatus ansehen – Rechnung abrufen,
nach Regeln oder Varianten: Bestellung ohne Rabatt zuerst, Mengenrabatt in einer eigenen Story,
nach Datenarten: erst Fahrräder, dann Komponenten, dann konfigurierbare Artikel,
nach Normalfall und Sonderfall: erst der Standardablauf, dann die Fehlerbehandlung (z. B. „Artikel nicht lieferbar“).
Nicht sinnvoll ist ein Schnitt nach technischen Schichten („Story 1: Datenbank, Story 2: Oberfläche“): Keine dieser Teil-Stories hätte für sich einen Wert für die Nutzenden (Verstoß gegen Valuable), und sie hängen voneinander ab (Verstoß gegen Independent).
Vom Anwendungsfall zur User Story
Liegen bereits Anwendungsfälle vor – etwa in einem UML-Anwendungsfalldiagramm –, lässt sich aus jedem Anwendungsfall eine User Story ableiten:
Rolle = Akteur*in, die oder der mit dem Anwendungsfall verbunden ist,
Funktion = Name des Anwendungsfalls, als Tätigkeit formuliert,
Nutzen = Zweck des Anwendungsfalls für die Akteurin (steht nicht im Diagramm, sondern muss aus dem Kontext erschlossen werden),
«include» = Teilschritt, der immer dazugehört: als Ergänzung „Dabei …“ formulieren,
«extend» = Erweiterung, die nur unter einer Bedingung stattfindet: als Ergänzung „Falls … / Wenn …“ formulieren oder als eigene Story.
Ein Beispiel aus einer Mitfahr-App: Akteurin „Auszubildende“, Anwendungsfall „Fahrt anbieten“ mit «include» „Treffpunkt festlegen“ und «extend» „Rückfahrt anbieten“ (Bedingung: Rückfahrt am selben Tag möglich):
Daraus ergibt sich diese User Story:
Als Auszubildende möchte ich eine Fahrt zum Berufskolleg anbieten, damit ich Spritkosten mit anderen teilen kann. Dabei lege ich immer einen Treffpunkt fest. Falls ich am selben Tag zurückfahre, möchte ich die Rückfahrt gleich mit anbieten, damit ich nicht zweimal inserieren muss.
Ein Anwendungsfalldiagramm zeigt den Überblick über alle Funktionen, eine User Story den Wunsch einer Rolle mit ihrem Nutzen. Beide ergänzen sich; sie ersetzen sich nicht.
User Stories im Product Backlog
In Scrum steht jede Anforderung als Eintrag (Product Backlog Item) im Product Backlog – meist als User Story formuliert. Das Product Backlog ist eine geordnete, dynamische Liste aller bekannten Anforderungen an das Produkt. Neben User Stories stehen dort auch Fehlerbehebungen oder technische Arbeiten, denn der Scrum Guide schreibt keine bestimmte Form der Einträge vor.
Der Product Owner pflegt es und legt die Reihenfolge fest – oben steht, was den größten Wert bringt oder am dringendsten ist.
Neue Wünsche kommen jederzeit als neue Story hinzu; überholte Stories werden gestrichen. Das Backlog ist nie „fertig“.
Oben im Backlog sind die Stories klein, verstanden und geschätzt (oft in Story Points), weiter unten dürfen sie noch grob sein (Epics).
Im Sprint Planning wählen die Developers die obersten Stories für den nächsten Sprint aus; daraus entsteht das Sprint Backlog.
Mehr zu Rollen, Ereignissen und Artefakten findest Du im Artikel über Vorgehensmodelle.
User Stories statt Pflichtenheft?
In agilen Projekten wird häufig auf ein vollständiges Pflichtenheft vorab verzichtet. Stattdessen entstehen User Stories, die in kurzen Abständen umgesetzt, vorgeführt und anhand der Rückmeldungen angepasst werden. Das lohnt sich, wenn
die Anforderungen zu Beginn noch nicht vollständig bekannt sind oder sich voraussichtlich ändern,
Auftraggeber*innen und Nutzende regelmäßig mitarbeiten und Rückmeldung geben können,
früh ein nutzbares Ergebnis gebraucht wird.
Grenzen gibt es auch: Für einen Festpreisvertrag, eine Ausschreibung oder sicherheitskritische Systeme mit Zulassung braucht es weiterhin verbindliche, vollständige Dokumente. Außerdem verlieren viele einzelne Stories leicht den Blick auf das Ganze – hier helfen Epics, ein Produktziel und ergänzende Modelle wie Anwendungsfall- oder Aktivitätsdiagramme.
Und die nichtfunktionalen Anforderungen?
User Stories beschreiben vor allem funktionale Anforderungen. Nichtfunktionale Anforderungen wie Antwortzeit, Verfügbarkeit, Barrierefreiheit oder Datenschutz gehen aber nicht verloren:
Betreffen sie eine Story, werden sie dort als messbares Akzeptanzkriterium festgehalten („Der Schließungscode erscheint nie im Klartext in E-Mails oder Logdateien.“).
Gelten sie für alle Stories, kommen sie in die Definition of Done oder in eine Liste übergreifender Vorgaben (constraints), z. B. „Alle Seiten erfüllen WCAG 2.2 Stufe AA.“
Manche Teams formulieren sie auch als eigene Story aus Sicht der Betroffenen („Als Händler mit Sehbeeinträchtigung möchte ich das Portal per Tastatur und Screenreader bedienen, damit ich ohne fremde Hilfe bestellen kann.“).
Englische Fachtexte zu User Stories
Aufgaben und Projektdokumentationen enthalten zu diesem Thema oft englische Texte. Diese Begriffe solltest Du kennen:
| Englisch | Deutsch |
|---|---|
| user story, story | Anwendergeschichte, User Story |
| end-user, type of user, role | Endnutzer*in, Nutzergruppe, Rolle |
| on behalf of the user | im Auftrag/im Namen der Nutzenden |
| template | Vorlage, Schablone |
| goal, capability, task | Ziel, Fähigkeit, Aufgabe (der Funktionsteil) |
| benefit, value | Nutzen, Mehrwert |
| requirement | Anforderung |
| acceptance criteria | Akzeptanzkriterien |
| (product) backlog item | Eintrag im (Product) Backlog |
| to estimate, effort | schätzen, Aufwand |
| to negotiate | aushandeln, verhandeln |
| to split a story | eine Story aufteilen/schneiden |
Tipp: Lies einen englischen Aufgabentext zuerst ganz, markiere die Begriffe aus der Tabelle und beantworte die Fragen dann auf Deutsch. Meist steht die Antwort für „Nenne …“ wörtlich im Text, für „Erläutere …“ musst Du sie mit eigenen Worten und einem Beispiel ausführen.
Leitfragen
- Was ist eine User Story, und worin unterscheidet sie sich von einer Anforderung im Pflichtenheft?
Eine User Story ist eine kurze, informelle Beschreibung einer Anforderung aus Sicht der Nutzenden: wer etwas möchte, was die Person tun möchte und wozu. Sie beschreibt ein Bedürfnis, keine technische Lösung, und ist bewusst unvollständig – die Details entstehen im Gespräch; ein Pflichtenheft versucht dagegen, vorab alles vollständig und verbindlich festzuschreiben, siehe Abschnitt „Was ist eine User Story?“ und Abschnitt „Eine Story ist ein Versprechen auf ein Gespräch: die drei C“.
- Wer schreibt User Stories, und wer ist für sie im Product Backlog verantwortlich?
Schreiben darf eine Story jede*r, die oder der Produkt und Nutzende kennt – Product Owner, Mitglieder des Entwicklungsteams oder Stakeholder, immer im Auftrag der Nutzenden. Verantwortlich für die Stories im Product Backlog ist in Scrum der Product Owner, der entscheidet, welche Story ins Backlog kommt und in welcher Reihenfolge sie umgesetzt wird, siehe Abschnitt „Wer schreibt User Stories?“.
- Aus welchen drei Teilen besteht eine User Story nach der Connextra-Schablone, und welche Frage beantwortet jeder Teil?
Die Schablone lautet „Als Rolle möchte ich Funktion, damit Nutzen.“: Die Rolle beantwortet, wer etwas möchte, die Funktion, was die Person tun oder erhalten möchte, und der Nutzen, wozu sie das braucht. Gerade der Nutzen verrät, warum etwas gebraucht wird, und eröffnet manchmal eine bessere Lösung, siehe Abschnitt „Der Aufbau: die Satzschablone“.
- Wofür stehen die Buchstaben I, N, V, E, S und T, und wie prüfst Du eine Story damit?
INVEST steht für Independent (unabhängig), Negotiable (verhandelbar), Valuable (wertvoll), Estimable (schätzbar), Small (klein genug für einen Sprint) und Testable (testbar). Du prüfst eine Story mit Fragen wie: Kann das Team sie ohne andere Stories umsetzen? Würde jemand außerhalb des Teams den Mehrwert merken? Gibt es Akzeptanzkriterien, die sich mit Ja oder Nein beantworten lassen?, siehe Abschnitt „Wann ist eine Story gut? Die INVEST-Kriterien“.
- Wie leitest Du aus einem Anwendungsfall mit «include» und «extend» eine User Story ab?
Die Akteurin wird zur Rolle, der Name des Anwendungsfalls als Tätigkeit zur Funktion, und den Nutzen erschließt Du aus dem Kontext. Ein «include» ist ein Teilschritt, der immer dazugehört, und wird als „Dabei …“ ergänzt; ein «extend» findet nur unter einer Bedingung statt und wird als „Falls … / Wenn …“ ergänzt oder als eigene Story formuliert, siehe Abschnitt „Vom Anwendungsfall zur User Story“.
- Welche typischen Fehler kommen in User Stories vor, und wie behebst Du sie?
Typische Fehler sind System oder Team als Rolle, eine technische Lösung statt eines Bedürfnisses, ein fehlender oder leerer Nutzen, mehrere Funktionen in einer Story, nicht prüfbare Formulierungen wie „schnell“ und zu viele Details vorweg. Du behebst sie, indem Du die profitierende Nutzerrolle und den echten Grund nennst, die Story aufteilst, messbare Akzeptanzkriterien ergänzt und Details ins Gespräch oder in ein Mockup verlagerst, siehe Abschnitt „Typische Fehler und wie Du sie behebst“.
- Wie formulierst Du Akzeptanzkriterien im Format Given – When – Then, und wie unterscheiden sie sich von der Definition of Done?
Ein Akzeptanzkriterium beschreibt eine Ausgangslage, eine Aktion und das erwartete Ergebnis: „Angenommen, ich habe zwei offene Rechnungen, wenn ich die Seite öffne, dann sehe ich nur diese, sortiert nach Fälligkeit.“ Akzeptanzkriterien gelten für eine Story und beschreiben ihr fachliches Verhalten; die Definition of Done gilt für alle Stories gleich und beschreibt die geforderte Qualität (z. B. Code reviewt, Tests grün), siehe Abschnitt „Wann ist eine Story fertig? Akzeptanzkriterien“.
- Wie schneidest Du ein Epic sinnvoll, und warum ist ein Schnitt nach Datenbank und Oberfläche ungeeignet?
Ein Epic schneidest Du fachlich, z. B. nach Arbeitsschritten, nach Regeln oder Varianten, nach Datenarten oder nach Normal- und Sonderfall. Ein Schnitt nach Datenbank und Oberfläche ist ungeeignet, weil keine der Teil-Stories für sich einen Wert für die Nutzenden hat (Verstoß gegen Valuable) und sie voneinander abhängen (Verstoß gegen Independent), siehe Abschnitt „Zu groß für einen Sprint? Epics schneiden“.
Links und weitere Informationen
zum Üben: Übungsaufgaben zu User Stories
verwandte Artikel: Anforderungsanalyse, Anforderungen dokumentieren, UML-Anwendungsfalldiagramm, Vorgehensmodelle
als Primärquelle zu Scrum: Der Scrum Guide (deutsche Fassung, 2020)
zur INVEST-Herkunft: Bill Wake: INVEST in Good Stories, and SMART Tasks (2003)
zu den drei C: Ron Jeffries: Essential XP: Card, Conversation, Confirmation (2001)
als Standardwerk: Mike Cohn: User Stories Applied: For Agile Software Development, Addison-Wesley 2004, ISBN 978-0-321-20568-1
zum Überblick: User story (englische Wikipedia)
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “User Stories: Anforderungen aus Sicht der Nutzenden formulieren” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/user-stories veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/projekt/anforderungsanalyse. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
