User Stories und Anforderungen

Eine der Neuerungen bei der Einführung von Scrum ist die Formulierung von User Stories. Gerade Mitarbeiter, die schon länger klassische Anforderungen formuliert haben, können sich damit schwer anfreunden. Die „schwammige“ Formulierung „Als <Rolle> möchte ich <Wunsch> damit <Nutzen>“ wäre sehr ungenau und die wichtigen Spezifikationen wie Größenangaben, Maße, etc. fehlte. Was viele hier aber außer Acht lassen (und bei ihrer bisherigen Arbeit auch), dass es auch in der klassischen Arbeitsweise eigentlich heißt, keine Anforderung ohne Use Case. Wobei ein Use Case nicht dasselbe ist wie eine User Story, aber der Gedanke zählt. Ich habe keine Anforderung, wenn ich nicht weiß wozu der Kunde oder Anwender das will und wie oder wann er es nutzt.

Ich möchte den Nutzen von User Stories auch für klassische Anforderungsspezifikationen an einem Beispiel verdeutlichen. In einem Projekt, in dem ich die Anforderungen reviewed habe, gab es eine Anforderung (neben vielen anderen ähnlich formulierten) mit folgendem Inhalt (etwas vereinfacht):

  • Ein Platz vor einem Gebäude soll mit Bewegungsmeldern gesichert werden.
  • Der Platz ist durch einen Zaun eingegrenzt. Bewegungen innerhalb des Zauns sollen detektiert und gemeldet werden.
  • Dazu gab es einen Bodenplan (hier nur als Skizze) mit allen Maßen, z.B. Abstand Gebäude zu Zaun. Höhe und Typ (Maschendraht) des Zauns, etc.

Man könnte meinen, dass alle Informationen vorhanden wären um das ganze umzusetzen. Es stellten sich für mich aber einige Fragen, mit denen ich auch den Projektleiter nervte:

Was ist hinter dem Zaun?

Die Reaktion auf diese Frage war völliges Unverständnis, schließlich interessierte uns nur was innerhalb des Zauns passierte. Hintergrund meiner Frage war aber, dass die Bewegungsmelder keine scharf abgegrenzte Reichweite hatten. Bis zu einer bestimmten eingestellten Reichweite konnten sie Bewegungen sehr zuverlässig erkennen. Darüber hinaus nahm die Wahrscheinlichkeit eine Bewegung zu erkennen dann zwar rapide ab, aber es bestand dennoch eine Chance etwas zu erkennen. Das bedeutete für uns bis zum Zaun 100% Wahrscheinlichkeit etwas zu erkennen, aber dann durch den Maschendraht auch gelegentlich dahinter wenn sich dort etwas bewegt. Oder wir haben keine 100% bis ganz an den Zaun, was aber der Anforderung widersprochen hätte. Es stellte sich heraus, dass nur einen Meter hinter dem Zaun eine auch nachts viel befahrene Straße war.

Das bedeutete mit den angegebenen Bewegungsmeldern, dass es permanent Fehlalarme geben würde. Was mich zur zweiten Frage brachte:

Woher kommen die Bewegungsmelder?

Sind die schon verbaut? Oder hat der Kunde die noch irgendwo rumliegen und möchte sie nutzen? Oder hat (mal wieder) jemand bei der Anforderungsanalyse als Lösungsvorschlag die Bewegungsmelder ins Spiel gebracht und man hat das natürlich gleich in der Anforderung so festgehalten? Es stellte sich heraus, dass es der Projektleiter selbst war. Dem Kunden war die Art und Weise ein Eindringen auf das Gelände festzustellen völlig egal. Prinzipiell hätten wir auch das Gelände mit Gewichtsensoren pflastern können, solange alles im preislichen Rahmen blieb.

Warum stört es den Kunden, wenn jemand auf dem betonierten Platz rumläuft?

Jetzt kam die entscheidende Frage. Jemand läuft nachts auf einem betonierten Platz rum. Wo war in dieser Geschichte das dramatische Element?

Der Punkt war, dass es nicht um den Platz oder den Zaun ging, sondern um das Gebäude. Darin befand sich eine Sammlung wertvoller nicht fahrbereiter Fahrzeuge und die größte Gefahr war Vandalismus. Man wollte also verhindern, dass jemand überhaupt in das Gebäude eindringt. Einbruchsensoren hätten erst angeschlagen, wenn jemand bereits im Gebäude ist. Wenn man allerdings eine Annäherung an das Gebäude feststellt, kann der Sicherheitsdienst sich bereits auf den Weg machen bevor der eigentliche Einbruchsversuch stattfindet. Damit kamen wir zu unserer User Story.

Die User Story

„Der Sicherheitsdienst will möglichst frühzeitig eine Annäherung an das Gebäude feststellen, damit er das Gebäude erreichen kann, bevor jemand eingebrochen ist und Schaden anrichtet.“

So sind wir am Ende auch bei den Bewegungsmeldern geblieben, da sie eine günstige und praktikable Lösung waren. Sie wurden so eingestellt, dass sie auf Bewegungen hinter dem Zaun nicht mehr reagierten. Dass es vom Zaun zum Gebäude hin einen Bereich gab, in dem das System nicht zuverlässig reagierte, war kein Problem, da die Zeit um diese wenigen Meter zu überbrücken vernachlässigbar war.

 

Was bedeutet das für die Anforderungen?

Entscheidend war und ist die Formulierung der User Story. Die ursprüngliche Anforderung mit ihren Spezifikationen hätten wir nicht zufriedenstellend erfüllen können. Wenn man aber diese Spezifikationen nur als Zusatzinformationen betrachtet und herausfindet was der Kunde damit bezweckt, hat man bessere Chancen eine adäquate Lösung anzubieten.  Man arbeitet zielstrebiger statt sich mit jeder (gescheiterten) Abnahme an das unklare Ziel heranzutasten.

Schätzen von User Stories

Eine der größten Schwierigkeiten, die viele Scrum-Teams haben, ist die Art und Weise wie die Größe geschätzt wird. Das Problem liegt u.a. darin, dass der Begriff „Größe“ den meisten zu abstrakt ist. Was ist damit gemeint? Die Komplexität, die Anzahl der Funktionen, der Aufwand? Die Meinungen was geschätzt werden soll sind so vielfältig wie ein Schottenrock. Die meisten die ich kenne schätzen die Komplexität. Das Problem das ich dabei aber sehe ist, dass die Komplexität nicht unbedingt viel Arbeit, Aufwand oder Zeit bedeutet. Es kann etwas komplex sein aber dennoch relativ schnell gemacht, dafür eine relativ einfache User Story viel Fleißarbeit erfordern. Heißt das nun ich schätze doch wieder Aufwände?

Nehmen wir zum Beispiel an unsere Hauptaufgabe ist es zu reisen. Wieviel kann ich in einem Sprint reisen? Was schätze ich? Als Einstieg würde ich einfach die Entfernung zum Ziel schätzen. Ob es Autobahnen oder einfache Landstraßen sind spielt erstmal keine Rolle. Solange ich die Strecke noch nicht kenne und schon oft gefahren bin, ist die Autobahn nicht unbedingt schneller als die Landstraße. Das hängt zu sehr davon ab, ob die Autobahn gut oder schlecht ausgebaut ist. Vielleicht gibt es viele Geschwindigkeitsbegrenzungen oder Staus, z.B. durch Baustellen oder Berufsverkehr. Der Berufsverkehr ist z.B. ein Aspekt, dass es mir auch bei bekannten Strecken schwer macht eine Zeit zu schätzen, wenn ich nicht genau weiß wann ich die Reise überhaupt antrete. Die User Story „Fahrt nach X“ liegt ja zunächst nur im Backlog. Das einzige was ich also zunächst einigermaßen gut schätzen kann ist die Entfernung.

Wenn ein Sprint geplant und durchgeführt wird enthält er viele einzelne Reisen. Bei den ersten Sprints wird auch die Größe der tatsächlich geschafften Reisen pro Sprint noch stark schwanken, aber nach einigen Sprints wird sich die Größe auf einen Durchschnittswert einpendeln. Das heißt, dass es gar nicht entscheidend ist wie lange man für eine einzelne Story braucht Es geht immer um einen Durchschnittswert über viele Stories. Das heißt in unserem Beispiel, es ist egal wie lange ich für eine bestimmte Reise gebraucht habe. Über einen langen Zeitraum mit mehreren Reisen wird der Durchschnittswert ausreichend genau sein und ich weiß (z.B. als Product Owner) in N Sprints werde ich ca. X Reisen schaffen. Wie lange ich für eine konkrete einzelne Reise brauche ist für die Projektlaufzeit unerheblich, solange ich über alle Reisen den Schnitt schaffe.

In diesem Beispiel ist die Entfernung natürlich eine leicht zu erfassende Größe. Wie sieht es aber mit User Stories aus wo ich nicht einfach eine Entfernung schätzen kann? Welche Größe nehme ich dann? Orientieren wir uns an dem Beispiel.

Was wäre der Aufwand? Das würde in etwa dem entsprechen, wie gut ein Streckenabschnitt befahrbar wäre, bzw. wie hoch die geschätzte fahrbare Geschwindigkeit wäre.

Die Komplexität wäre die spezielle Mischung Landstraße, Autobahn, Geschwindigkeitsbegrenzungen und Stauwahrscheinlichkeiten.

Was aber entspricht der Entfernung, der Strecke? Es ist vermutlich immer noch nicht klar ersichtlich was die „Größe“ sein soll. Ihr müsst euch nur die Frage „Wieviel kann es, wenn es fertig ist?“ bzw. „Wie viele Eigenschaften hat es?“. Dabei geht es natürlich nur um Eigenschaften die für die Arbeit von Bedeutung sind und ich sage ausdrücklich Eigenschaft und nicht Funktionalität, da es ja auch nichtfunktionale Eigenschaften gibt. Wie komplex eine Eigenschaft ist oder wie aufwändig spielt dabei keine Rolle. Entscheidend ist und bleibt was über viele Stories rauskommt und nicht ob eine einzelne Story mal schneller oder langsamer umgesetzt wird.