I.N.V.E.S.T. oder „Was macht eine User Story komplett?“

Gute Userstories sind die Grundlage erfolgreicher Produktentwicklung. Unser Artikel beschreibt, mit welcher Hilfsmethode man das erreichen kann.
Created with Lunacy

I.N.V.E.S.T. oder „Was macht eine User Story komplett?“

by Georg Ehrentraut

Im agilen Kontext, speziell in Scrum Teams, wird die User Story häufig als Format genutzt, um grundlegende Wünsche und Bedürfnisse eines Nutzers zu beschreiben. Wobei der Begriff Story in unserem agilen Fall weniger mit einem ausufernden Essay über Maslowsche Bauwerke gemein hat, sondern vielmehr ganz konkrete Anforderungen aus Sicht des Anwenders mit einfachen Worten in einem kurzen, prägnanten Satz beschreibt.

Entgegen der landläufigen Meinung entstammt der Begriff User Story nicht dem Scrum Guide sondern ist ein Konzept aus dem agilen Entwicklungsmodell Extreme Programming (XP).

Inhaltlich definiert eine gute User Story drei Aspekte einer Anforderung: Wer, Was und Warum.

  • Wer will das haben? Wer braucht das?
  • Was wünscht sich der Anwender?
  • Warum möchte der Anwender das haben?

Mit diesem Baukasten können die Bedürfnisse, Wünsche und Ideen der Stakeholder von Beginn an in die Produktentwicklung einfließen. Jede Person ist mit diesem Format in der Lage eine erste, einfache User Story zu formulieren und einzubringen.

Am Beispiel unseres Sitebuilders „CM4all Sites“ könnte die User Story für Besucherstatistiken so aussehen:

„Als Sites Nutzer möchte ich Zugriff auf Besucherstatistiken erhalten, um das Nutzungsverhalten der Besucher meiner Webseite nachvollzuziehen zu können.“

Durch die niedrige Einstiegshürde fließen Ideen und Anforderungen zwar direkt in die Produktentwicklung ein, was grundsätzlich auch sinnvoll und gewünscht ist, gleichzeitig entsprechen User Storys in ihrer ersten, groben Formulierung oftmals nicht der „Definition of Ready“. Es ist also notwendig neue User Storys gemeinsam mit den Stakeholdern und dem Team zu hinterfragen und auszuarbeiten, bevor sie im Zuge des Plannings Teil eines Sprints werden können.

Unpräzise User Storys führen im Worst Case dazu, dass konkrete Anforderungen nicht erfüllt werden und der Produktnutzen für den Anwender abnimmt. Bei frühzeitiger Identifikation der Diskrepanz wird aber mindestens eine Korrektur der User Story und der angeschlossenen Aufgaben innerhalb einer Iteration notwendig, was wiederum zu zusätzlichem Aufwand und Frustration bei allen Beteiligten führt.

Der Feinschliff von User Storys findet grundsätzlich im Refinement statt. Ziel dieses regelmäßigen Meetings ist es, die priorisierten Backlog-Einträge so auszuarbeiten, dass sie der vereinbarten „Definition of Ready“ entsprechen, ein allgemeines Verständnis für den Umsetzungsaufwand herrscht und im Sprint Planning berücksichtigt werden kann. Ein erfahrungsgemäß positiver Nebeneffekt eines regelmäßigen Refinements ist, dass das Planning durch bereits klar formulierte User Storys und eindeutige Priorität der Backlog-Einträge deutlich weniger Zeitaufwand erfordert.

Um die Qualität einer User Story zu gewährleisten, sollte jede Story daher die I.N.V.E.S.T. Kriterien erfüllen:

  • Independent: Eine User Story muss unabhängig von anderen User Storys sein, sie darf nicht davon abhängen, dass zuerst eine andere Story umgesetzt wird.
  • Negotiable: User Storys sind nicht in Stein gemeißelt. Stakeholder und Team diskutieren und präzisieren sie gemeinsam.
  • Valuable: Jede User Story darf nicht nur einen Nutzen haben, sondern muss einen eindeutigen Mehrwert bieten.
  • Estimatable: Der Aufwand der Umsetzung einer User Storys muss für das Team schätzbar sein.
  • Small: Auch wenn der konkrete Umfang einer Story vom Team entschieden wird, sollten User Storys nicht zu groß oder zu klein sein. Erfahrungsgemäß sollte die Umsetzung einer Story mindestens einen halben Personentag und maximal 10 Personentage erfordern.
  • Testable: Um eine User Story erfolgreich abschließen zu können, müssen Storys zwingend testbar sein.

Wenn einzelne der genannten Kriterien nicht erfüllt werden, sollte die User Story gemeinsam mit den Stakeholdern und dem Team diskutiert und entsprechend abgeändert werden.

Erfahrungsgemäß steigt das Verständnis für eine vollständige User Story innerhalb des Teams und auf Seiten der Stakeholder mit der Menge an gemeinsam ausgearbeiteten User Storys.

Werden alle sechs I.N.V.E.S.T. Kriterien erfüllt, kann eine User Story getrost als vollständig bezeichnet und guten Gewissens in einem Sprint umgesetzt werden. Sie wird schlussendlich die Anforderungen des Nutzers erfüllen und das Produkt damit erfolgreicher machen.

back