Das Team hat sich geeinigt, welche UserStorys im nächsten Projektabschnitt bearbeitet werden. Aber die UserStorys können nicht abgeschlossen werden. Das Projektteam kämpft mit dem Umgang.

Neben den Projektprozessen im Team lohnt es sich auf die Qualität der UserStorys zu achten. In der Praxis und in der Hektik des Alltags geht die Idee von einer guten UserStory leicht verloren.

Einige blähen die UserStorys während der Bearbeitung auf. Die "never-ending Story" ist geboren. Das ist eine Geschichte, die während des Projektabschnitts im Umfang wächst, aber nicht abgeschlossen wird.

Das Team sieht sich nicht in der Lage, diesem Wachstum Einhalt zu gebieten. Wann geschieht das? Und wie kann das Team damit gesünder umgehen?

UserStorys sind häufig nicht gut formuliert sind. UserStorys sollen den fachlichen Grund für eine bestimmte Funktion - in Relation zur fachlichen Rolle - erläutern:

"In der Rolle XYZ mache ich ABC, um DEF zu erreichen".

Diese Formulierung wird um Akzeptanzkriterien erweitert, in der fachliche Anforderungen und Abhängigkeiten formuliert sind. Im beruflichen Alltag geht diese Formulierung häufig verloren. An Stelle der klärenden Beschreibung steht nur "Loginformular" auf der entsprechenden UserStory-Karte. Mit dieser Kurzform gehen Informationen verloren:

• Für welche Rolle ist diese Funktion notwendig?
• Welcher Leistungsumfang ist abzuleiten?

Während die UserStory "Loginformular" bearbeitet wird, stellen die Teammitglieder fest, dass die erfassten Daten administriert werden müssen. An Stelle eine neue Story zu schreiben und diese ins Backlog zu befördern, ergänzt das Team die UserStory um den Administrationsbereich.

Die Forderung nach einer generellen Umsetzung fällt die Idee zum Opfer, die Aufgaben für jede Rolle gesondert aufzuschreiben.

Ergebnis: eine UserStory, die wächst und wächst und nicht fertig wird.

An Stelle der fachlichen Beschreibung finden sich auch häufig in UserStorys semi-technische Anforderungen. Das bereits erwähnte "Loginformular" kann auch mit diesem Phänomen beschrieben werden.

An Stelle einer reinen fachlichen Beschreibung enthält bereits die Beschreibung der zu erstellenden Aufgabe technische Anforderungen. Diese werden dann zum Teil in den Akzeptanzkriterien aufgenommen. Mit den Worten "das ist doch auch schon klar" fallen die Akzeptanzkriterien für solche UserStorys sehr klein aus.

Während der eigentlichen Umsetzung bereiten derart gestaltete UserStorys Schwierigkeiten. Sie blähen nach und nach auf. Immer mehr Akzeptanzkriterien kommen hinzu. Indiz für diese Art von UserStorys sind stark technisch geprägte Diskussionen zum einem Zeitpunkt, zu dem der fachliche Leistungsumfang verstanden werden soll. 

Kurz gesagt: die UserStorys folgen der Idee des INVEST nicht. Auch hier ist das Ergebnis, dass die UserStory während der Umsetzung stark an Umfang zunimmt und nicht fertig wird.

Aber zur never-ending Story braucht es noch eine Zutat mehr: nur ein nicht-diszipliniertes Team wird eine langlaufende UserStory zulassen.

Eigentlich sind UserStorys, die nicht abgeschlossen werden können, erneut zu überarbeiten. So sieht SCRUM vor, dass nicht abgenommene Storys zurück ins Product Backlog gehen. Ähnliche Regeln können Kanban-Teams vereinbaren, wenn einzelne UserStorys nicht der Flussgeschwindigkeit folgen. 

Diese Regelungen gehen auf das dritte und siebte Prinzip des agilen Manifest zurück, dass die regelmäßige Auslieferung funktionsfähiger Software fordert beziehungsweise anmahnt, dass nur funktionierende Software den Fortschritt des Projekts beschreibt:

3. "Deliver working software frequently, from a  couple of weeks to a couple of months, with a  preference to the shorter timescale."

7. "Working software is the primary measure of progress."

Wenn ein Team also UserStorys als Langläufer zulässt, unterläuft dieses Team die Forderungen des agilen Manifests.

Der Umgang mit UserStorys erfordert also Disziplin im Team. Um diese Disziplin zu ermöglichen, ist es notwendig, dass das Team sich explizit auf verbindliche Regeln einigt, wie das Team mit UserStorys umgehen möchte.  Mögliche Teamregeln zum Umgang mit "Langläufern" könnten die nachfolgenden Regeln sein:

In jedem Fall muss das Team sauber analysieren, wann und unter welchen Umständen UserStorys zu Langläufern werden. So oder so muss das Team darauf methodisch und klar antworten. Das Level, auf dem die Antwort liegt, hängt von der Analyse ab.