Starfish at the beach

Bilanz am Jahresende mit dem „kleinen Seestern“

Gefühlt war gerade eben erst Januar und schon nähert sich mit großen Schritten das Jahr 2020 wieder dem Ende. Ein Jahr, das sicherlich nicht wenige von uns als anstrengend, frustrierend und auch von Existenzängsten geprägt wahrgenommen haben. Aber auch ein Jahr, in dem wir alle gemeinsam viel über neue Wege der Zusammenarbeit gelernt haben und dabei Dinge möglich wurden, die wir früher für nicht machbar gehalten haben.

Irgendwie schreit so ein Jahresende ja danach, Bilanz zu ziehen. Im persönlichen Bereich, aber auch beruflich. Um dabei nicht im Jammertal über das herausfordernde 2020 zu versinken, ist es jedoch entscheidend, welchen Blickwinkel wir dabei einnehmen. Genau dazu möchte ich eine kleine Geschichte erzählen, die ich vor ein paar Jahren als Mitglied eines Softwareentwicklungsteams erlebt habe.

Unser Projekt lief damals – wie ja leider viele Softwareprojekte – nicht so richtig rund. Es gab technische Probleme, der Zeitplan passte nicht zu dem gewünschten Anforderungsumfang, Hindernisse ließen sich nicht beseitigen und die Stimmung im Team war schlecht. Eines Nachmittags starteten wir in die x-te Retrospektive am Ende einer Iteration, die wir wie immer mit dem Format „Mad-Glad-Sad“ durchführten.

Das Format ist vielen sicherlich bekannt – falls nicht, ist es schnell erklärt. Der Moderator teilt ein Whiteboard o. ä. in drei Abschnitte, die jeweils eine der Fragen behandeln:

  • „Mad“: Was hat mich während der letzten Iteration wirklich wütend gemacht?
  • „Glad“: Worüber habe ich mich in der letzten Iteration sehr gefreut?
  • „Sad“: Was hat mich in der letzten Iteration traurig gestimmt?

Die Teilnehmer der Retrospektive sammeln dann (üblicherweise auf Post-Its) ihre ganz persönlichen Antworten auf diese drei Fragen (siehe Abbildung 1). Mit den Ergebnissen aus diesem schriftlichen Brainstorming kann dann in darauffolgenden Retrospektiven-Phasen weitergearbeitet werden.

Mad-Glad-Sad Skizze

Abbildung 1: Läuft bei uns. Bergab und rückwärts, aber läuft…

An diesem Nachmittag kam es wie es kommen musste: In der „Glad“-Rubrik herrschte eine ziemliche Leere, dafür türmten sich die Zettel bei „Mad“ und „Sad“.  In der Diskussion der Punkte herrschte die Überzeugung, dass wir eh nichts ändern können und die Energie war am Ende des Termins komplett im Keller. Schlecht gelaunt gingen wir in den Feierabend.

Auf dem Weg nach Hause schwor ich mir: „So eine Jammer-Retrospektive mache ich nicht wieder mit. Entweder wir ändern was oder ich lasse das Meeting das nächste Mal sausen“.

Am Wochenende durchforstete ich den Retromat[1] und las das Buch „Agile Retrospectives“ von Esther Derby und Diana Larsen ein weiteres Mal. Dabei stieß ich auf das Retrospektiven-Format, das ich seitdem am liebsten mag: „Start-Stop-Continue“, manchmal auch „Small Starfish“ genannt.

Bei dieser Methode arbeiten die Teilnehmer mit folgenden drei Kategorien:

  • Start: Womit möchten wir in der nächsten Iteration beginnen, was möchten wir unbedingt ausprobieren?
  • Stop: Was hat in der letzten Iteration nicht gut funktioniert, was war destruktiv, womit möchten wir aufhören?
  • Continue: Was ist gut und kann so bleiben, was sollten wir auf jeden Fall weitermachen?

Wie bei „Mad-Glad-Sad“ sammeln alle dazu auf Post-Its o. ä. die für sie relevanten Punkte. Der Name „Small Starfish“ rührt daher, dass diese Kategorien üblicherweise in Sternform angeordnet werden (siehe Abbildung 2).[2]

Drawing of Small Starfish Retrospective

Abbildung 2: Bestehendes würdigen und Pläne schmieden mit dem kleinen Seestern

Der Kollege, der sich damals um die Moderation der Retrospektiven kümmerte, war leicht zu überzeugen, „Start-Stop-Continue“ in der nächsten Retro auszuprobieren. Zwei Wochen später waren einige Teamkollegen allerdings zuerst irritiert, als ich das neue Vorgehen vorstellte. „Das ist aber schwierig!“ oder „Können wir nicht wieder Mad-Glad-Sad machen?“ waren die ersten Reaktionen.

Als sie sich dann darauf einließen, dauerte das schriftliche Brainstorming zwar zunächst etwas länger als gewöhnlich, aber dann geschah etwas Spannendes: Die Energie im Raum begann sich langsam zu ändern. Wo wir uns früher vor allem mit Negativem beschäftigt hatten, fingen wir plötzlich an, positive Aspekte wertzuschätzen und konkrete Änderungsideen für die Zukunft aufzuschreiben. Wo wir früher vor allem „das Management“ für den schlechten Zustand des Projektes beschuldigt hatten, fingen wir plötzlich an, nach kleinen Dingen zu suchen, die wir in Eigenverantwortung verbessern konnten. Wir konzentrierten uns nicht mehr auf die negativen Themen, an denen wir nichts ändern konnten, sondern auf das, was wir aktiv tun konnten. Gut gelaunt und voller Tatendrang gingen wir alle nach der Retrospektive nach Hause.

Warum aber schreibe ich gerade jetzt diese kleine Geschichte auf? Das Format „Start-Stop-Continue“ ist in der agilen Szene doch seit Jahren bekannt und beliebt. Damit kann man doch niemanden mehr hinter dem Ofen vorlocken. Ich glaube aber, dass die Geschichte trotzdem gerade jetzt wichtig ist, weil uns eine Situationsanalyse mit „Start-Stop-Continue“ auch in der aktuellen Situation enorm weiterhelfen kann.

Es gibt momentan Dinge, die wir vielleicht nicht beeinflussen können. Aber es gibt auch Vieles, das wir gestalten können und wie so oft auch „Gutes im Schlechten“ in der Corona-Pandemie. Ich habe mich zum Beispiel seit Jahren nicht mehr so gesund ernährt und so viel an der frischen Luft bewegt, wie in den letzten Monaten. Das möchte ich auch im nächsten Jahr auf jeden Fall beibehalten. Loslegen möchte ich nächstes Jahr damit, mich um die Gründung einer UG oder GmbH gemeinsam mit meinem Mann Michael Herrmann zu kümmern.

Und wie sieht euer „kleiner Seestern“ für 2020 aus? Was möchtet ihr beibehalten, was aufgeben und womit möchtet ihr nächstes Jahr gerne loslegen? Schreibt es mir gerne in den Kommentaren.

Ich wünsche uns allen eine schöne Weihnachtszeit voller Zuversicht und Dankbarkeit und dass wir trotz der oft großen Unsicherheiten der letzten Monate das Pläneschmieden und Gestalten nicht verlernen!


[1] Eine richtig tolle Website mit vielen Ideen für erfolgreiche Retrospektiven, zu finden unter https://retromat.org/de/?id=107-54-25-72-120.

[2] Es gibt auch noch einen „normal großen“ Seestern, für den ihr im Retromat unter https://retromat.org/de/?id=49 eine Beschreibung findet.

Als Product Owner die richtigen Fragen stellen

Wusstet Ihr, dass Kinder an die 500 Fragen pro Tag stellen?[1] Und dass sie – wenn sie mit dem Sprechen anfangen – zuerst nach dem „Was“ und „Wo“ und mit ungefähr drei Jahren auch nach dem „Warum“ fragen?[2] Deshalb behaupte ich in meinen Trainings manchmal scherzhaft, dass kleine Kinder vermutlich die besten Product Owner oder Requirements Engineers wären. 😉

Denn wenn es darum geht, die Bedürfnisse der Stakeholder an ein Produkt herauszufinden, sind Fragen ein wichtiges Arbeitsinstrument für Product Owner, Business Analysten, Requirements Engineers und überhaupt alle, die sich mit der Analyse von Anforderungen beschäftigen. Aber wie schaffe ich es, in Stakeholder-Interviews wirklich die richtigen Fragen zu stellen?

Da ich nach dem Abitur ursprünglich Journalistin werden wollte und auch eine Zeitlang nebenberuflich bei einer Zeitung gearbeitet habe, beschäftige ich mich schon lange damit, wie man erfolgreiche Interviews führt. Ein guter Anlass für mich, darüber nun einen Blogartikel zu schreiben!

Die innere Haltung ist entscheidend

„Ist das die richtige Frage?“ – damit beschäftigen sich Kinder gar nicht. Sie fragen einfach nach allem, was sie wissen wollen. Ich glaube, da können wir uns als Product Owner oder Requirements Engineers ein bisschen was abgucken. Denn wir können noch so schlaue Fragen stellen, wenn die Grundvoraussetzung für ein gutes Gespräch nicht gegeben ist: Ein ehrliches Interesse am Gegenüber und an dem, was er oder sie zu erzählen hat.

Hilfreich finde ich es, mich selbst als Interviewer in erster Linie als Lernende zu sehen und nicht zu versuchen, die Stakeholder mit vermeintlichem Fachwissen zu beeindrucken. „Ich bin hier, um zu lernen“, ist mein kleines Mantra, das ich mir manchmal im Geiste vorsage, wenn ich mich dabei erwische, wieder in die „Expertenfalle“ zu tappen.

Zu wissen und auch zu zeigen, dass man etwas nicht weißt, ist nicht immer leicht. „Sie sind doch hier die Experten!“ empörte sich vor ein paar Jahren ein Kunde, den ein Kollege und ich im Rahmen eines E-Commerce-Projektes interviewt hatten. Mein Kollege hat damals sehr souverän reagiert und dem Kunden ruhig und freundlich erklärt, dass wir zwar die Experten für E-Commerce-Software sind, jedoch nicht für seine Branche und Produkte. Daher wäre es für uns enorm wichtig, diese Themen mit ihm zu besprechen. Der Kunde hat daraufhin sofort mehr Verständnis für unsere – für ihn möglicherweise teilweise recht sonderbar anmutenden – Fragen gehabt und wir konnten ein konstruktives und informatives Interview führen.

Als Interviewerin muss ich mir außerdem bewusst sein, welche eigenen Annahmen ich mit in das Gespräch bringe. Diese sollte ich explizit machen, um zu überprüfen, ob diese auch der Weltsicht des Stakeholders entsprechen. Wir sind alle geprägt von Systemen, Websites und Apps, die wir gerne nutzen. Wenn ein System neu entwickelt wird, nutzen wir diese Erfahrungen häufig als Referenz, ohne entsprechende Punkte näher zu diskutieren. Blöd nur, wenn man am Ende merkt, dass der Kunde beispielsweise von einem an iOS angelehnten Bedienkonzept ausgegangen ist, während ich mich weitestgehend in der Android-Welt tummle.

Die Sesamstraßenstrategie

Offenheit und die geistige Klarheit über meine eigenen Annahmen sind für mich als Interviewerin also schon mal die halbe Miete. Bei der zweiten Hälfte hilft mir ein Ausflug zurück in meine Kindheit. Nein, damit meine ich nicht, die Stakeholder mit circa 500 „Warum“-Fragen am Tag zu terrorisieren!  Sondern ich meine die Sesamstraße! 😀

„Wer, wie, was, wieso, weshalb, warum“ – wer kennt sie nicht, die Sesamstraßen-Titelmelodie. Und damit hat man eigentlich auch schon die wichtigsten Fragen für die Anforderungsanalyse zusammen[3]. Der Vorteil von diesen W-Fragen ist, dass es sich bei ihnen um offene Fragen handelt. Diese sind bestens geeignet, um den Gesprächspartner ins Erzählen kommen zu lassen und so möglichst viele Informationen abgreifen zu können. Anders als bei der Sesamstraße, sollte am Anfang der Fokus allerdings noch nicht so sehr auf dem „Wie“ liegen, sondern eher auf dem „Warum“ bzw. dem „Wozu“.  Andernfalls besteht die Gefahr, dass man sich frühzeitig in unwichtigen Details oder technischen Lösungsdiskussionen verliert.

Psychoanalyse für Antworten

Falls Euer Frage-Ehrgeiz jetzt geweckt ist, lohnt sich außerdem ein Ausflug in die Welt des systemischen Coachings. Gute Coaches nutzen in ihren Gesprächen Fragetechniken der natürlichsprachlichen Analyse, um in den Antworten der Coachees verborgene Informationen ans Licht zu heben. Man spricht in diesem Zusammenhang von sprachlichen Effekten wie Tilgungen, Generalisierungen und Verzerrungen, die in Gesprächen häufig zu Missverständnissen führen.

In der folgenden Tabelle stelle ich euch einige dieser Sprachmuster vor:

Sprachmuster Beispiel Wie hinterfragen
Passivkonstruktionen „Die Meldung wird verworfen“. „Wer oder welches System macht das?“
Nominalisierungen „Der Kunde schließt seine Anmeldung ab“. „Wer genau ist der Kunde? Was ist mit Anmeldung gemeint?“
Nicht qualifizierte Adjektive oder Adverben „Das System muss einfach zu bedienen sein“. „Was verstehen Sie unter einfach? Haben Sie ein Beispiel für mich?“
Unspezifische Verben „Der Kunde erfasst die Daten.“ „Wie und wann erfasst der Kunde die Daten?“ (und siehe oben: Nominalisierungen)
Universalquantoren „Das System muss alle Datensätze exportieren“. „Wirklich alle Datensätze? Gibt es Ausnahmen?“

Es braucht etwas Übung, aber wenn ihr mit der Zeit feine Antennen für diese Sprachmuster entwickelt habt, hilft euch das dabei, möglichst wenige Informationen zu übersehen. Falls ihr Lust und Zeit habt, sucht euch zum Üben doch einfach mal eine beliebige Nachrichtensendung oder eine Talkshow raus und schaut, welche sprachlichen Effekte ihr dort entdeckt!

Fragenjoker für alle Fälle

Am Ende eines Interviews benutze ich dann gerne eine Fragetechnik, die ich in meiner Ausbildung zum systemischen Coach gelernt habe: Die sogenannte Jokerfrage.

Ich frage meinen Gesprächspartner dann, ob es noch irgendeine Frage gibt, die ich vergessen habe zu stellen. So nehme ich mein Gegenüber mit in die Pflicht, für sich noch einmal das Gespräch zu reflektieren und die Vollständigkeit der ausgetauschten Informationen zu überprüfen. Manchmal kommen hierdurch tatsächlich noch wichtige Punkte ans Tageslicht.

Fazit

Gute Stakeholder-Interviews zu führen ist gar nicht so schwer. Wenn die innere Haltung stimmt und ein gutes Gesprächsklima vorherrscht, braucht es nur noch ein wenig Handwerkzeug und Übung.

Letztendlich solltet ihr es allerdings entspannt angehen. Denn falls ihr aus irgendeinem Grund doch nicht die „richtigen“ Fragen gestellt haben solltet, ist das meiner Meinung nach gar nicht so dramatisch. Erstens könnt ihr die Stakeholder später immer noch mal kontaktieren, sollten euch nach dem Interview noch weitere Fragen einfallen (Besorgt euch während des Interviews schon das Einverständnis des Stakeholders hierzu und seine Kontaktdaten!).

Und zweitens merkt ihr in einem agilen Vorhaben letztendlich bei der Auslieferung des ersten Softwareinkrements an dem Feedback des Stakeholders, ob ihr seine oder ihre Bedürfnisse gut genug verstanden habt. Und könnt so mit jedem Inkrement immer bessere Fragen stellen und bessere Antworten erhalten.

Wie seht ihr das? Welche Tipps und vielleicht sogar „Lieblingsfragen“ habt ihr für Stakeholder-Interviews?


[1] https://www.schweizer-illustrierte.ch/family/alltag/wann-ihr-kinderfragen-besser-nicht-beantwortet

[2] https://www.spiegel.de/familie/warum-kinder-warum-fragen-brauchen-und-wie-eltern-damit-umgehen-sollten-a-992c6e63-6a2d-42c5-8aef-8bb61c62a0f2

[3] Das „Wann“ und „Wozu“ fehlen hier noch.

Beitragsbild: https://pixabay.com/de/photos/universal-studios-singapur-2413365/

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

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.