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“.

Mein Vortrag über „Spiral Dynamics“ bei der REConf 2019

Jeder Requirements Engineer, der schon in verschiedenen Unternehmen, Projektkontexten oder mit verschiedenen Stakeholdergruppen zusammengearbeitet hat, kennt sicherlich folgende Probleme:

  • Während dieselbe Strategie zur Analyse von Anforderungen bei einer Gruppe von Stakeholdern total gut funktioniert, führt sie bei einer anderen Gruppe zu keinen brauchbaren Ergebnissen.
  • Während in dem einen Projekt das Requirements Engineering Toolset begeistert genutzt wird, findet es in einem anderen Projekt keinerlei Anklang.
  • Während es in dem einem Unternehmen möglich ist, offen über den Tausch von Features, Kompromisse und Alternativenbildung zu sprechen, ist man in dem anderen Unternehmen unter keinen Umständen bereit, Abstriche im Hinblick auf den geplanten Funktionsumfang einer Software zu machen.
  • … und so weiter…

Das Modell Spiral Dynamics, welches ich in meinen Vortrag “Und welche Farbe haben Sie?” – Requirements Engineering Methoden anhand des Spiral Dynamics Modells auswählen“ auf der diesjährigen REConf in München vorgestellt habe, liefert Ansatzpunkte zur Erklärung, warum es diese Unterschiede gibt. Das Modell wurde ursprünglich von dem amerikanischen Psychologen Clare W. Graves entwickelt und beschreibt die Entwicklung von Wertesystemen. Jedem Wertesystem wird dabei eine Farbe zugeordnet (Daher auch der Titel meines Vortrags!).

Je nachdem, welches Wertesystem eine Organisation oder einen Mensch in einem bestimmten Kontext dominiert, wird sich auch seine Herangehensweise an das Thema Softwareanforderungen unterscheiden. Requirements Engineers sollten dabei nicht verzweifeln, weil Stakeholder mit bestimmten Methoden (noch) nicht zurechtzukommen oder sie falsch zu verstehen und einzusetzen zu scheinen, sondern anerkennen, dass sie aktuell in anderen Wertesystem unterwegs sind. Für bestimmte Kontexte sind dabei bestimmte Wertesysteme angemessener als andere. So ist es für ein Luftfahrtunternehmen sicherlich passend, wenn das blaue Wertesystem mit den Kernwerten Sicherheit und Ordnung vorherrscht. Eine Airline mit einem roten Wertesystem, in dem Impulsivität und Kampfgeist wichtige Werte sind, nimmt es mit der Sicherheit vielleicht nicht so genau…

Die Vortragsfolien stehen hier zum Download bereit. Außerdem habe ich noch einen One Pager mit einer Übersicht über den Vortrag erstellt.

Über Feedback freue ich mich.

Cheat Sheet Anforderungsdokumentation

Beim klassischen Dokumentieren von Anforderungen muss man ganz schön viel beachten. Zum Glück gibt es zu diesem Thema hinreichend Literatur auf dem Markt. So zum Beispiel das praktische Büchlein „Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level“ von Klaus Pohl und Chris Rupp, dessen Inhalt wie der Titel schon sagt die Basis zur CPRE-Zertifizierung Foundation Level bildet.

RE-Cheat-Sheet

Für alle, die dieses Buch jedoch nicht immer dabei haben und einfach auf einer Seite die wichtigsten Regeln für das Schreiben von Anforderungen zusammengefasst haben wollen, habe ich vor ein paar Jahren auf Basis des oben genannten Buches einen kleinen Spickzettel (auch bekannt als „Cheat Sheet“) erstellt.

 

Der folgende Link führt direkt zum Cheat Sheet: RE-Cheat-Sheet

In dem Sinne: Happy Cheating! 😉