INVEST-Kriterien

Die INVEST-Kriterien sind eine Checkliste für gute User Stories. Das Akronym hilft agilen Teams dabei zu prüfen, ob eine Anforderung klar genug beschrieben, sinnvoll geschnitten und bereit für die Umsetzung ist.

INVEST steht für Independent, Negotiable, Valuable, Estimable, Small und Testable. Oder etwas weniger feierlich gesagt: Eine User Story sollte für sich stehen, besprechbar bleiben, echten Nutzen liefern, schätzbar sein, nicht zu groß werden und am Ende überprüfbar sein.

Funktionsweise und Verwendung

Die INVEST-Kriterien werden häufig im Backlog Refinement oder im Sprint Planning genutzt. Dabei prüft das Team gemeinsam mit dem Product Owner, ob eine User Story schon gut genug vorbereitet ist oder noch einmal überarbeitet werden sollte.

Erfüllt eine Story eines der Kriterien nicht, ist das kein Drama. Dann wird sie geschärft, geteilt, ergänzt oder manchmal auch wieder zurück ins Backlog gelegt. Ziel ist nicht die perfekte Formulierung, sondern eine Anforderung, mit der Entwicklung, Testing und Fachbereich wirklich arbeiten können.

Gerade bei größeren Vorhaben helfen die Kriterien dabei, aus groben Ideen umsetzbare Arbeitspakete zu machen. So entsteht weniger Rätselraten im Sprint und mehr Klarheit darüber, was gebaut, geprüft und geliefert werden soll.

Die sechs Kriterien

• Independent: Die User Story ist möglichst unabhängig von anderen Stories und kann ohne große Reihenfolge-Probleme umgesetzt werden.
• Negotiable: Die Story beschreibt den Bedarf, aber nicht jedes technische Detail. Die genaue Lösung bleibt verhandelbar.
• Valuable: Die Umsetzung liefert einen erkennbaren Nutzen für Nutzer, Kunden oder Stakeholder.
• Estimable: Das Team hat genug Informationen, um den Aufwand grob einschätzen zu können.
• Small: Die Story ist klein genug, um in einem Sprint realistisch umgesetzt zu werden.
• Testable: Es ist klar prüfbar, wann die Story erfüllt ist. Meistens helfen dabei Akzeptanzkriterien.

Praxisbeispiele

• Ein großes Registrierungs-Epic wird in kleinere User Stories aufgeteilt
• Eine unklare Anforderung wird im Refinement mit Akzeptanzkriterien ergänzt
• Eine Story ohne direkten Nutzwert wird fachlich neu zugeschnitten
• Eine zu große Funktion wird in mehrere Sprint-taugliche Schritte zerlegt