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/