Im vorigen 10 Minuten Beitrag über Produktentwicklung habe ich schon über das Product Backlog geschrieben, welches sich inzwischen in der agilen Welt stark verbreitet hat. Ähnlich verhält es sich mit User Storys, mit denen das Product Backlog üblicherweise gefüllt wird. Diese entstanden ursprünglich im Zusammenhang mit dem agilen Framework eXtreme Programming (XP), welches unter anderem von Ron Jeffries entwickelt wurde. Als das entwickelt wurde, gab es den Begriff agil in diesem Sinne noch nicht, aber das ist eine andere Geschichte.
Effektiv kommt also quasi jeder der sich im agilen Kontext bewegt zwangsläufig mit User Storys in Berührung. Den Effekt den ich dabei häufig beobachte ist die folgende Aussage: „Das sind Anforderungen die in einer speziellen Form aufgeschrieben werden“. Das ist jetzt nicht grundsätzlich falsch, nur das was daraus gemacht wird ist zum Teil fatal. Das Ergebnis ist dann eben häufig, dass alles was früher in einem Lastenheft oder Fachkonzept stand, irgendwie in diese User Storys gepresst wird. Nur geht dann der ganze Sinn dieser schönen Praktik verloren.
Die Grundidee von User Storys ist, dass es eine Einladung zum Gespräch ist. Es erzählt eine Geschichte und Menschen hören und erzählen gerne Geschichten. Indem also eine Geschichte rund um eine Anforderung formuliert wird, wird die Idee dazu transportiert. Wenn jetzt versucht wird, alles rund um die Anforderung exakt zu spezifizieren, warum dann noch reden? Das ist ja das Dilemma, weshalb dieses Konzept entstanden ist. Das Gespräch zwischen Anforderern und Umsetzern soll ja gerade unterstützt werden.
Ron Jeffries schlägt die Formel der drei Cs für gute User Storys vor: Card, Conversation und Confirmation. Card, also Karte bezieht sich darauf, dass die User Story eine greifbare Einheit sein sollte, üblicherweise eine Metaplankarte oder ein Post-It. Sie beschränkt außerdem bewusst den Platz, damit eben nicht alle Details darauf geschrieben werden können. Conversation, also Gespräch soll die Grundlage sein. Daher kommt der Spruch mit „User Story ist eine Einladung zum Gespräch“. Confirmation, also Bestätigung bezieht sich auf die Akzeptanzkriterien. Es ist üblich auf der Rückseite der Karte mit der User Story Kriterien zu definieren, welche erfüllt sein müssen, damit diese Story als erfüllt gilt. Diese Kriterien entstehen am besten auch in Folge des Gesprächs und unterstützten das gemeinsame Verständnis, welches darauf basierend erlangt wurde. Sie bilden dann übrigens auch eine Grundlage für testgetriebene Entwicklung.
Ich würde mich so freuen, wenn ich mehr gute User Storys sehen würde und weniger so detaillierte User Storys, dass sie zusammen eine vollständige Spezifikation ergeben.
Schreibe einen Kommentar