Qualitätsanforderungen in (Online-)Workshops erheben

Qualität liegt im Auge des Betrachters

„Lasst uns doch endlich mal wieder mit der Clique richtig schön essen gehen!“ schlägt ein Freund vor. Gute Idee, aber was genau bedeutet für uns eigentlich „schön essen gehen“?

Der eine Freund möchte zum Brasilianer, weil dort die Steaks besonders groß und saftig ist. Jemand anders macht gerade eine Diät und möchte lieber zum Asiaten, weil es dort leichte Gerichte mit viel Gemüse gibt. Und die dritte Person möchte gerne zu dem kleinen Italiener ums Eck, weil es dort den besten Grappa der Stadt gibt.

Es bewahrheitet sich also mal wieder das alte Sprichwort „Schönheit liegt im Auge des Betrachters“.[1] Und so ist es nicht nur beim Essen, sondern auch bei Software. Damit die angepeilten Ziele mit einer Software erreicht werden können, ist auf der einen Seite eine bestimmte Funktionalität wichtig. Aber Softwarefunktionen sind nur die eine Seite der Medaille – die andere Seite sind die qualitativen Eigenschaften, wie zum Beispiel Benutzbarkeit, Sicherheit und Wartbarkeit. Fehlen diese ganz oder teilweise, führt dies in der Regel zu großer Unzufriedenheit bei Nutzern der Software und anderen Stakeholdern (siehe Abbildung 1: Unzufriedene Stakeholder).

Abbildung 1: Unzufriedene Stakeholder

Deshalb müssen wir in der Anforderungsanalyse mit Stakeholdern auch über die gewünschten Qualitätsanforderungen an eine Software sprechen. Oft fokussieren wir jedoch auf die benötigten Funktionen und verlieren diesen wichtigen Aspekt aus den Augen. Damit das nicht passiert, möchte ich hier ein praxiserprobtes Workshopvorgehen vorstellen, mit dem es gelingt, auch Stakeholder ohne technischen Hintergrund von Anfang an in die Definition von Qualitätsanforderungen einzubeziehen.

Workshopplanung

Für einen Workshop zur Ermittlung von Qualitätsanforderungen ist eine gute Teilnehmermischung wichtig, weil wir nur so unterschiedliche und vielleicht auch widersprüchliche Anforderungen sammeln können. Die Teilnehmer sollten verschiedene fachliche Hintergründe und Rollen im Projekt haben, um so vielfältige Blickwinkel abdecken zu können.

Die richtigen Teilnehmer auszuwählen, kann eine Herausforderung sein, da der Teilnehmerkreis gleichzeitig nicht zu groß werden sollte. Maximal zehn Teilnehmer sind meiner Erfahrung nach eine gute Größe. Falls der potenzielle Teilnehmerkreis größer ist, kann ich Euch die Liberating Structures ans Herz legen. Diese Moderationsmethoden sorgen auch in großen Gruppen dafür, dass sich alle gut einbringen können.

Für einen ersten „Aufschlag“ zum Thema Qualitätsanforderungen kann ein vierständiger Workshop ein guter Start sein. Falls Ihr den Workshop online durchführt, würde ich tendenziell ein noch kürzeres Zeitfenster von 2-3 Stunden einplanen und dafür mehr Zeit in die Vorbereitung investieren.

Die ISO-Norm 25010 für Softwarequalität

Um bei dem umfangreichen Thema Qualitätsanforderungen nicht den Überblick zu verlieren, verwende ich in Workshops das Qualitätsmodell für Produktqualität aus der internationalen Norm ISO 25010 für die System- und Softwareentwicklung. Die Norm definiert acht Qualitätsmerkmale, welche jeweils in weitere Untermerkmale unterteilt sind (siehe Abbildung 1: Qualitätsmerkmale nach ISO 25010). Abhängig von der Workshopdauer und meinem Vorwissen über das Projekt, verwende ich im Workshop entweder das komplette Modell oder relevante Teilausschnitte davon.

Abbildung 2: Qualitätsmerkmale nach ISO 25010

 

Manche Qualitätsmerkmale sind selbsterklärend, bei anderen brauchen die Workshopteilnehmer für die Arbeit mit dem Modell ein paar erläuternde Worte. Für eine Reihe von Präsenzworkshops habe ich für einen Kunden zu diesem Zweck vor einiger Zeit ein kleines Handout angefertigt, welches Ihr hier herunterladen könnt.

Für Online-Workshops bereite ich ein Online-Whiteboard (z. B. mit Miro oder Conceptboard) vor, welches eine Mindmap mit den relevanten Qualitätsmerkmale aus der ISO 25010 mit einer kurzen Erklärung enthält (Siehe Abbildung 3 für einen Auszug der entsprechenden Mindmap). Diese baumartige Strukturierung der Qualitätsmerkmale wird in der Fachliteratur auch oft als „Utility Tree“ oder „Qualitätsbaum“ bezeichnet. Damit später genug Platz auf dem Whiteboard ist, um die einzelnen Qualitätsmerkmale zu bearbeiten, lasse ich möglichst viel Freiraum rund um die einzelnen Mindmap-Elemente.

Qualitätsanforderungen mit Qualitätsszenarien konkretisieren

Nachdem ich das Qualitätsmodell und den Qualitätsbaum kurz erklärt habe, geht es im Workshop an die Analyse der Qualitätsanforderungen. Hierzu eignet sich die sogenannten Qualitätsszenarien – eine Technik, die oft auch zur Bewertung von Softarchitekturen verwendet wird.

Qualitätsszenarien beschreiben die Verwendung des Systems mit Fokus auf jeweils ein Qualitätsmerkmal und dienen dazu, die am Anfang oft schwammigen Qualitätsanforderungen zu konkretisieren.

Ganz allgemein lassen sich drei Arten von Szenarien unterscheiden:

Szenarioart Beschreibung Beispiel
Verwendungsszenario Beschreibt die normale tägliche Nutzung des Systems. Ein Webseiten-Benutzer führt eine Volltextsuche durch. Die Suchergebnisse werden in unter 5 Sekunden angezeigt. (Qualitätsmerkmal: Leistungseffizienz)
Änderungsszenario Beschreibt was passiert, wenn Dinge im System geändert werden (z. B. neue Funktionen, größere Nutzeranzahl etc.). Ein Webseiten-Manager möchte eine neue Sprache hinzufügen. Er kann dies ohne die Unterstützung eines Softwareentwicklers tun.
Fehlerszenario Beschreibt, wie das System auf Fehler oder unvorhergesehene Ereignisse (z.B. Netzwerk- oder Hardwareausfälle) reagiert. Ein Webseiten-Benutzer hat versehentlich eine Seite gelöscht. Ein Webseiten-Administrator kann die gelöschte Seite innerhalb kurzer Zeit wiederherstellen.
Tabelle 1: Arten von Qualitätsszenarien

Typischerweise enthält ein Qualitätsszenario immer eine Quelle (z. B. ein Webseiten-Benutzer, ein Webseiten-Manger), eine Interaktion mit dem System (z. B. eine neue Sprache hinzufügen) und ein Antwortmaß (z. B. „unter 5 Sekunden“, „ohne die Unterstützung eines Softwareentwicklers“). Hierdurch werden Qualitätsanforderungen greifbar und zumindest theoretisch überprüfbar.

Wenn ich einen Workshop vorbereite, bereite ich für jede Unterkategorie der relevanten Qualitätsmerkmale ein konkretes Beispielszenario vor. So fällt es den Teilnehmern leichter, später selbst Qualitätsszenarien zu formulieren.

Falls ich die Anforderungen an das System schon etwas besser kenne, verwende ich als Beispiele realistische Szenarien, die im Idealfall von den Stakeholdern direkt bestätigt werden können. Falls ich die Anforderungen noch nicht kenne, verwende ich fiktive Szenarien aus einem anderen Bereich (wie zum Beispiel die Szenarien in Tabelle 1: Arten von Qualitätsszenarien ).

Je nach Teilnehmeranzahl geht es nun entweder mit der gesamten Gruppe oder in Kleingruppen weiter und die Teilnehmer sammeln auf physikalischen oder virtuellen Post-Its Qualitätsszenarien zu den einzelnen Unterkategorien der ISO25010.

Abbildung 3: Sammeln von Qualitätsszenarien auf einem Miro-Bord

Priorisierung von Qualitätsmerkmalen

In kurzer Zeit kann so eine große Anzahl von Qualitätsszenarien zusammenkommen. Hierbei wird meist schnell deutlich, dass die Stakeholder einen unterschiedlichen Fokus darauf haben, welche Qualitätsmerkmale aus ihrer Sicht besonders wichtig sind. Der IT-Architekt achtet vielleicht vor allem auf Sicherheit und Wartbarkeit, während den Key-Usern die Benutzbarkeit am wichtigsten ist.

Wie schön wäre es, wenn wir ein System bauen könnten, dass die Qualitätswünsche aller Stakeholder vollkommen befriedigt! Leider ist dies in der Praxis jedoch meistens nicht möglich. Zum einen, weil dieses System unglaublich teuer zu realisieren wäre, zum anderen, weil es oft Konflikte zwischen Qualitätsmerkmalen gibt. Ein sehr sicheres System ist beispielsweise oft schlechter nutzbar und sehr performanter Quellcode kann schwierig wartbar sein. In der Architekturbewertungsmethode ATAM spricht man in diesem Zusammenhang auch von den sogenannten Tradeoffs zwischen Qualitätsmerkmalen.

Um abwägen zu können, welche Tradeoffs man am ehesten eingehen kann, ordnen die Workshopteilnehmer jedem Qualitätsszenario eine Priorität (High, medium oder low) zu. Für einen Online-Workshop mit Miro eignen sich hierzu die Labels, welche frei definiert und an Post-its geknüpft werden können.

Ich bitte zunächst alle Teilnehmer, die Prioritäten allein (sozusagen in „Stillarbeit“) zu vergeben. Wie in Abbildung 4 zu sehen, kommt es dabei normalerweise mehr oder weniger häufig vor, dass Teilnehmer dasselbe Qualitätsszenario unterschiedlich bewerten (z. B. ein Teil der Teilnehmer bewertet die Priorität als „High“, ein andere Teil als „Low“). Die Szenarien mit unterschiedlicher Bewertung werden im nächsten Schritt ähnlich wie beim Planning Poker diskutiert und am Ende einigen sich hoffentlich alle Teilnehmer auf eine gemeinsame Priorität. Hierbei entsteht in der Regel ein sehr guter Austausch zwischen den Stakeholdern, die offen darüber reden, was ihnen am System am wichtigsten ist.

Abbildung 4: Priorisierung von Qualitätsszenarien

Einen kleinen Spaßfaktor bieten in Miro die Emoticons, welche man auf einen Post-It setzen kann. Ich habe in einem Workshop mal die Teilnehmer gebeten, das wütende Emoticon zu nutzen, falls sie mit einem Szenario gar nicht einverstanden sind. Genauso können Teilnehmer einem für sie besonders wichtigen Szenario den Daumen nach oben oder ein anderes positives Emoticon geben.

Fazit

Das Erheben und Analysieren von Qualitätsanforderungen ist kein Hexenwerk und funktioniert mit Qualitätsszenarien und einem guten Online-Whiteboard auch remote sehr gut. Mindestens genauso wichtig wie die Szenariosammlung am Ende des Workshops ist aus meiner Erfahrung jedoch auch der Austausch zwischen den Stakeholdern. Oft ist der Workshop der ersten Anlass, endlich einmal explizit über die eigenen Qualitätserwartungen an die Software zu sprechen.

Die erarbeiteten Qualitätsanforderungen fließen im Nachgang als eigene Stories, Akzeptanzkriterien oder über die Definition of Done in den Entwicklungsprozess ein.

Welche Erfahrungen habt Ihr mit Qualitätsanforderungen gemacht? Habt ihr das Thema Qualitätsanforderungen auf dem Schirm und falls ja, wie erarbeitet Ihr sie mit den Stakeholdern? Schreibt es mir gerne in die Kommentare zu diesem Blogbeitrag.

Und falls Ihr Unterstützung bei der Vorbereitung und / oder Durchführung eines Qualitätsanforderungsworkshops benötigt (Präsenz oder remote), schreibt mir gerne:

 


[1] Manche behaupten auch, Schönheit sei eine Sache der Beleuchtung – aber diesem Thema wollen wir an dieser Stelle besser nicht weiter nachgehen. 😉

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.

Modafinil rezeptfrei wird als wachheitsförderndes Medikament eingestuft. Wie der Name schon sagt, ist das Ziel, die Wachsamkeit oder Aufmerksamkeit zu fördern, um die Auswirkungen der Schlafattacken und der Tagesmüdigkeit zu verringern.

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