Product Backlog Management mit Jira und Confluence: Custom Fields vorbelegen

„Was gehört alles in eine User Story?“ fragte eine Teilnehmerin neulich im Training für agiles Requirements Engineering. Diese Frage nehme ich zum Anlass, um im zweiten Teil der Artikelserie zum Product Backlog Management mit Jira und Confluence darüber zu schreiben, wie ihr mit vorbelegten Custom Fields dafür sorgen könnt, beim Erstellen von Vorgängen in Jira nichts Wichtiges zu vergessen.

*** Ein Hinweis vorweg: Um den Jira-spezifischen Teil zu verstehen und umzusetzen, benötigt Ihr Grundkenntnisse in der Administration und Konfiguration von Jira. Oder Ihr schickt diesen Artikel einfach an Eure Jira-Administratorin. 😉 ***

Was gehört denn alles in eine User Story?

Bevor ich Euch zeige, wie ihr das Feld eines Jira-Vorgangs mit Standardwerten vorbelegen könnt, möchte ich die Frage „Was gehört alles in eine User Story?“ zunächst etwas globaler betrachten.

User Stories sind im ursprünglichen Sinne eigentlich „nur“ Platzhalter für ein Gespräch. Das heißt, es geht gar nicht darum, so viel wie möglich besonders gut aufzuschreiben, sondern um einen guten Dialog miteinander. Da manchmal aber doch Gedächtnisstützen hilfreich sind, folgen jetzt ein paar Punkte, die sich in der Arbeit mit User Stories als ausgesprochen hilfreich erwiesen haben:

1.      Die Story selbst

In eine User Story gehört selbstverständlich die Story selbst.  Zugegebenermaßen: Um das zu wissen, muss man wahrscheinlich kein Agile RE Training besuchen. 😉

Für die Formulierung einer User Story hat sich folgendes Template bewährt:


Natürlich müsst ihr Stories nicht nach diesem Template schreiben. Es gibt viele andere Varianten, die sicherlich genauso gut funktionieren. Ich finde dieses Template aber richtig hilfreich, da es drei wichtige Fragen beantwortet:

  • Die Frage danach, wer eigentlich eine Funktion haben möchte[1].
  • Die Frage danach, was der Benutzer braucht.
  • Die Frage danach, warum der Benutzer die Funktionalität braucht.

2.    Die Akzeptanzkriterien

Die Akzeptanzkriterien einer User Story beschreiben, was funktionieren muss, damit eine Story als umgesetzt gilt. Sie bilden damit die Ausgangsbasis für den Softwaretest. Auch hier gibt es viele verschiedene Möglichkeiten der Formulierung, auf die ich an dieser Stelle allerdings nicht detailliert eingehen will (schreibt mir gerne, falls Ihr dazu mehr wissen wollt!).

Für die Arbeit mit Akzeptanzkriterien hat sich in der Praxis bewährt, diese eindeutig durchzunummerieren. So können sich die Entwickler in ihren Commit-Messages eindeutig darauf beziehen.

Bevor eine Story in die Umsetzung geht, solltet Ihr außerdem darauf achten, dass die Liste der Akzeptanzkriterien nicht zu lang ist. Falls es mehr als sieben Akzeptanzkriterien sind, schaut besser, ob Ihr die Story noch weiter schneiden könnt.

3.    Abgrenzung

Gibt es Dinge, die explizit nicht oder in einer anderen Story umgesetzt werden soll? Natürlich kann man hier keine allumfänglich vollständige Liste aufschreiben, aber häufig gibt es Situationen, bei denen sich durch eine klare Abgrenzung („out of scope“) Missverständnisse vermeiden lassen. Beispielsweise, wenn eine E-Mail-Adresse in einem Eingabeformular zwar schon vorhanden ist, aber der Wert noch nicht auf Korrektheit geprüft werden soll.

4.    Definition of Done

Für die Arbeit mit einer User Story ist auch die Definition of Done relevant. Wichtig ist, dass die DoD allen bekannt, aktuell und realistisch ist. Hochgesteckte Ziele, die das Team in der Praxis nicht einhalten kann oder eine Definition of Done, deren Inhalt niemand kennt, helfen keinem weiter!

Typische Inhalte für eine Definition of Done sind zum Beispiel folgende Punkte:

  • Akzeptanzkriterien für die Story wurden erfüllt
  • Unit-Tests sind vorhanden
  • Alle Unit-Tests sind grün
  • Code Review wurde erfolgreich durchgeführt
  • benötigte Dokumentation ist vorhanden bzw. aktualisiert worden
  • Review ist vorbereitet
  • Coding Conventions wurden eingehalten

Um in der Praxis den Überblick zu behalten, welche Punkte der DoD für eine Story schon geprüft wurden, kann es hilfreich sein, in der Story auf die DoD zu verweisen oder diese als kleine Checkliste einzubinden.

5.    Weitere optionale Inhalte

Je nach Komplexität der Story gibt es möglicherweise weitere Details, die für die Umsetzung oder den Review relevant sein können, wie beispielsweise:

  • Geschäftsprozessmodellierungen
  • Wireframes oder Screen-Designs
  • Szenarien
  • Geschäftsregeln
  • Stakeholder, die zum Review der Story eingeladen werden sollen
  • Lösungsideen, die in Frage kommen oder verworfen wurden
  • Anforderungsquellen

Falls umfangreiche Hintergrundinformationen benötigt werden, empfehle ich, diese NICHT direkt in den Jira-Vorgang hineinzuschreiben oder als Datei hochzuladen, sondern in Confluence zu dokumentieren und in Jira dorthin zu verlinken.

Und wie geht das jetzt mit den Custom Fields in Jira?

Die Liste der Punkte, die in eine User Story gehören, ist ja schon ganz schön lang… (und das, obwohl ich mich bemüht habe, mich einigermaßen kurz zu fassen!). Wie gut, dass man in Jira ein Template hinterlegen kann, so dass beim Erstellen einer Story keine wichtigen Punkte vergessen werden.

In dem folgenden Video zeige ich Euch in Jira Cloud, wie das funktioniert. Falls Ihr es eilig habt, folgt hier außerdem eine schriftliche Kurzanleitung:

  1. Zuerst erstellt ihr ein neues Custom Field mit dem Feldtyp „Textfield (multi-line)“ und weist es dem gewünschten Screen zu. In meinem Beispiel nenne ich das Feld „Story Description“.
  2. Dann hinterlegt ihr über den Punkt „Contexts and Default value“ direkt an eurem neuen Feld einen Standardtext für das Feld. Ihr könnt hier Wiki Markup nutzen (siehe Tabelle 1: Möglicher Standardtext für einen Jira-Vorgang).
  3. Über den Menüpunkt Field Configurations wählt ihr den Wiki Renderer für das neue Feld aus.
  4. Und schon ist Euer neues Feld mit Standardtext fertig und kann in einem Vorgang benutzt werden.

*Story*
Als <Rolle> möchte ich <Funktion oder Eigenschaft des Systems>, damit / um < Wert bzw. Ziel >.*Akzeptanzkriterien*
Was muss nach Fertigstellung der Story funktionieren, damit sie abgenommen werden kann?
<Akzeptanzkriterium>
<Akzeptanzkriterium>*Definition of Done*
||Eintrag||Erledigt||
|Akzeptanzkriterien erfüllt|nein|
|Dokumentation aktualisiert|nein|
|Performancetests grün|nein|*Abgrenzung*
Gibt es Dinge, die explizit nicht umgesetzt werden sollen?*Anmerkungen / Details*
Welche weiteren Details sind zum Verständnis der Story wichtig? (z. B. Beispiele für das gewünschte Verhalten, Szenarien, Geschäftsprozesse, Festlegungen, Business Rules)*Lösungsmöglichkeiten / -ansatz*
Welche Möglichkeiten zur Lösung der Story wurden ggf. bereits mit den Stakeholdern diskutiert?
Welche davon sind akzeptabel für die betreffenden Stakeholder, welche nicht?

*Reviewer*
Wer kann fachliches Feedback zu der Story geben und sollte daher im Sprint Review anwesend sein?

Tabelle 1: Möglicher Standardtext für einen Jira-Vorgang

Fazit

In eine User Story können viele verschiedene Dinge gehören. Und Jira Custom Fields, die mit Default Werten vorbelegt sind, können Euch dabei helfen, hier den Überblick zu behalten.

Eigentlich hätte ich die Frage „Was gehört alles in eine User Story?“ im Sinne echter Agilität aber auch ganz anders beantworten können: In eine User Story gehört alles rein, was IHR in Eurem Team braucht!

Schließlich sollen Individuen und Interaktionen im Vordergrund stehen und nicht Prozesse und Tools. Deshalb: Redet miteinander! Und findet gemeinsam heraus, was Euch bei der Arbeit mit User Stories weiterhilft. Vielleicht ist es ein Standardtext für ein Jira-Feld, vielleicht reicht eine einfache Checkliste, vielleicht ist es aber auch etwas ganz anderes.

Falls Ihr dabei Hilfe braucht, schreibt mir gerne oder schaut mal in meine Trainingsangebote.

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

[1] Wichtig ist, dass es sich wirklich um eine Benutzerrolle handelt und ihr nicht schreibt „Als Product Owner (…)“ oder (noch schlimmer) „Als Datenbank (…)“ oder so etwas.

Beitragsbild: https://www.pexels.com/de-de/foto/rot-loffel-schreibtisch-trocken-4199098/

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