Product Backlog Management mit Jira und Confluence – Nutzung der Kommentarfunktion

Atlassian Jira und Confluence sind mittlerweile in vielen Firmen Standard, wenn es darum geht, ein Product Backlog für die agile Softwareentwicklung zu verwalten. Da die Tools recht intuitiv zu bedienen sind, wird oft auf eine Schulung der Mitarbeiter oder eine umfangreiche Vorbereitung verzichtet. Für kleine Vorhaben kann das gut funktionieren, aber in Prozessen mit vielen Beteiligten stößt man schnell auf Hindernisse. Zeitraubende Diskussionen und Verwirrung sind die Folge und bremsen den Entwicklungsfortschritt.

Dies ist der erste Artikel einer Blogserie zum Product Backlog Management mit Jira und Confluence. Die Serie beschäftigt sich damit, welche Anti-Patterns im Umgang mit Jira und Confluence oft auftreten und wie sich diese beheben lassen.

Los geht es dem Thema Änderungen von Vorgangsbeschreibungen und die Kommentarfunktion.

Ein Softwareentwickler klagt sein Leid:

Bevor ich anfange eine Story zu bearbeiten, muss ich mir erstmal aus der Beschreibung und allen Kommentaren den aktuellen Stand zusammensuchen. Das heißt, die Beschreibung zu lesen reicht nicht, ich muss alles komplett durchgehen. Und da kommt es dann auch öfter vor, dass in der Beschreibung steht „Das soll so gemacht werden“ und ganz weit unten in einem Kommentar steht „Nee, doch nicht, das soll doch anders“. Und so geht es nicht nur mir, sondern auch der Kollegin, die die Story dann später testen soll. Dabei geht wahnsinnig viel Zeit drauf und es passieren natürlich auch oft Fehler, weil eine Info übersehen wurde.

Na, wer hat sich in diesen Zeilen wiedererkannt? 😉

In vielen Projekten nutzen die Teammitglieder die Kommentarfunktion unter einem Jira-Vorgang wie die Diskussionsfunktionen in den gängigen Social Media Netzwerken. In einem Kommentar wird eine Frage gestellt, im nächsten Kommentar geht jemand darauf ein und schnell geht dieses Ping-Pong-Spiel in eine Richtung, die mit dem ursprünglichen Thema nur noch wenig zu tun hat.

Zum Glück kommt es in einem Jira-System – anders als in den sozialen Netzwerken – eher selten dazu, dass sich Menschen in den Vorgangskommentaren am Ende gegenseitig beschimpfen[1]. Aber durch eine exzessive Verwendung des Kommentarfeatures kann es schnell zu einer fragmentierten Darstellung von Informationen in einem Jira-Vorgang kommen. Kritisch ist dies vor allem dann, wenn Anforderungen sich häufig ändern und Kommentare oder Anhänge mit veraltetem Wissensstand nicht aus dem Vorgang entfernt werden. Der finale Stand der Story ist dann meist schlecht erkennbar und jeder, der mit dem Vorgang arbeitet, muss unnötige Zeit investieren, um herauszufinden, was entwickelt werden soll.

Meiner Erfahrung nach hilft es in diesem Fall, im Team genau abzusprechen, wofür die Kommentarfunktion genutzt wird – und wofür nicht.

Folgende Tipps habe ich dabei für Euch:

1)     Jira-Kommentare nicht als Ersatz für ein direktes Gespräch nutzen.

Zieht ein persönliches Gespräch immer einer Diskussion über Jira vor. Die Verlockung für Letzteres ist zugegebenermaßen groß: Die Story enthält noch ein unklares Akzeptanzkriterium und der Product Owner ist erst morgen wieder im Haus, um weiterzuhelfen? Schnell wird die Rückfrage in einen Jira-Kommentar geschrieben und der Vorgang dem Product Owner zugewiesen. Aus den Augen, aus dem Sinn…

Besser wäre es an dieser Stelle, den Product Owner am nächsten Tag direkt anzusprechen bzw. um eine kurze Videokonferenz zu bitten. Dies ist ganz im Sinne des 6. agilen Prinzips: „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“[2]

Im persönlichen Gespräch lassen sich Rückfragen einfacher klären und es kann Bedarf schnell gemeinsam eine Visualisierung erstellt werden, durch die der Sachverhalt klarer wird.

Um das Product Backlog transparent zu halten und zu zeigen, dass der Vorgang aktuell in Klärung ist, kann er in Jira als Hindernis markiert und mit einem erläuternden Kommentar versehen werden („In Klärung mit dem Product Owner“). Dieser Kommentar sollte nach erfolgter Klärung dann wieder gelöscht werden (siehe auch Punkt 3).

2)     Jira-Kommentare wie Commit-Messages verwenden.

Verwendet Jira-Kommentare nicht für Änderungen oder Erweiterungen der ursprünglichen Story-Beschreibung, sondern versucht, sie analog zu Commit-Messages in git[3] zu verwenden.

Eine gute Commit-Message erklärt vor allem, WARUM etwas im Quellcode geändert wurde und beschreibt dann in der Regel, was genau Gegenstand der Änderung ist.

Für Jira-Vorgänge könnt ihr das analog umsetzen. Ändern sich Informationen in der Vorgangsbeschreibung oder kommen neue Details hinzu, wird diese Änderung oder Erweiterung direkt im Vorgangsfeld „Beschreibung“ vorgenommen. Nicht mehr aktuelle Informationen werden dabei gelöscht oder überschrieben[4]. Durch die Vorgangshistorisierung sind die alten Informationen für interessierte Leser immer noch zugänglich, lenken aber nicht bei der Bearbeitung des Vorgangs ab.

Im Vorgangskommentar könnt ihr analog einer Commit-Message schreiben, warum ihr die Vorgangsbeschreibung geändert habt (z. B. „Akzeptanzkriterium 3 nach Termin mit Stakeholdern aus der Buchhaltung gelöscht“). Das ist natürlich nicht verpflichtend – kann euch aber gerade bei langlaufenden Vorgängen helfen, Änderungen später besser nachzuvollziehen.

3)     Veraltete Kommentare löschen.

Denkt immer an die Menschen, die den Vorgang nach euch bearbeiten oder lesen. Keiner möchte alte Kommentare lesen und rätseln, was zum Teufel der Kommentarschreiber damit gemeint hat.

Daher ist es sinnvoll, nicht mehr benötigte Vorgangskommentare zeitnah zu löschen. Dies gilt beispielsweise für Kommentare wie der in Punkt 1) „In Klärung mit dem Product Owner“. Sobald die Klärung erfolgt ist, kann der Kommentar gelöscht werden.

In der Änderungshistorie ist der Kommentar noch enthalten, so dass sich die ganz Hartgesottenen immer noch alle jemals geschriebenen Kommentare durchlesen können. Alle anderen müssen keine wertvolle mentale Kapazität mehr auf das Verstehen veralteter Kommentare verwenden, sondern können sich aufs Entwickeln oder Testen konzentrieren.

Fazit

Eine bedachte Nutzung der Jira-Kommentarfunktion kann helfen, wertvolle Zeit und Nerven zu sparen. Kommentare sollten nicht für das Führen von Diskussionen verwendet werden, sondern eher wie Commit-Messages in git. Und da sich gerade im agilen Umfeld Informationen oft ändern, ist es wichtig, veraltete Kommentare aus Jira-Vorgängen auch zeitnah zu löschen.

Welche Erfahrungen habt ihr mit Jira-Kommentaren gemacht? Habt ihr noch weitere Tipps und Tricks? Schreibt es mir gerne als Kommentar zu diesem Artikel.

Weitere Tipps, wie ihr Euer Product Backlog Management mit Jira und Confluence verbessern könnt, gibt es im nächsten Artikel dieser Blogserie und in meinem Training „Product Backlog Management mit Jira und Confluence“.

Keine Blogartikel mehr verpassen?

Folgt mir einfach bei Xing, LinkedIn oder Twitter. 🙂

 


[1] Ich hoffe es zumindest. Bitte schreibt mir gerne, falls ihr gegenteilige Erfahrungen gemacht habt…

[2] Quelle: https://agilemanifesto.org/iso/de/principles.html

[3] Ein weit verbreitetes Versionskontrollsystem, in dem Softwarequellcode verwaltet werden kann. Eine Commit-Message ist ein Text, den ein Entwickler jedes Mal schreiben muss, wenn er neuen oder geänderten Quellcode in git speichert.

[4] Hier könnte man ein weiteres Anti-Pattern anführen: Manchmal kommt es vor, dass veralteter Text in Vorgängen als durchgestrichen formatiert wird, anstatt in zu löschen. Auch dies sorgt oft für Verwirrung und unnötigen „visuellen Lärm“.