Im Kontext einer agilen Projektabwicklung dauert es jeweils nicht lange bis man dem Begriff der „User Story“ begegnet. In dieser zweiteiligen Artikelserie möchte ich zusammenfassen, wie man das aus der Softwareentwicklung stammende Konzept auf Analytics-Vorhaben (aka Business Intelligence und Data Warehousing) übertragen kann.
User Stories oder allgemeiner Stories sind ein Hilfsmittel zur Strukturierung von Anforderungen. Roman Pichler fasst es wie folgt zusammen:
“(User) stories are intended as a lightweight technique that allows you to move fast. They are not a specification, but a collaboration tool. Stories should never be handed off to a development team. Instead, they should be embedded in a conversation: The product owner and the team should discuss the stories together. This allows you to capture only the minimum amount of information, reduce overhead, and accelerate delivery.”
Damit die nachfolgenden Ausführungen etwas weniger abstrakt werden, möchte ich zuerst ein simples, fiktives Fallbeispiel einführen. Nehmen wir einmal an, ein Verein wie der TDWI (wo ich selber aktives Mitglied bin) möchte ein neues Vereinsdashboard. Dazu hat der Projektleiter bereits erste Ideen als Mockup, d.h. als Skizze, illustriert:
Grundlagen
Die Formulierung einer User Story folgt dabei einem bestimmten Schema, wobei es unterschiedliche Grundformen gibt. Das gebräuchlichste Schema lautet so:
Nicht in allen Projekten wird ein System gebaut, welches direkt auf die Benutzung durch Users, also Endbenutzer, ausgerichtet. Nehmen wir an, wir bauen eine Persistent Staging Area und darauf basierend eine Datenschnittstelle, welche integrierte Daten an ein anderes System liefert. In solchen Fällen wirkt es etwas künstlich, von „User Stories“ zu sprechen. Folgend ein alternatives Schema, wie eine Story formuliert werden kann (Quelle):
Eine der zentralen Fragen bei der Anwendung von Stories ist stets das „Schneiden“ der Stories. Wie gross oder umfangreich soll eine Story sein? Ich verfolge dabei drei Grundsätze:
- Die Story ist die kleinste Planungseinheit ist, mit welcher ich in einem Projekt plane. Natürlich kann man dann eine Story auch noch in Aufgaben und technische Entwicklungsschritte aufteilen. Das ist dann aber Sache der umsetzenden Personen. Solange wir auf der Ebene sind, wo der Product Owner und damit eine Fachperson involviert ist, bleiben wir auf Ebene der Story.
- Die maximale Umsetzungszeit einer Story ist auf ein, maximal zwei Arbeitstage limitiert. Das inkludiert die Präzisierung der Anforderungen („reminder to have a conversation about it), die technische Umsetzung sowie das integrierte Testing. Das zwingt uns zu kleinen Stories mit einer mehr oder weniger einheitlichen Grösse. Dieses Prinzip ermöglicht, dass sich ein „Flow“ in der Umsetzung täglich messen lässt (an dieser Stelle dürfte dann auch klar sein, dass ich wenig vom Prinzip der Story Points halte, das ist aber eine andere Geschichte…)
- Eine Story hat immer einen „end to end“ Charakter und ihre Umsetzung soll ein nutzbares Inkrement in der Umsetzung des Gesamtsystems liefern. Im Kontext von Analytics bedeutet dies oft, dass eine Story eine Datenquelle als Start hat und eine Form der Datenauswertung als Ende.
Schauen wir uns das etwas konkreter anhand des Fallbeispiels an. In einem ersten Schritt fokussieren wir auf einen bestimmten Teil des Dashboards – nennen wir das „Feature 1“ – wo es um die Auswertung de Anzahl Teilnehmer geht:
Noch unabhängig von der technologischen Umsetzung können wir an dieser Stelle zwei Dinge ableiten: Ein einfaches, analytisches Datenmodell (z.B. in Form eines Stern-Schemas) sowie die benötigten Datenquellen (zur Erinnerung: Das Beispiel ist rein fiktiv). Bezogen auf die vorgängig formulierten Grundsätze stellt sich nun die Frage, was „end to end“ bedeutet. In einfachen Fällen kann es gut möglich sein, dass sich der Umfang einer Story von der Datenquelle über das Datenmodell bis und mit dem eigentlichen Dashboard erstreckt und sich dieser Umfang in ein bis zwei Arbeitstagen problemlos umsetzen lässt. Was aber, wenn allein die technische Erschliessung der Datenquelle mehrere Tage Arbeitsaufwand bedeutet? Oder die Berechnung einer komplexen Kennzahl mehrere Workshops bedingt?
Gerade in grösseren Organisationen höre ich dann: „Dieser End-to-End-Gedanke ist zwar nett, aber das funktioniert bei uns nicht. Wir schreiben lieber „technische“ Stories“. Damit ist dann beispielsweise gemeint: Ich als Datenarchitekt modelliere die Faktentabelle XY und Event-Dimension. Ich als ETL-Entwickler belade die Faktentabelle XY und die Event-Dimension. Ich als Datenschutzbeauftragter definiere die Row-Level-Security für Faktentabelle XY. Obwohl jedes dieser Beispiele im Gesamtsystem einen Nutzen bringt, für sich alleine bringt es noch keinen Mehrwert und ist schwierig testbar. Die andere Antwort lautet: „Diese End-to-End-Geschichte macht absolut Sinn, aber das funktioniert nicht mit einer Durchlaufzeit von ein bis Arbeitstagen. Wir arbeiten halt einfach zwei, drei Wochen an einer Story“. Das ist nicht minder problematisch. Wenn die Umsetzung einer Story mehrere Wochen dauert, dann wird die Erfolgs- und Fortschrittskontrolle sehr schwierig. Im dümmsten Fall merken wir nicht bereits nach ein oder zwei Tagen, dass wir auf dem falschen Dampfer sind sondern erst nach drei oder sogar vier Wochen.
Beides – technische Stories sowie „lange“ Stories – gilt es zu vermeiden. Wie das genau gehen soll, erläutere ich im zweiten Teil dieser Serie.
