User Stories machen das Leben leicht

User Stories haben sich in der agilen Welt für den Umgang mit Anforderungen mittlerweile fest etabliert. Sie bestechen auf den ersten Blick durch ihre Einfachheit und Klarheit. Richtig eingesetzt, sollen sie dabei helfen, sich darauf zu konzentrieren, was in einem Projekt wirklich wichtig und nutzbringend ist. Um dies sicherzustellen, gibt es Qualitätsmerkmale wie die 3 Cs: Card (die User Story passt auf eine DINA5-Karte), Conversation (die User Story ist ein Versprechen für eine Konversation) und Confirmation (in Form von Akzeptanzkriterien oder Akzeptanztests).

Statt Cards finden wir jedoch in der Praxis Spezifikationen, die nun dem Satzmuster der User Stories folgen. Statt Conversation werden die Spezifikationen nun in Form von User Stories wie gehabt mehr oder weniger kommentarlos weitergegeben. Statt Confirmation bleibt die Frage, wann eine Anforderung abgenommen wird, weiterhin unbeantwortet.

Warum ist das so? User Stories dürfen nicht als eine neue Form der Anforderungsspezifikation missverstanden werden. Ich höre in der Praxis Sätze wie: „Wir werden jetzt viel schneller, weil wir schreiben nur noch einen Satz“.

Die Frage wie man zu diesem Satz kommt, ist nun die spannende. Bei richtiger Verwendung führen User Stories zu einem Umdenken und einem Paradigmenwechsel. Das wiederum erfordert Mut, da auf die bisherigen (vermeintlichen) Sicherheitsnetze umfassender Spezifikation verzichtet werden muss.

In der Praxis zeigt sich jedoch, dass gerade dabei erhebliche Schwierigkeiten auftreten. Wieviel weiteres Detail darf bzw. muss ich denn nun zu dem Satz hinzufügen und wie mache ich das am geschicktesten? Was ist der  Unterschied zwischen Spezifikation und Dokumentation, was benötigen wir wann und reichen persistente Testfälle zur Dokumentation aus?

Auf dieses und mehr gehen wir in unser Schulung zum Certified Agile Requirements Specialist (CARS) ein.

Dieser Blogbeitrag wurde von Susanne Mühlbauer für HOOD geschrieben.