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. Im ersten Teil habe ich die Grundlagen zu Stories zusammengefasst. Nun möchte ich erläutern, wie wir Stories strukturieren bzw. schneiden können, damit sie den Umständen in Analytics-Systemen und deren Entwicklungsprojekte gerecht werden und gleichzeitig die drei folgenden Grundsätze erfüllen:
- Die Story ist die kleinste Planungseinheit ist, mit welcher ich in einem Projekt plane.
- Die maximale Umsetzungszeit einer Story ist auf ein, maximal zwei Arbeitstage limitiert.
- Eine Story hat immer einen „end to end“ Charakter. Im Kontext von Analytics bedeutet dies oft, dass eine Story eine Datenquelle als Start hat und eine Form der Datenauswertung als Ende.
Vom Feature zur Story
Werfen wir zuerst einen Blick auf die folgende Graphik – anschliessend gehen wir sie Punkt für Punkt durch:
Auf der linken Seite sehen wir den vereinfachten Architekturstack einer Analytics-Lösung. In Bezug auf die Anforderungserhebung und der anschliessenden (agilen) Projektstrukturierung reichen die abgebildeten drei Ebenen in den meisten Fällen aus:
- BI Applikation: Das ist das meist sichtbare Gesicht einer Analytics-Lösung. Es handelt sich um Informationsprodukte aller Art, von Reports über Dashboards aber auch Datenschnittstellen zu anderen Systemen. Oft setzt sich das fertige Produkt auf dieser Stufe aus Daten zusammen, die aus mehreren Entitäten der Ebene darunter zusammensetzen, z.B. Daten aus einem Sales Datamart und einem Logistik Datamart.
- DWH bzw. Datengrundlage: Hier fasse ich bewusst die Ebenen Core Data Warehouse und Datamart zusammen. Auch wenn es technisch unterschiedliche Dinge darstellt, im Hinblick auf den praktischen Nutzen einer Story bringt ein Core-DWH alleine noch kaum ein Mehrwert, sondern erst durch die Umsetzung erster Kennzahlen und der Anwendung von fallspezifischen Geschäftsregeln kommt der Nutzen der Daten wirklich zum Tragen.
- Konnektivität und Infrastruktur: Das Erschliessen einer neuen Datenquelle kann mitunter eine aufwändige Sache sein. Ebenso das initiale Bereitstellen der benötigten Infrastruktur. Es versteht sich von selbst, dass bei einer maximalen Umsetzungszeit einer Story von ein bis zwei Tagen eine bereits etablierte Infrastruktur vorausgesetzt ist. Das heisst aber auch, dass wir dafür eigene Stories benötigen, um diese Grundlage zu entwickeln.
In vielen (wenn auch nicht in allen) Fällen besteht eine Analytics-Lösung aus allen drei Ebenen. An dieser Stelle spielt die Technologie eine untergeordnete Rolle, so ist z.B. denkbar, dass der DWH-Aspekt im übertragenen Sinne rein virtuell im BI-Frontend-Tool abgebildet werden. Inhaltlich muss er dennoch gleichermassen bedacht werden (vgl. dazu auch das Modell der Architektur-Tshirt-Grössen). Diese drei Ebenen stellen für mich die Makrovariante von „end to end“ dar – vom eigentlichen Quellsystem zum fertigen Informationsprodukt. Auf dieser Makro-Ebene spreche ich gerne von „Features“. Ein Feature wird analog einer User Story formuliert, ein Beispiel dazu finden Sie oben rechts in der Graphik. Ein Feature wird häufig im Rahmen von zwei bis drei Wochen umgesetzt. Damit ist das Gefäss aber zu gross für die tägliche Erfolgsmessung im Projekt. Ein Feature muss so dann weiter geschnitten werden in Epics und Stories auf den drei Ebenen BI Applikation, DWH / Datengrunldage sowie Konnektivität und Infrastruktur. Epics stellen dabei lediglich eine thematische Klammer dar. Nehmen wir an, das Feature 1 im fiktiven Vereinsdashboard (vgl. erster Teil) lässt sich auf Ebene BI-Applikation mittels vier Stories umreissen. Dann würde ich diese vier Stories einer Epic zuweisen und dadurch die Zusammengehörigkeit der Stories abbilden.
Bei der Aufteilung in die drei Architekturebenen ist der zentrale Aspekt, dass jede Ebene für sich genommen ebenfalls „end to end“ Charaketer hat, diesmal aber auf der Mikroebene. Zudem überlappen sich diese drei Ebenen bewusst etwas. Nehmen wir wieder das Beispiel des Vereinsdashboards und die abgebildete Story: „Als TDWI Backoffice Mitarbeiterin will ich ein Diagramm, welches die angemeldeten Teilnehmer pro Roundtable in einer auswählbaren Stadt darstellt.“ Damit diese Story umgesetzt werden kann, ist unsere Datenquelle das zugrundeliegende Datenmodell. Allenfalls ist es auch so, dass dieses punktuell noch angepasst oder erweitert werden muss im Rahmen der Applikationsstory. Das Endprodukt ist ein Teil des fertigen Dashboards und erzeugt potentiell sofort einen Nutzen für den Endbenutzer.
Wenn wir auf die Ebene des DWHs gehen, dann setzen wir als Quelle auf eine bereits etablierte Schnittstelle zum Quellsystem auf sowie einer funktionierenden Dateninfrastruktur. Wie aber sieht das andere Ende aus, wo wir ebenfalls eine Form der Auswertung erwarten? Wir brauchen dazu nicht ein komplettes Dashboard zu bauen – dafür gibt es ja eine eigene Story. Aber wir können on top von jedem Datenmodell eine einfache Auswertung generieren, z.B. auf Basis von Excel, und Daten damit sichtbar machen. Und sofort kann beispielsweise der Product Owner mit dem DWH-Entwickler ins Gespräche kommen, ob diese ersten Resultate den Erwartungen entsprechen.
Selbst auf Ebene der Konnektivität lässt sich dieses Prinzip anwenden. Hier ist das Quellsystem die Ausgangslage. Im abgebildeten Beispiel handelt es sich um einen fiktives, webbasiertes System, welches entweder einen CSV-Export oder eine Webserviceabfrage ermöglicht. Im Rahmen einer ersten User Story wird ein CSV-Export in einen Load-Layer des DWHs geladen. Das Resultat, welches der Product Owner zu Gesicht bekommt, ist dabei nicht einfach eine Tabellendefinition, sondern wiederum eine einfache Auswertung dieser Rohdaten. Das ermöglicht dem Product Owner beispielsweise schon früh etwaige Datenqualitätsprobleme zu entdecken.
Wie Sie den Beispielstories entnehmen können, nutze ich auf Ebene Feature und BI-Applikation gerne das „traditionelle“ Story-Schema mit „Ich (Endbenutzer) in meiner Rolle als <xy> will <abc> damit <def>“. Auf den Ebenen DWH sowie Konnektivität und Infrastruktur bietet sich ein alternatives Schema an: <Aktion> die|der|das <Resultat> <nach|für|von|in> <Objekt>.
Zusammenfassung und Ausblick
In diesem zweiten Artikel der Serie zu (User) Stories im Analytics-Umfeld habe ich aufgezeigt, wie sich kleine Stories mit dem Anspruch von „end to end“ einer Story vereinbaren lassen. Wichtig ist dabei, das grosse Ganze („Feature“) nicht aus den Augen zu verlieren und gleichzeitig auf Epic und Story Ebene immer auf die konkret sichtbare Auswertung hinzuarbeiten.
Selbst mit dieser Strukturierung ist es aber immer noch eine Herausforderung, Stories so zu schneiden, dass sie in ein bis zwei Tagen umsetzbar sind. Dazu gibt es ebenfalls viele praxistaugliche Ansätze – und Stoff für einen weiteren Blogartikel ;-)
