Data-Science in Retrospektiven nutzen

Jedes Team ist unterschiedlich. Unabhängig von agilen Ansätzen wie Scrum oder Kanban oder Ansätzen aus dem klassischen Projektmanagement – eins eint alle Projekte: Perfekt und ohne Hindernisse ist kein Projekt. Und während das Team versucht, Hindernisse aus dem Weg zu räumen, damit es fokussiert arbeiten kann, ergeben sich individuelle Fragestellungen je nach Team:

• In unserem Backlog ist immer mehr Chaos aus kleineren Issues entstanden – warum ist das so? Gibt es vielleicht Gemeinsamkeiten oder Abhängigkeiten, die wir nicht (mehr) sehen?
• Ist unser Team cross-funktional aufgebaut? Gibt es Kopfmonopole und passt unser Skill-Set zu den sich entwickelnden Bedürfnissen?
• Wie präzise schätzen wir Aufwände und Teamleistung? Was sind die Einflussfaktoren, die uns Schätzungen schwer machen?
• …

Mittlerweile gibt es zahlreiche Möglichkeiten datengetrieben Antworten auf solche und ähnliche Fragen zu finden. Auch der Scrum Guide verweist auf die Empirie als Basis der drei Scrum-Säulen Transparenz, Überprüfung und Anpassung. Ebenso ist die Empirie für die Produktplanung der Product Owner:innen und für die Coaching-Arbeit der Scrum Master:innen unerlässlich.¹

Dieser Beitrag bezieht sich auf Scrum als eines der am weitesten verbreiteten Frameworks, Data-Science Methoden können aber bei jeder agilen Vorgehensweise wertbringend eingesetzt werden. Viele relevante Daten stecken in Ticketsystemen – häufig Jira, weswegen wir dieses System als Basis verwenden.

In der Praxis landen Scrum Master:innen, Product Owner:innen und Projektleiter:innen schnell mit einem Fuß in der Data-Science Domäne, wenn sie versuchen, diese Fragen über die Jira-Query Language (JQL) oder die hauseigenen Berichte von Jira auszuwerten. Was aber, wenn die Analysemöglichkeiten von Jira an ihre Grenzen stoßen, weil die Fragen des Teams zu individuell sind? Wenn andere Datenquellen in die Analysen integriert oder Daten bereinigt werden müssen, interaktive Ad-hoc Analysen oder weiterführende KI-Analysen (wie Process Mining) gefordert sind, werden die Antworten auf vermeintlich einfache Fragen schnell komplex.

Es ist möglich – und oft der erste Ansatz – Daten (sog. Issues) aus den Ticketsystemen bspw. nach Excel zu exportieren und dort zu analysieren, um unsere Fragen zu beantworten. Hier stoßen Sie jedoch schnell und unweigerlich an die 1.000-Issue-Grenze des Jira-Datenexport. Auch sind die Analysemöglichkeiten von Excel erfahrungsgemäß schnell erschöpft. In solchen Fällen braucht es individuelle, anpassbare und transparente Visualisierungsmöglichkeiten, die sowohl allgemeine Analysen bieten, die auch in Jira möglich wären, als auch weitere Analysen. Ein Ergebnis könnte zum Beispiel folgende Übersichtsseite, ein sog. Dashboard, sein:

Bild 1: Interaktives Dashboard, das verschiedene Fragenstellung anhand von Data-Science Methoden beantwortet

• Dashboards können auf jede Art von Jira-Projekt angepasst werden (Scrum, Kanban oder klassisches Projekt).
• Ein Jira-Projekt mit wenigen Monaten Laufzeit reicht hierzu als Datenbasis erfahrungsgemäß schon aus.
• Sie ist für sämtliche Projektgrößen, von Einzelprojekten bis hin zu großen „scaled agile“ Multi-Projekten oder Projektprogrammen geeignet.
• Die Methode ist auf individuelle Fragestellungen anpassbar und mit anderen Datenquellen kombinierbar.

Im Folgenden stellen wir einige Anwendungsfälle vor, die sich mit Data-Science Methoden und einem Dashboard beantworten lassen. Zum Schluss stellen wir das technische Vorgehen zum Jira-Datenabzug und die verwendeten Methoden kurz vor – der Fokus liegt aber auf den Lösungsmöglichkeiten.

Backlog aufräumen – unterstützt durch Datenanalyse

In einem Backlog sammeln sich Anforderungen, gewünschte Features oder auch Ideen für Erweiterungen. Häufig wächst dieses mit der Zeit immens. Zwischen wichtigen Anforderungen befinden sich veraltete Anforderungen, Duplikate oder Features, die längst umgesetzt wurden. Dies macht die Priorisierung schwierig und zerstört den Überblick für relevante Fragestellungen. Es ist daher unabdingbar, das Backlog von Zeit zu Zeit aufzuräumen. Hier leisten interaktive Dashboards erhebliche Unterstützung, indem sie Möglichkeiten aufzeigen, wie das Backlog aussortiert und systematisch abgearbeitet werden kann.

Bild 2: Interaktives Dashboard mit verschiedenen Informationen zum Backlog

Die Darstellung von Issues und ihren Eigenschaften in einer 2D-Landschaft ermöglicht es dabei ähnliche Sachverhalte nah beieinander abzubilden.  Jedes Issue wird in der 2D-Issues-Landschaft durch einen Punkt dargestellt. Zur Aufbereitung der Daten werden automatisiert Data-Science Methoden angewendet. Die Textfelder der Issues werden durch geeignete Natural Language Processing (NLP) Verfahren wie BERT vektorisiert und mit Dimensionsreduktionsverfahren wie UMAP (Uniform Manifold Approximation Projection)² auf einen zweidimensionalen Raum projiziert.

Die Issues können zusätzlich nach unterschiedlichen Kriterien eingefärbt und in einer interaktiven Visualisierung dargestellt werden, sodass Nutzer:innen durch Hovern über die Punkte/Issues einzelne Issues genauer betrachten und mit ähnlichen Issues vergleichen können.

Bild 3: Issues in einer 2D Landschaft mit Einfärbung je nach Status – im Bild ist die Maus über ein Issue gehooverd, sodass Details zu dem Issue aufgepoppt sind.

• Welche Issues sind ähnlich oder doppelt und sollten fusioniert werden?
• Welche Issues sind veraltet oder wurden bereits im Rahmen anderer Arbeiten erledigt?
• Welche Issues haben keine:n Bearbeiter:in und wer könnte ein:e sinnvolle Bearbeiter:in sein?
• Welche Issues sind zu groß und müssen geschnitten werden?
• Bietet sich eine Gruppe von inhaltlich ähnlichen Issues an, um gemeinsam in einen Sprint zu wandern?

In der abgebildeten Darstellung werden neben dem Backlog auch die abgeschlossenen Issues visualisiert, um den Gesamtkontext des Produktes abzubilden. Issues im Status ‚Done‘ sind grün, im Status ‚Backlog‘ mit Bearbeiter:in gelb und im Status ‚Backlog‘ ohne Bearbeiter:in rot eingefärbt. Für die Identifizierung von ähnlichen oder doppelten Backloginhalten sind die roten und gelben Punkte in der Grafik relevant, denn diese wurden noch nicht bearbeitet. Vergleichen Sie diese mit den naheliegenden Datenpunkten, erscheinen Issues mit ähnlichem Inhalt. Dann kann entschieden werden, ob eine Fusion oder das Setzen einer Abhängigkeit zu anderen bereits bestehenden Inhalten sinnvoll ist. Um veraltete Inhalte zu identifizieren, können Sie offene Anforderungen im Backlog mit ähnlichen Issues im Status ‚Done‘ vergleichen und überprüfen, ob hier Anforderungen in Teilen bereits umgesetzt wurden.

Die Grafik bietet noch mehr Analysepotential. Ein Großteil der Anforderungen ist bereits umgesetzt – kann aus diesen erledigten Issues etwas für die offenen Anforderungen gelernt werden? Sinnvoll ist es, die Bearbeiter:innen abgeschlossener Issues für ähnliche, zukünftige Umsetzungen im Refinement zu Rate zu ziehen. Eventuell können Synergieeffekte bei der Bearbeitung genutzt werden, evtl. werden Kopfmonopole deutlich, die es bei der Bearbeitung der Tickets im Backlog zu berücksichtigen gilt.

Cross-Funktionalität und Kopfmonopole – auffindbar durch Data-Science

Kopfmonopole und fehlende Cross-Funktionalität des Teams stellen erhebliche Risiken oder auch Engpässe für ein Projekt dar. Wissen über das Projekt droht verloren zu gehen, wenn der:die Inhaber:in des Kopfmonopols ausfällt oder das Projekt verlässt. Die im vorherigen Abschnitt verwendete Methode und die 2D-Issue-Landschaft, kann das Team verwenden, um solche Kopfmonopole zu reflektieren.

Issues mit ähnlichem Inhalt liegen wieder nebeneinander. Nun sind Issues je nach Bearbeiter:in eingefärbt. Issues mit demselben:derselben Bearbeiter:in, haben dieselbe Farbe und unter Berücksichtigung der Fairness und des Datenschutzes können folgende Fragen beantwortet werden:

• Ist das Team cross-funktional oder existieren Kopfmonopole in einzelnen Bereichen?
• Gibt es externe Bearbeiter:innen, die nicht zum Scrum Team gehören?

Sind Bereiche der Grafik (Bild 4) in derselben Farbe eingefärbt, weist dies auf ein Kopfmonopol hin. Ist die Grafik bunt eingefärbt, agiert das Team cross-funktional. Außerdem fällt schnell auf, welche Issues von Bearbeiter:innen außerhalb des Teams umgesetzt wurden. Besteht hier eventuell Schulungsbedarf, damit die Mitglieder des Scrum Teams in Zukunft ähnliche Issues eigenständig bearbeiten können?

Anhand dieser Grafik können Sie schnell erkennen, welches Mitglied des Scrum Teams am nächsten an diesem Thema dran ist und überlegen, ob es sinnvoll ist, diese:n Kolleg:in mit einer Weiterbildung zusätzlich zu unterstützen.

Bild 4: Issues sind anhand ihrer Bearbeiter:innen eingefärbt. Sie sehen keine größeren Cluster: Alle können sich thematisch überall einbringen.

Arbeiten wir fokussiert auf ein Sprintziel hin und passt unsere Velocity?

Scrum Teams entwickeln über die Zeit ein Gefühl, wie viele Aufgaben sie pro Sprint abarbeiten können. Oft werden Story Points für Schätzungen der Inhalte verwendet. Die Gesamtanzahl der umgesetzten Story Points wird dann als Velocity bezeichnet und kann zur Planung zukünftiger Sprints herangezogen werden. Stellen Sie als Team fest, dass am Ende eines Sprints häufig Issues nicht fertig sind, könnte es sein, dass das Scrum Team sich falsch einschätzt. Existiert eine Diskrepanz zwischen geplanter und tatsächlich umgesetzter Velocity? Diese Frage lässt sich in einem Dashboard leicht visualisieren.

Bild 5: Zeitlicher Verlauf zur Diskrepanz zwischen geplanter und tatsächlich umgesetzter Velocity

• Wie kommt es, dass die Velocity in unserem Projekt so sehr schwankt?

Dazu hatten wir die These, dass Schwankungen anhand von Sprintinhalten zu erklären sind: Je ähnlicher die Issues in einem Sprint sind, desto effizienter wird der Sprint durch Synergieeffekte. Diese Hypothese lässt sich ebenfalls mit einer KI-Methode untersuchen.

Zuerst wird die Heterogenität eines Sprints mit der Methode SBERT (Sentence Bidirectional Encode Representations from Transformer) bestimmt. Diese Methode wird auch verwendet, wenn Webseiten ähnliche Artikel zu einem Artikel anzeigen: „Folgender Artikel könnte Sie auch interessieren“. Bei der Methode werden Sätze in einen mehrdimensionalen Raum eingebettet, sodass semantisch ähnliche Sätze nah beieinander liegen. So lässt sich auch der Text aus Titel und Beschreibung eines Issues als Text im Mehrdimensionalen platzieren. Punkte, die nah beieinander liegen, entsprechen Issues, die semantisch ähnlich sind. Danach lässt sich eine Heterogenitätskennzahl für jeden Sprint bestimmen und mit der Velocity des Sprints korrelieren.

Bild 6: Streudiagramm zeigt Korrelation zwischen Heterogenität und Velocity: Je unterschiedlicher die Tickets im Sprint, desto höher war die Velocity.

Bei dem hier analysierten Team war der Sprint mit der höchsten Velocity gleichzeitig ein Sprint mit hoher Heterogenität. Auch statistisch ließ sich zeigen, dass je heterogener ein Sprint war, desto höher war tendenziell die Velocity des Sprints. Ein Grund könnte sein, dass parallele Bearbeitung unterschiedlicher User Storys den Koordinationsaufwand der Entwickler:innen reduziert, da sie sich während der Bearbeitung nicht mit anderen Entwickler:innen abstimmen mussten oder auf umgesetzte Features der anderen warten mussten. In so einem Fall wird von Single Developer Velocity gesprochen – dies erhöht aber das Risiko eines Wissensmonopols.

Entspricht der typische dem geplanten Arbeitsablauf in unserem Projekt?

Welche Schwachstellen hat unser Prozessablauf? Gibt es Bottlenecks oder springen Issuess oft zwischen Status hin und her?

Diese Fragen können innerhalb eines Teams gestellt werden, um Auffälligkeiten und Optimierungspotentiale im Prozess zu erkennen. Jira-Daten bieten die Möglichkeit die Änderungshistorie der umgesetzten Aufgaben nachzuvollziehen und dieses „Event Log“ als Basis für Process Mining zu nutzen. Neben dem Prozessablauf in Form der Statusänderungen, können auch weitere Änderungen wie Kommentare oder Bearbeiterwechsel als Events einbezogen werden. Der entstandene Graph hat alle Statusänderungen als Knoten. Als Kantengewichtung kann einerseits die Anzahl der Issues, andererseits die Prozessschrittdauer genutzt werden.

Folgende Fragestellungen können anhand der Analyse beantwortet werden:

• Welchen Weg gehen die Issues häufig? Entspricht dies dem von uns in Jira definierten Prozess?
• Welche ungewöhnlichen Abläufe kommen regelmäßig vor? Warum kommt es zu diesem Arbeitsablauf?
• Was sind die ungewöhnlichen Prozessabläufe? Werden geschlossene Issues häufig wieder geöffnet?
• Dauern Prozessschritte auffällig lange?

Können Sie sich erklären, warum Issues in Ihrem Projekt häufig diese Statusänderungen durchlaufen?

Bild 7: Häufige Statusübergänge in einem Projekt dargestellt in einem Graph: In dieser Grafik springen Issues häufig von“done“ zurück auf „in progress“. Vielleicht ist die Definition of Done in diesem Projekt nicht präzise genug, sodass zu viele Fehler nach dem Testen gefunden werden?

Technischer Hintergrund zum Jira-Datenabzug und zur Datenaufbereitung

Die oben beschriebenen Anwendungsszenarien machen den Datenschatz der in Jira verwalteten Informationen deutlich. Wie können Sie diese Daten extrahieren und Analysen realisieren?

Viele komplexe Auswertungen lassen nicht durch die von Jira bereitgestellten Berichte und JQL-Ausdrücke umsetzen. Hierfür bietet sich die Jira API³ zum Export der Issuesdaten an. Diese wird durch ein Token mit denselben Rechten autorisiert, die der:die Anwender:in im Frontend von Jira hat. Auf diese Weise lassen sich nur Issuess und Informationen extrahieren, auf die auch auf der Jira Oberfläche zugegriffen werden kann.

Um diese Datenextraktion und -aufbereitung schnell und unkompliziert auf verschiedene Projekte und Anwendungsszenarien anzuwenden, haben wir Python Skripte entwickelt, die diesen Extraktionsschritt automatisieren. Das Ergebnisformat der REST API sind zunächst JSON Daten, die alle Issueinformationen, Sprintzeiten und Änderungshistorien beinhalten. Für eine weitergehende Analyse werden diese in ein tabellarisches Datenformat gebracht, sodass als Ergebnis der Datenaufbereitung csv-Dateien mit den relevanten Informationen entstehen.

Für manche Analysen, die bspw. Experten für ein Thema innerhalb eines Teams identifizieren, ist ein Personenbezug sinnvoll. Allerdings werden im Großteil der Analysen personenunabhängige Muster oder Informationen betrachtet. Im Sinne des Datenschutzes sollten diese ohne Personenbezug stattfinden. Hierfür werden bei der Datenaufbereitung automatisiert die personenbezogenen Daten (Bearbeiter:innen, Beobachter:innen und Verlinkungen in Textfeldern) pseudonymisiert. Daneben kann ein Whitelisting Ansatz verfolgt werden, um nur Ticketinformationen ohne Personenbezug in die Analysen zu integrieren. Sobald die Daten tabellarisch aufbereitet wurden, können weitergehende Analysen realisiert werden. Die geschaffene Datenbasis ermöglicht den Einsatz beliebiger Tools.

Die vorgestellten Analysen setzen einen weiteren automatisierten Aufbereitungsschritt voraus. In diesem werden zunächst die textuellen Felder vektorisiert. Welche Felder relevant sind, bestimmt der individuelle Anwendungsfall und kann konfiguriert werden. Als NLP-Verfahren bietet sich BERT⁴ – ein vortrainiertes Modell, das von Google entwickelt wurde – an, da es die Wörter vektorisiert und dabei die Kontextinformationen des Satzes berücksichtigt. Damit Wörter mit einer geringen Bedeutung das Ergebnis nicht verfälschen, werden Stopwords (bspw., und, oder) aber auch individuelle Begriffe wie Firmennamen, die zuvor konfiguriert werden müssen, entfernt. Das Ergebnis ist eine Vektorrepräsentation, die für verschiedene Auswertungen weitergenutzt werden kann.

Für die Visualisierung und Bereitstellung der Analysen bietet sich ein interaktives self-service Dashboard wie beispielsweise PowerBI oder tableau an. Auf diese Weise kann das Projektteam, Scrum Master:innen:in, Product Owner:innen:in oder Projektleiter:in individuelle Fragestellungen beantworten und den geeigneten Detailgrad wählen.

Bild 7: Der Weg der Daten aus Jira über die REST-API in ein Dashboard.

Fazit

Projektteams sammeln in Ticketsystemen wie Jira einen immensen Datenschatz, der zur eigenen internen Reflektion genutzt werden kann. Ihn für die Teams zu erschließen, wird immer einfacher. Dabei müssen die Jira-Daten nicht zwangsweise manuell exportiert, umständlich aufbereitet und ausgewertet werden, sondern können mit Hilfe von interaktiven und passend aufbereiteten Dashboards Antworten auf die jeweiligen, individuellen Fragen liefern.

Im Zuge der Datenanalyse gilt es separat und explizit zu berücksichtigen, dass Auswertungen nicht als Kontrollinstrument zweckentfremdet werden. Außerdem gilt es zu beachten, dass viele der Grafiken ohne das Kontextwissen der Teams nicht sinnvoll interpretierbar sind. Trotzdem können mit dieser Methode Projektfortschritte und bestimmte Fragestellungen sinnvoll visualisiert werden. Auf dieser Basis können individuelle Themen im Team diskutiert werden und mögliche Handlungsbedarfe abgeleitet werden. Eventuell kann auch die Zusammenarbeit und Kommunikation mit Stakeholder:innen von der Datenanalyse profitieren.

Hinweise:

Interessieren Sie sich für eine Einrichtung eines automatischen Datenexports für die Erstellung eines ersten Dashboards (z. B. mit PowerBI) und eine Auswertung durch professionelle Data Scientist:innen und Agile Coaches? Dann laden Sie Dr. Ina Humpert und Ronja Köhling gerne zu einer datengetriebenen Retrospektive ein und kommen Sie ins Gespräch. Alternativ können Sie auch gerne beim umfangreichen Schulungsangebot zum agilen Arbeiten von viadee vorbeischauen.

[1] Schwaber, Ken and Sutherland, Jeff. Der Scrum Guide. (2020)
[2] UMAP
[3] Jira REST API
[4] Devlin, J., Chang, M.W., Lee, K., & Toutanova, K.. (2018). BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding.

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Dr. Ina Humpert und Ronja Röhling haben einen weiteren Beitrag im t2informatik Blog veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.