Ich habe heute meine JIRA-Plugins aktualisiert und bin nun in den Genuss der Umbenennung (*) von Greenhopper zum neuen JIRA Agile seit Version 6.3 gekommen.

Dabei finde ich eines erstaunlich, und zwar die auf der Atlassian-Seite nachzulesende Aussage “JIRA Agile makes sprint and epic information first class citizens.” Das klingt erstmal nach ein wenig Marketing-Bling-Bling, ist aber erstaunlich, weil es die bisher zweistufige Hierarchie von Vorgang und Unteraufgabe praktisch in eine dreistufige erweitert. Zwar ist das bisher in keiner Navigation visualisiert, aber man kann es sich schon gut vorstellen.

Der Einschränkung auf die beiden Stufen konnte man bisher mit Komponenten begegnen, die wie Tags funktionieren: Eine zeitlose Zuordnung zwischen Tickets und einem Label. Ein Ticket kann man dabei auch mehreren Komponenten zuordnen. Dadurch ergibt sich eine n:m-Beziehung. Ein Epic (dt. Epos, pl. Epen) ist im Gegensatz zur Komponente nicht horizontal, sondern vertikal über den Vorgängen organisiert. Dadurch lassen sich verschiedene User Stories zu einem etwas größeren Feature zusammenfassen, z.B. “Nutzerverwaltung” oder “Batch-Modus”. Man muss natürlich aufpassen, einen Epic nicht zu stark zur Komponente werden zu lassen (zum Beispiel mit einer Bezeichnung wie “Frontend”). Sonst ergeben sich Epic-Tickets, die ewig und drei Tage offen bleiben (und das versaut bekanntlich die schönen JIRA-Statistiken zur Durchlaufzeit :-)).

Was ich weiterhin bei JIRA Agile vermisse ist eine echte Integration in die “Standard-Struktur” der Vorgänge: Schätzungen im Planning Board (wir machen das auf Stunden-Basis) werden nicht in die geschätzte Zeit eingetragen, und ein in JIRA Agile angelegter Sprint ist  etwas anderes als eine Lösungs-Version. Wenn man also ein Scrum-Projekt mit JIRA Agile’s Planungshilfe organisiert, ist man wie bisher dazu verdammt, auch nur dieses Board für die tägliche Arbeit im Sprint zu verwenden. Die Burndown-Charts im Projekt zum Beispiel lassen sich nur auf einer “echten” Lösungsversion anwenden und bleiben dann leer. Trägt man dagegen eine Schätzung als Zeit am Ticket ein und organisiert die Tickets in Lösungsversionen, versteht wiederum das Agile Board nichts davon. Dann liegen alle Tickets ungeschätzt und ungeplant in einem riesigen Backlog. Nach wie vor gibt es also getrennte Welten. Schade, denn eine enge Integration war genau das Feature, worauf ich mich gefreut hatte (und dem Marketing-Bling-Bling eigentlich entnommen hatte).

Immerhin, es gibt einen Lichtblick im Dunkel der Nacht: Das Planning Board zeigt links neben dem Epic-Filter auch eine Liste der Lösungsversionen an, auf die man auch Tickets aus dem Backlog ziehen und ablegen kann. Vielleicht ergibt sich ja zumindest bei der zeitlichen Planung in den nächsten Releases eine gewisse Konvergenz.