Job Story

Was ist eine Job Story, wie wird sie formuliert und was sind Unterschiede zur User Story?

Die Situation als Ausgangspunkt für die Job Story

Im agilen Projektmanagement und der Softwareentwicklung sind User Storys ein beliebtes Mittel, um gewünschte Funktionalitäten aus Sicht eines Anwenders zu beschreiben. Der Anwender steht im Mittelpunkt der Aktion. Job Storys wählen einen anderen Weg der Beschreibung; sie stellen die Situation in den Vordergrund, in der ein Anwender etwas tun, um ein gewünschtes Ergebnis zu erzielen. Der Kontext ist bei einer Job Story also besonders wichtig.

Das bekannte User Story Template lautet auf Englisch bzw. Deutsch:

  • As a <role> I want <goal> so that <benefit>.
  • Als <User> möchte ich <Funktionalität>, um <Nutzen> zu erreichen.

Das Job Story Template folgt hingegen folgender Satzschablone (Englisch bzw. Deutsch):

  • When <situation> I want <motivation> so I can <expected outcome>.
  • Wenn <Situation> möchte ich <Motivation>, so dass ich <erwartetes Ergebnis>.

 

Job Story - eine Situationsbeschreibung, in der ein Anwender ein bestimmtes Ergebnis erzielen möchte

Unterschiede zwischen User Story und Job Story

Was sind die Unterschiede zwischen einer User Story und einer Job Story? Oder anders gefragt: wann ergibt der Einsatz von welchem Ansatz Sinn? Um diese Fragen zu beantworten, werfen wir zuerst einen Blick auf die User Story:

  • Bei einer User Story geht es um WER macht WAS und WARUM.
  • WER ist die Rolle, also der Anwender, Kunde, Anforderungsanalytiker, Kinobesucher, Projektleiter etc.
  • Die Rolle steht am Anfang des Satzes und damit wird die Perspektive der Rolle betont. Diese Perspektive schafft die Basis für ein Verständnis bei den Entwicklern. Diese Verständnis ist wichtig, um später Funktionen für das WAS zu implementieren, um das WARUM zu erreichen.
  • Und natürlich dürfen auch die Akzeptanzkritieren nicht fehlen. Sie gelten als Bindeglied zwischen User Storys und Testfällen und werden meist durch das Hinterfragen von Schlüsselwörtern, also Verben, Adjektiven und Substantiven, gewonnen.

Klingt ziemlich einfach, oder? Warum sollte also die Verwendung einer Job Story nützlich sein? Hier gibt es vor allem zwei Gründe:

  1. Bei vielen Entwicklungen werden unzählige User Storys für ein und dieselbe Rolle formuliert. Die Rolle an sich verliert somit an Bedeutung, sie trägt nicht zum Wechsel einer Perspektive bei und sie erhöht nicht das Verständnis der Beteiligten.
  2. Die Situation, in der sich die Story zuträgt, in der die Rolle oder der Akteur tätig wird, um das gewünschte Ergebnis zu erzielen, vermittelt zusätzliche Informationen. Diese Kontextinformationen sind punktuell sehr nützlich für das Verständnis der Beteiligten. Stellen Sie sich bspw. vor, Sie sitzen im Homeoffice und wollen gleich an einer Videokonferenz teilnehmen, aber die Sonne blendet. „Wenn die Sonne blendet und ich an einer Videokonferenz teilnehme, möchte ich, dass sich die Helligkeit des Displays automatisch erhöht, so dass ich sehen kann, was der Präsentator zeigt.“ Die Information, dass die Sonne bei der Durchführung der Videokonferenz blendet, ist somit deutlich wichtiger als die Information, in welcher Rolle ich an der Videokonferenz teilnehme.

Tipps zur Arbeit mit Job Storys und User Storys

Aus diesen Erkenntnissen lassen sich einige Tipps zur Arbeit mit Job Storys und User Storys ableiten:

  • Wer ein Produkt entwickelt, bei dem sich die Bedürfnisse der Anwender in wesentlichen Punkten unterscheiden (und damit die Rollen an Bedeutung gewinnen), sollte wie gehabt User Storys formulieren. Die Betonung liegt auf der Rolle, die eine Aktion ausführt, um einen Nutzen zu erzielen. User Storys sind genau dafür gemacht. Sie erzählen eine kurze Geschichte aus Sicht einer Rolle.
  • Wer aber ein Produkt entwickelt, bei dem sich die Bedürfnisse der Anwender nicht wesentlich unterscheiden, kann Job Storys formulieren. Sie stellen den Kontext in den Vordergrund, in dem ein Anwender etwas tut, um ein erwartetes Ergebnis zu erzielen. Job Storys erzählen eine kurze Geschichte, die in einer konkreten Situation stattfindet.
  • Das Mixen von Job Storys und User Storys zu einer gemeinsamen Story kann durchaus Sinn ergeben: Wenn <Situation> möchte ich als <Rolle> <Funktionalität>, um <Nutzen> zu erreichen. Dies ist naheliegend, insbesondere da es auch alternative User Story Satzschablonen gibt.  

Ein Impuls zum Diskutieren:

Job Storys könnten eine sinnvolle Alternative zu Technical Storys sein.

Hinweise:

Mike Cohn – einer der Gründer der Scrum Alliance und Autor von „Agile Estimation and Planning“ – empfiehlt die gemeinsame Verwaltung von Job und User Storys im Backlog. Alles andere wäre auch merkwürdig, denn dort werden ja bereits Epics, Features, Spike Storys etc. verwaltet. Darüber hinaus gibt Mike Cohn den Hinweis, immer dann Job Storys zu formulieren, wenn man einen Schwung an User Storys schreiben möchte, die alle mit „Als Anwender …“ beginnen. 

Job Storys werden auch im Kontext von Jobs to be done erwähnt. Jobs to be done adressiert die Bedürfnisse, die ein Nutzer mit einem Produkt wirklich erfüllen möchte. Einen Blogbeitrag dazu finden Sie hier.

Weitere interessante Beiträge und Diskussionen finden Sie hier und hier.

Was macht t2informatik?

t2informatik - Wir entwickeln Software für großartige Unternehmen

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

Wissen kompakt: Was ist eine Spike Story?

Was ist eine Spike Story?

Wissen kompakt: Wie funktioniert Planning Poker?

Wie funktioniert Planning Poker?