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/

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! 😉