Das I in INVEST – wie unabhängig können User Stories sein?

Heute hatte ich eine sehr spannende Diskussion. Es ging um das INVEST-Paradigma für User Stories, speziell um das I in INVEST. Das I steht für independent, also unabhängig.
Gute Stories sollen genau das sein: unabhängig.

Während der Diskussion ist mir bewusst geworden, dass das I in INVEST mindestens ebenso häufig falsch interpretiert wird, wie das zweite Wertepaar im Agilen Manifest.

Unabhängigkeit bei User Stories kann nämlich als die Möglichkeit einer beliebigen Reihenfolge verstanden werden. Wenn sich dieses Verständnis für Unabhängigkeit festgesetzt hat, führt das häufig zu künstlich unabhängigen oder zu großen User Stories und langwierigen Diskussionen über die Qualität der User Stories.
Künstliche Unabhängigkeit versucht um jeden Preis zu vermeiden, dass eine Story A implementiert sein muss, bevor eine Story B umgesetzt werden kann. Damit einher gehen häufig ziemlich schräge Akzeptanzkriterien oder es gibt eine Story-Explosion, weil versucht wird, so lange gemeinsame Teilaspekte aus den beiden Stories heraus zu splitten, bis die Abhängigkeit aufgelöst ist. Was aber nie passieren wird, Abhängigkeiten lassen sich manchmal vielleicht verstecken, aber nicht eliminieren.
Die zweite Variante, die ich beobachtet habe, führt dazu, dass Story B, die von Story A abhängt eben zu einer Story AB zusammengefasst werden. Die Story Points werden schnell addiert und man ist fein raus – glaubt man.
Meistens passt die Story dann nicht mehr in einen Sprint oder man erkennt erst, nach der Umsetzung von A und B, dass B überflüssig war. Bei zwei einzelnen Stories wäre diese Erkenntnis billiger zu haben gewesen.

Ich bin der Überzeugung, dass es völlig OK ist, wenn eine Story die Erledigung einer anderen Story voraussetzt. Insbesondere große und komplexe Systeme lassen sich gar nicht anders aufbauen. Die Unabhängigkeit von User Stories bedeutet eben gerade nicht, dass sie in beliebiger Reihenfolge realisiert werden können. Vielmehr bedeutet die Unabhängigkeit von User Stories, dass der Product Owner die Möglichkeit hat, im aktuellen Sprint das in Story A beschriebene Feature von einem Team realisieren zu lassen, ohne dass das von Story B beschriebene Feature auch realisiert werden muss. Story B kann zu einem beliebigen späteren Zeitpunkt von einem anderen Team realisiert werden. Genau das ist die Unabhängigkeit, die mit User Stories erreicht werden soll und die sowohl den Teams als auch dem Product Owner nützt.
Dazu ist es natürlich notwendig, dass die Story A in sich abgeschlossen ist. Hier spielen das T (Testable) und das V (Valuable) in INVEST mit der Unabhängigkeit zusammen. Insofern muss es in jedem größeren System Stories geben, die Vorbedingung für andere Stories sind.
Die Unabhängigkeit bezieht sich auf die Entscheidungsfreiheit des Product Owner, Features neu einzuplanen und neu zu priorisieren – nicht auf die notwendige technische Reihenfolge.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.