User Stories, eine Übung in Demut

Der Überlieferung nach begegnete der heilige Augustinus bei einem Spaziergang am Strand einem Jungen, der ein Loch in den Sand gebuddelt hatte. Der Junge hielt eine Muschel in der Hand, schöpfte Wasser aus dem Meer, und lief damit zum Loch zurück. Augustinus fragte ihn, was er da tue. Das Kind erwiderte, dass es das gesamte Meer in dieses eine Loch gieße.Erwachsene, rational denkende Menschen, können eine solche Antwort schwer verdauen. Für den Jungen indes macht die Handlung durchaus Sinn: Die Mengen an Wasser, die er mit seiner Muschel vom Meer in das Loch befördert, sind für ihn symbolische kleine Teile, die für das große Ganze stehen. Zeitsprung 2012Ein Abteilungsleiter geht in ein neu geformtes Scrum-Team und sieht, wie das Team eifrig Karteikarten mit merkwürdig formulierten Sätzen schreibt. Auf die Frage, was das Team denn da tue, bekommt er als Antwort, es schreibe das gesamte Produkt in Form einsätziger Alsmöchteichdamit-Sätzen auf. Der Abteilungsleiter lacht, schüttelt ungläubig den Kopf, und sagt: „So so, damit verbringt ihr jetzt eure Zeit.“Bei solchen Reaktionen kommen selbst hoch motivierte Team-Mitglieder ins Zweifeln. Und fragen sich, warum sie plötzlich User Stories schreiben sollen, wenn sie doch eh schon immer wussten, was zu tun war. 

User Stories sind also vor allem eins: Eine Demutslektion.

Wir gestehen uns ein, dass Produktentwicklung komplex ist, und dass wir im Vorfeld unmöglich alles

wissen können. Wir gestehen uns ein, dass wir gar nicht so genau wissen, wofür der Kunde sein Portemonnaie öffnen wird, und was den Benutzer zum Strahlen bringen wird. Deshalb formulieren wir die Produkteigenschaften nicht als Anforderungen, sondern als Hypothesen über die Bedürfnisse unserer Nutzer. Hypothesen, die es am Ende eines Sprints zu validieren gilt. Deshalb versuchen wir, die Entwicklung in kleine, mehrtätige Arbeitspakete herunterzubrechen, an dessen Ende eine (noch so rudimentäre) Funktionalität steht. Jede einzelne User Story, so klein sie auch sein mag, steht bereits für das große Ganze. Deshalb lohnt es sich, selbst bei reinen Backend-Stories die Frage nach dem Nutzer und den Nutzen zu stellen.Für wen entwickeln wir eine Funktionalität in letzter Instanz? Sicher nicht für den DB-Admin. Auch nicht für den Kollegen in der Entwicklung oder den Tester. Können wir die Frage nach Nutzer und Nutzen nicht beantworten, dann ist das fast immer ein Zeichen dafür, dass wir uns mit uns selbst beschäftigen und den Sinn unseres Tuns aus den Augen verloren haben. Nachdem Augustinus dem Kind sagt, dass es niemals das gesamte Meer in das Loch gießen werde, antwortet der Junge: „Und so wirst auch du nie das Geheimnis der Dreifaltigkeit ergründen."