Dimensional Planning – Eine User Story ist kein kleines Fachkonzept

Vor nicht allzu langer Zeit wurden Business Analysten oder Requirements-Engineers gezwungen Anforderungen in Form von Fachkonzepten zu definieren. Ziel dieser Dokumente war es, möglichst alle Anforderungen des zu erstellenden Systems so detailliert zu beschreiben, dass anschließend die Kollegen vom Systemdesign und der Entwicklung die Anwendung implementieren konnten. Änderungen an den Anforderungen zogen immer auch Änderungen aller nachfolgenden Schritte nach sich und waren dementsprechend aufwendig. Nicht dokumentierte Anforderungen schafften es meisten nicht direkt in die Anwendung, sondern erst zu einem späteren Release.

Diese Art der Anforderungsbeschreibung führte dazu, dass Anforderer oft alle potentiell benötigten Systemfunktionen auf Verdacht spezifizierten, um später nicht in die Situation zu gelangen, dass vergessenen Funktionen nicht rechtzeitig geliefert wurden.

Heute arbeiten wir anstelle eines Fachkonzepts mit einem Product Backlog und spezifizieren die Anforderungen in User Stories. Leider passiert es aber immer wieder, dass die gelernten Verhaltensweisen aus der Zeit der Fachkonzepte sich in der Form und den Inhalten einer User Stories wiederfinden. Hier kann es helfen bei der Definition von User Stories das Modell des “Dimensional Planning” zu berücksichtigen:

Die Idee hinter Dimensional Planning ist es, den bekannten Dimensionen Zeit, Kosten und Umfang eine weitere Dimension hinzuzufügen. Diese Dimension beschreibt die Detailtiefe in der der definierte Umfang realisiert wird. In unserem Fall wird der Umfang eines Produkts durch die zu realisierenden User Stories im Backlog definiert. Diese existieren jetzt aber nicht mehr nur in einer Ausprägung, sondern in unterschiedlichen Ausbaustufen. In der ersten Ausbaustufe wird zunächst nur die denkbar einfachste Lösung für das fachliche Problem beschrieben. Weitere Ausbaustufen beschreiben dann jeweils komfortablere Lösungen und enthalten Zusatzfunktionen, die zwar schön sind, aber nicht unbedingt zur Problemlösung benötigt werden.
Im Dimensional Planning werden diese Ausbaustufen in Form von Straßenzuständen beschrieben. Es gibt 4 verschiedene Ausbaustufen:

  1. Feldweg (dirt road)
    Auf dieser Ebenen gibt es kaum oder gar keine Unterstützung durch das System (Workaround)
  2. Kopfsteinpflaster (cobblestone road)
    Der minimale Funktionsumfang um den Anwender in die Lage zu versetzen den Anwendungsfall selber durchzuführen
  3. Asphaltierte Straße (asphalted road)
    Eine Implementierung mit der ein Benutzer so eben leben kann
  4. Autobahn (highway)
    Die richtige Implementierung mit dem vom Benutzer erwarteten Komfort

Nehmen wir einmal an, wir sollen als Teil unserer Anwendung den Export von Daten realisieren. Die zugehörige User Story könnte lauten:

Als Sachbearbeiter möchte ich die Liste der vom Kunden bestellten Artikel nach Excel exportieren, damit ich sie anschließend in meinen Office Anwendungen weiter bearbeiten kann.

Die unterschiedlichen Ausbaustufen könnten sich beispielsweise so gestalten:

  • Feldweg
    Der Benutzer bekommt eine SQL Statement bereit gestellt, dass er mit Hilfe eines externen Tools auf der Datenbank ausführen muss. Das Ergebnis kann er mit Hilfe des Tools oder über die Zwischenablage manuell nach Excel übernehmen
  • Kopfsteinpflaster
    Die Liste der bestellten Artikel wird dem Benutzer in der UI der Anwendung angezeigt und die Datensätze können von dort markiert und dann über die Zwischenablage nach Excel kopiert werden
  • Asphaltierte Straße
    Dem Benutzer wird eine Funktion “Export nach Excel” angeboten, die die Daten in ein neues Excel Dokument schreibt und dieses dann automatisch öffnet
  • Autobahn
    Die Funktion schreibt nicht nur die Daten nach Excel sondern sorgt auch für die richtige Formatierung und die richtigen Spaltenbreiten

Obwohl die User Story immer die gleiche ist, unterscheidet sich der Aufwand für die Implementierung unter Umständen erheblich. Definiert man User Stories immer nur als Autobahnen, führt das unter Umständen dazu, dass man sehr viel Aufwand in einzelne User Stories investiert. Das wiederum kann dazu führen, dass man andere Stories gar nicht erst umsetzt und ganze Funktionen nicht rechtzeitig vorhanden sind. Ändert man sein Vorgehen und realisiert zunächst die benötigten Funktionen nur als “Kopfsteinpflaster” oder “Asphaltierte Straße”, dann kann der Benutzer zumindest seine Arbeit mit dem System erledigen, auch wenn noch nicht mit dem gewünschten Komfort. Je früher man den Benutzer mit den Funktionen konfrontiert, desto früher bekommt man auch sein Feedback. Das führt dazu, dass die Spezifikation der weiteren Ausbaustufen sich besser an dem tatsächlichen Bedarf der Benutzer orientieren kann.

Für Projekte mit einem fixen Lieferzeitpunkt bedeutet das, es wird viel einfacher, den gesamten Funktionsumfang pünktlich zum Termin zu liefern. Variable ist dabei die Ausbaustufe in der die einzelnen Funktionen zu dem Zeitpunkt realisiert sind.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>