In JIRA verwalten Unternehmen ihre Projekte, Epics, User-Stories und Detailaufgaben. Anforderungen werden hier in konkrete Tickets übersetzt, die zugewiesen und abgearbeitet werden können. Abhängigkeiten sind hier abgebildet. Projektfortschritte werden mit JIRA gemessen und ausgewertet.
Auch Confluence kennt seit einigen Jahren Aufgaben und Aufgabenlisten. Dazu hat uns vor einer Weile jemand auf Twitter angesprochen:
Ich frage mich, wann ihr Aufgabenlisten von Confluence statt JIRA verwendet?
Gute Frage, zu der mir direkt weitere einfallen: Kommt es da nicht zu Redundanzen? Sollten nicht besser sämtliche Aufgaben akkurat in einem System existieren? Gehen Aufgaben nicht weit über das hinaus, was Confluence leisten soll und kann? Dazu ein paar Gedanken und Erfahrungen.
JIRA-Tickets sind operationalisiert und unterliegen Workflows
In JIRA lässt sich eine Aufgabe natürlich viel besser operationalisieren als in Confluence. Der Ersteller kann eine Zusammenfassung und eine Detailbeschreibung kommunizieren, gegebenenfalls unterstützende Anhänge beifügen, den Aufwand schätzen, eine Priorisierung vornehmen, einen Fertigstellungstermin festlegen und so weiter. JIRA-Tickets befinden sich im Rahmen eines konkreten Projekts und sie unterliegen spezifischen Workflows, in denen festgelegt ist, welche Transitionsschritte die Aufgabe von der Erstellung bis zum Abschließen durchlaufen muss.
Wenn die Leute im Unternehmen so mit JIRA arbeiten, wie Atlassian sich das vorstellt, ist für jede Aufgabe der aktuelle Bearbeitungsstand jederzeit ersichtlich, inklusive der aufgewendeten Zeit. JIRA-Tickets sind im System über die Suche auffindbar. Ein Vorgang hat eine unikale URL. In digitale Agile-Boards des JIRA-Projekts ist ein Ticket automatisch integriert.
Kurz: Hier sind Informationsdichte, Sichtbarkeit und Nachvollziehbarkeit ungleich höher als bei Confluence-Aufgaben. Diese bestehen aus etwas Text. Ein Fälligkeitsdatum kann noch angegeben werden. Weitere Spezifizierungsmöglichkeiten und Metainformationen gibt es nicht. Confluence-Aufgaben werden erstellt und irgendwann wortwörtlich abgehakt. Das ist der ganze Workflow. Wenn sie so wenig können – weshalb sollte man sie überhaupt nutzen und in welchen Szenarien?
Confluence-Aufgaben sind schnell erstellt und praktisch
Eine Aufgabenliste wird im Editor via Werkzeugleiste mit zwei Klicks in eine Confluence-Seite eingebaut. Die Zuweisung einer Aufgabe erfolgt ganz simpel per @-Mention. Der Bearbeiter wird automatisch per E-Mail und über seine Confluence-Workbox benachrichtigt und kann die Seite direkt aufrufen, die die entsprechende(n) Aufgabe(n) für ihn enthält.
Das ist zunächst mal deutlich weniger Aufwand als für die Erstellung und Operationalisierung einer Reihe von JIRA-Tickets. Dennoch würde (oder sollte) niemand auf die Idee kommen, die Aufgaben in einem Software-Projekt in Form von Confluence-Aufgabenlisten abzubilden. Aber es gibt auch andere sinnvolle Anwendungsfälle dafür.
Aus den meisten Meetings ergeben sich weiterführende Themen und Aufgaben. Es gibt nichts Effizienteres, als diese inklusive der Verantwortlichkeiten direkt live auf einer Wiki-Seite in Confluence festzuhalten. Hier können Aufgabenlisten insbesondere eine Vorstufe der späteren JIRA-Spezifizierung bilden. Wir machen das oft so.
Bei Confluence-spezifischen To-dos können Confluence-Aufgaben meiner Erfahrung nach ebenfalls sinnvoll sein, speziell wenn sie den tatsächlichen Inhalt einer Seite betreffen:
Theoretisch landen meine Kollegen im richtigen Kontext, wissen auf einen Blick und ohne Tool-Wechsel, was zu tun ist, und können zur Tat schreiten. (Auf Theorie versus Praxis komme ich unten noch zu sprechen.)
Bei uns haben sich Confluence-Aufgabenlisten auch für die letzten Schritte bei der Organisation von Veranstaltungen bewährt:
Analog dazu arbeiten wir auch bei der Reisevorbereitung mit solchen Listen. So eine Aufstellung bietet Transparenz und Verantwortlichkeiten auf einen Blick, sie ist für kurzfristig aktuelle To-dos praktisch und gut zu handhaben - und es gibt genug interne Kleinaufgaben, bei denen das Erstellen eines Tickets tatsächlich länger dauert als die Bearbeitung der Aufgabe selbst.
Keine Frage: Komplexe und Projektaufgaben gehören ins JIRA-System. Aber was Confluence-Listen JIRA-Tickets hier voraus haben: Sie stehen – wie gesagt – direkt im Kontext. Unmittelbar nach dem Meeting die live erstellten Aufgaben und weiterführenden Themen auf einer Seite mit den anderen Notizen zu haben, ist schon wertvoll und transparent. Sicher, auch mit JIRA lässt sich über Links und Beschreibungen Kontext schaffen, aber das erfordert Mehrarbeit für den Ersteller sowie Klicks und Systemwechsel beim Bearbeiter. Nicht immer ist das nötig, finde ich, und machbar ist es auch nicht immer. Wenn ich ein Ticket Linchpin-Flyer auslegen erstelle, kommt mir das komisch vor. Und in einem Meeting kann ich live keine JIRA-Tickets anlegen.
Unterschiedliche Verantwortlichkeiten
Neben den funktionalen Aspekten und den Anwendungsfällen unterscheiden sich JIRA- und Confluence-Aufgaben im Hinblick auf die Ownership. Sprich: Wer hat den Hut dafür auf, dass die Aufgaben auch tatsächlich (und gegebenenfalls auch innerhalb des vorgesehenen Zeitfensters) erledigt werden?
In den meisten Software-Teams ist das heute das Team in seiner Gesamtheit, das seine To-dos in Backlog-Groomings, Sprintplanungen und Daily-Standup-Meetings zusammen mit dem Product Owner priorisiert und zur Bearbeitung einplant. In anderen Teams gibt es einen Projektmanager, dem das JIRA-Projekt 'gehört'. Wenn JIRA professionell und systematisch genutzt wird, dürfte es auf jeden Fall jemanden geben, der die Übersicht und den Hut auf hat.
Bei Confluence-Aufgaben ist das nicht so klar. Soll vielleicht ein Product Owner bzw. ein Projekt-, Team- oder Abteilungsleiter alle To-dos im Blick haben, die in einem bestimmten Confluence-Bereich angelegt werden? Das ist nicht so ohne Weiteres möglich, denn Confluence bietet keinen Suchfilter speziell für Aufgaben, über den man regelmäßig nach neuen Tasks suchen könnte.
Hier liegt die Verantwortung für die Abarbeitung eher beim Listenersteller beziehungsweise beim Owner der entsprechenden Seite. Eine solche Liste dient oft eher seiner eigenen Übersicht als der konkreten Organisation der Teamarbeit.
Verbindlichkeit
JIRA ist das offizielle Projekt- und Aufgabenmanagement-System im Unternehmen. Dementsprechend hoch ist die Verbindlichkeit und das Maß an Eigenverantwortung: Ein offizielles JIRA-Ticket bedeutet für den Bearbeiter, dass hier eine Aufgabe definitiv zu erledigen ist (oder ein Ticket zumindest Aufmerksamkeit und Abstimmung erfordert). Dazu kommt der Druck des eigenen Teams und des Product Owners / Projektmanagers, die ein sauberes, akkurat dokumentiertes, auswertbares Projekt haben wollen.
Erfahrungsgemäß unterliegen Confluence-Aufgaben einer größeren Gefahr, im Sande zu verlaufen. Hier entstehen grundsätzliche Fragen: Kann man es von den Kollegen verlangen, dass sie Confluence-Aufgaben eine gleichermaßen hohe Aufmerksamkeit entgegenbringen wie ihren JIRA-Tickets? Wenn die Tasks wichtig sind – weshalb stehen sie dann nicht in JIRA?
Insofern hat der Ersteller in diesem Zusammenhang eine gewisse Holschuld: Jemandem in Confluence eine Aufgabe zuzuweisen und dann vorauszusetzen, dass der Kollege sie bearbeiten wird, kann daneben gehen. Sie fliegt nun mal unter dem 'offiziellen' JIRA-Radar. (So viel zur Kluft zwischen Theorie und Praxis.)
Wie verfährt man nun am besten?
Wahrscheinlich lautet der beste Rat: Im Zweifel ist man mit einem JIRA-Vorgang auf der sicheren Seite und hat eher die Aufmerksamkeit des Bearbeiters. Es ist eine Grundsatzentscheidung, die jedes Team und Unternehmen für sich treffen muss: Brauchen wir für jede (interne) Kleinaufgabe einen eigenen Vorgang? Gilt der Grundsatz No ticket, no task?
Falls nicht, dann sind Aufgabenlisten gut zu handhabende Tools, die in vielen Fällen für die spätere JIRA-Operationalisierung wertvoll sind. In anderen Anwendungsfällen schaffen sie als schlanke To-do-Listen, die man prima abarbeiten kann, ihrerseits zentrale Sichtbarkeit für die Beteiligten. Bei uns leben Ad-hoc-Aufgaben in Confluence ganz gut neben den organisierten JIRA-Projekten, ohne dass es da zu Überschneidungen oder anderen Problemen kommt. Die Herausforderungen im Hinblick auf Verbindlichkeit und Ownership bleiben jedoch bestehen.
Weiterführende Infos
JIRA-Inhalte in Confluence integrieren
Entwicklungsteams, die mit JIRA Software arbeiten, brauchen auch Confluence
Confluence: Die WorkBox als Tool im persönlichen Aufgabenmanagement?
Mehr über die Creative-Commons-Lizenz erfahren
