…zumindest könnte man das annehmen, wenn der vierte Hamburger Scrumtisch in den Räumen der Hamburger Handwerkskammer stattfindet. Aufgrund der vielen Anmeldungen sahen sich die Organisatoren gezwungen, auf einen Veranstaltungsort auszuweichen, der mehr Raum bot als das kuschelige P.I.A. Kesselhaus in Ottensen, das bisher die Scrumtische beherbergte. Leider fanden gestern nur wenige Scrum-Interessierte den Weg zum Holstenwall. Diese “Mannschaft”, die sich aus alten Stammtisch-Hasen und Neulingen zusammensetzte, erlebte und gestaltete eine Veranstaltung, die ausschließlich das Open-Space-Format nutzte, um aus dem Gremium eingebrachte Themen in drei Runden an jeweils drei Tischen zu diskutieren. Das macht in Summe neun Diskussionsrunden. Vom “Gesetz der Füße” wurde eher spärlich Gebrauch gemacht – vermutlich ein Indiz dafür, dass die Diskussionen zu fesseln vermochten. Ich musste früh aufbrechen und kam deshalb in den Genuss von nur zwei Open-Space-Runden.

Nachdem die Frage nach dem Wesen des User Story Mapping (Artikel|Video) in Ermangelung an Experten dieser Praktik nicht zufriedenstellend beantwortet werden konnte, vertagten wir dieses Thema auf den nächsten Stammtisch (glücklicherweise fand sich jemand, der das Thema mit dahin aufbereiten wollte) und widmeten uns stattdessen der Frage, wie man “gute” Stories schreibt. Dem spontanen Schweigen nach zu urteilen, gibt es auf diese Frage keine schnelle Antwort. Wir versuchten deshalb, die Güte einer Story über deren Wert zu ermitteln. Natürlich schwirrte sofort der Begriff des Geschäftswerts im Raum. Als wir uns dann aber einigen konkreten Beispielen widmeten, mussten wir schnell feststellen, dass in bestimmten Projekten und allgemein in den ersten Sprints die Suche nach dem Geschäftswert recht schwierig ist. “Was spricht dagegen, den Geschäftswert in diesen Fällen durch einen anderen Nutzen zu ersetzen?”, fragten wir uns. Wie aber kann ein solcher Nutzen aussehen? Und wann entsteht dann der Geschäftswert? Nach einer “wert-vollen” Diskussion mussten wir uns eingestehen, dass wir bei dem Begriff “Geschäftswert” sofort an monetäre Größen denken. Es können aber tatsächlich ganz andere Aspekte eine Rolle spielen: Beispielsweise kann eine Story einen strategischen Wert besitzen, unter Umständen auch “nur” einen ideellen Wert. Oder der Produktverantwortliche verbindet mit der hohen Priorisierung einer Anforderung einen zeitlichen Vorteil: Je früher das Feature verfügbar ist, umso länger hat man in diesem Bereich einen Vorsprung vor den Mitbewerbern. Ein Geschäftswert ist also mehr als nur Heller und Pfennig.

“Gute” Stories sind immer überschaubar. Was aber, wenn der Kunde die Lösung mit dem Goldrand möchte, diese jedoch in einem Sprint nicht umsetzbar ist? Wie bricht man eine solche Story in kleinere Einheiten auf? Ein interessanter Vorschlag kam von Stefan Roock: Mittels Dimensional Planning. Darunter versteht man in der agilen Welt die Bewertung einer Story nach deren “Tiefe”, man könnte auch sagen: Komfort – vergleichbar dem System der Hotel-Sterne. Als Metapher für das Dimensional Planning nannte Stefan den Straßenbau. Um mit einem Fahrzeug von A nach B zu kommen, benötige ich eine Straße. Dabei kann es sich im einfachsten Fall um eine Schotterpiste handeln, über die ich mehr schlecht als recht mein Ziel erreiche. Eine mit Kopfsteinen gepflasterte Straße ist schon deutlich komfortabler, rüttelt mein Fahrzeug aber immer noch ordentlich durch. Das ist bei der asphaltierten Straße nicht mehr Fall. Trotzdem kann ich immer noch nicht so schnell fahren, wie ich eigentlich möchte. Das darf ich erst tun, wenn meine Straße zur Autobahn ausgebaut wurde. Ähnlich ist es beim Sterne-System im Hotelgewerbe: In einem Zwei-Sterne-Hotel kann man auch schlafen, weil der minimale Standard ein Bett umfasst. Im Fünf-Sterne-Grand-Hotel ist das Bett aber weicher, die Matratze nicht so durchgelegen, und der Service viel besser – das Frühstück wird mir direkt am Bett serviert. Kommen wir zurück zu den Stories: Diese lassen sich ebenfalls nach ihrem Komfort kategorisieren. Damit ist es möglich, in einem Sprint eine Story in der Drei-Sterne-Version umzusetzen, und zwei Sprints später dieses Feature mit Vier-Sterne-Komfort zu versehen.

Aber was genau macht denn nun eine “gute” Story aus? Auf diese Frage haben wir leider keine allgemein gültige Antwort gefunden – vermutlich deshalb, weil es keine einfache Antwort auf diese Frage gibt.

Henning Wolf stellte in der zweiten Diskussionsrunde eine interessante These in den Raum: Mit Blick auf das agile Schätzen hinterfragte er den Sinn der Fokussierung auf die Größe einer Story. Seiner Meinung nach sollte man auch die Komplexität einer Story berücksichtigen. Eine saubere Definition des Begriffs “Komplexität” bildete sich in der nachfolgenden Diskussion zwar nicht heraus (ist aber auch ganz schön kompliziert), aber die Idee, die hinter dem Schätzen von Komplexität steht, wurde dennoch deutlich. So sollte die Anzeige von Kundendaten in der Benutzungsoberfläche aus fachlicher Sicht genauso groß (d.h. aufwendig zu implementieren) sein wie die Anzeige von Lieferantendaten. Wenn letztere jedoch aus verschiedenen Datenquellen zusammengestellt werden müssen, dann dürfte die Komplexität dieser Aufgabe (im Sinne von miteinander in Beziehung zu setzenden Komponenten) höher sein als im Falle der Kundendaten, die aus einer einzigen Datenbank bezogen werden. Gleiche Aufgabe (Anzeige von Daten), aber unterschiedliche Komplexität (Datenzugriff): Wenn man das dem Kunden bewusst machen kann, dann besteht die Hoffnung, dass auf diese Weise die Erklärungen (bzw. Rechtfertigungen) agiler Teams ihrer vermeintlich zu hohen Größenschätzungen in Zulunft entfallen oder zumindest deutlich seltener vorkommen werden.

Die Komplexität kann aber multidimensional sein. Im genannten Beispiel hat der Zugriff auf Daten für verschiedene Domänen (Kunden, Lieferanten) eine unterschiedlich hohe Komplexität. Der Mechanismus für die Anzeige von Daten und den damit verbundenen Datenzugriff quer durch alle Systemschichten hat eine eigene Komplexität. Erst die Kombination dieser beiden Komplexitätswerte liefert für die Stories “Anzeige von Kundendaten” und “Anzeige von Lieferantendaten” eine realistische Gesamtkomplexität.

Ein weiterer Vorteil der “Komplexitätsorientierung” wurde nur kurz andiskutiert und müsste meiner Meinung nach noch vertieft werden: Wie wirken sich Refactorings auf Größe und Komplexität einer Story aus? Ich hege die Hoffnung, dass es mit der kombinierten Bewertung von Größe und Komplexität möglich ist, unseren Kunden den Wert eines Refactorings nachzuweisen. Damit gehört dann hoffentlich eine weitere Diskussionskategorie (“Was soll dieses teuere Refactoring? Ich sehen doch gar keine Veränderung!”) der Vergangenheit an. Unrealistisch? Vielleicht. Aber man wird doch wohl mal träumen dürfen…