Was ist eine User Story?

User Story: Definition und Aufbau

Eine User Story hält eine Anforderung in einem Satz fest: Wer will etwas, was soll möglich sein und wozu? Die klassische Form lautet „Als [Rolle] möchte ich [Funktion], um [Nutzen] zu erreichen“. Der Nutzen steht bewusst mit drin, denn er zeigt, wie wichtig die Anforderung ist und ob es einfachere Lösungen gibt.

Zur Story gehören Akzeptanzkriterien, also klare, prüfbare Bedingungen, wann sie als erfüllt gilt. Größere Vorhaben werden als „Epic“ beschrieben und in einzelne Stories zerlegt. Gesammelt werden alle Stories im Backlog, das der Product Owner nach Nutzen priorisiert. Dadurch bleibt für alle sichtbar, was als Nächstes ansteht und warum.

Gute User Stories: das INVEST-Prinzip

Als Orientierung dient das Kürzel INVEST: unabhängig (Independent), verhandelbar (Negotiable), nutzbringend (Valuable), schätzbar (Estimable), klein (Small) und testbar (Testable). Eine Story soll in wenigen Tagen umsetzbar sein und im Gespräch zwischen Fachbereich und Entwicklung verfeinert werden, statt als starrer Vertragstext zu gelten.

Akzeptanzkriterien werden häufig im Muster „Gegeben – Wenn – Dann“ formuliert: Gegeben ein angemeldeter Monteur, wenn er einen Auftrag öffnet, dann sieht er Adresse, Ansprechpartner und Materialliste. Solche Sätze lassen sich von Fachleuten gegenlesen und später direkt als Testfall verwenden. Das verhindert Missverständnisse zwischen Fachbereich und Entwicklung.

• Rolle konkret benennen statt „der Nutzer“ im Allgemeinen
• Ziel und Nutzen in einem Satz festhalten
• Akzeptanzkriterien prüfbar formulieren
• Story so schneiden, dass sie in einem Zyklus fertig wird
• Keine technische Lösung vorgeben, wo das Ziel genügt

Praxis­bei­spiel: Mitarbeiter-App im Sanitärbe­trieb

Ein Sanitärbetrieb plant eine App für die Baustelle. Statt einer langen Funktionsliste entstehen Stories wie: „Als Monteur möchte ich meine Arbeitsstunden direkt auf der Baustelle erfassen, damit ich abends keine Zettel nacherfassen muss.“ Oder: „Als Büroleiterin möchte ich sehen, welche Aufträge heute abgeschlossen wurden, um Rechnungen schneller zu schreiben.“

Im Gespräch über die erste Story stellt sich heraus, dass auf manchen Baustellen kein Empfang besteht. Daraus entsteht eine eigene Anforderung: Eingaben müssen auch offline möglich sein. Ohne die Nutzerperspektive wäre das erst nach dem Start aufgefallen, mit entsprechendem Umbauaufwand.

Grenzen, Fehler und Umsetzung

User Stories ersetzen keine Dokumentation: Für komplexe Regeln, Schnittstellen oder rechtliche Vorgaben braucht es zusätzliche Beschreibungen. Typische Fehler sind Stories als versteckte Lösungsvorgaben („Als Nutzer möchte ich ein Dropdown …“), zu große Stories, fehlende Akzeptanzkriterien und Stories, die die Entwicklung ohne Rücksprache mit den Anwendern schreibt.

Nano Concepts erarbeitet Anforderungen gemeinsam mit Ihren Fachbereichen, formuliert sie als User Stories mit Akzeptanzkriterien und nutzt sie als Grundlage für Angebot, Umsetzung und Abnahme. Bei größeren Projekten lohnt es sich, die wichtigsten Stories in einem kurzen Workshop gemeinsam zu sammeln. So wissen alle Beteiligten, was gebaut wird und woran sich der Erfolg misst.