Job Stories

Ziel

Eine Job Story beschreibt ein Element des Produkt-Backlogs als Arbeit, die ein Stakeholder in einem bestimmten Moment erledigen will. Der Satz benennt die Situation, die das Bedürfnis auslöst, das, was die Person in diesem Augenblick erreichen will, und das Ergebnis, das sie davon erwartet. Der Ausdruck job to be done, die Aufgabe, die jemand zum Abschluss bringen will, stammt aus der Nachfragetheorie von Clayton Christensen: Ein Produkt wird "angeheuert", um eine Arbeit zu erledigen, und diese Arbeit erklärt den Kauf besser als das Profil des Käufers.

Das Format behebt einen Entwurfsfehler: Eine Anforderung, die einer Rolle zugeschrieben ist, sagt, wer handelt, ohne zu sagen, warum. Zwei Personen, die demografisch nichts verbindet, treffen auf denselben Auslöser und wollen dasselbe; dieselbe Person trifft je nach Tag in unterschiedlichen Rollen auf diesen Auslöser. Klement formulierte das Argument 2013 gegen die Persona, jenes typisierte Porträt eines Nutzers aus demografischen und verhaltensbezogenen Merkmalen: eine erfundene Kundschaft, deren Merkmale keine Ursache erklären. Die Situation trägt den Kontext des Moments, das Material, mit dem das Delivery-Team entwirft.

Das Arbeitsergebnis ist der Satz selbst, der auf dem Backlog liegt und wie jedes andere Element verfeinert wird.

Einsatz

Wann einsetzen

• Bedürfnis, das ein bestimmter Moment auslöst: Was die Handlung hervorruft, wiegt schwerer als die Identität der handelnden Person.
• Situation, die mehrere Rollen teilen: Ein einziger Auslöser trägt unterschiedliche Motivationen.
• Gestaltung der Benutzererfahrung: Die Situation liefert die Einschränkungen des Moments.
• Backlog, das zur Lösung abdriftet: Das Format zwingt dazu, das Bedürfnis vor jeder Funktion zu formulieren.
• Denken in Ursache und Wirkung: einen Auslöser mit einem erwarteten Ergebnis verbinden und danach prüfen, ob das Ergebnis eingetreten ist.
• Verfeinerung im Delivery-Team: Das Format wird an Elementen geübt, die bereits im Backlog stehen.

Wann nicht einsetzen

• Berechtigungen sind zu spezifizieren: Der Satz verschweigt die Rolle und damit die Zugriffsrechte; hier greift die Rollen- und Berechtigungsmatrix.
• Verhalten mit vielen Alternativpfaden: Drei Segmente tragen weder Abläufe noch Ausnahmen; hier greifen die Anwendungsfälle.

Beschreibung

Die Form des Satzes

Eine Job Story wird in der ersten oder in der dritten Person geschrieben. Die erste lässt den Stakeholder sprechen: "wenn Situation, möchte ich Motivation, damit erwartetes Ergebnis". Sie liest sich von links nach rechts als Ursachenkette: ein Auslöser, ein Bedürfnis, das er weckt, und ein Zustand, den die Person erreichen will.

Die drei Elemente

Die Situation gibt den Kontext des Moments, in dem die Arbeit zu erledigen ist. Sie benennt einen Auslöser und dessen Umfeld: was gerade geschehen ist, was drängt, was unbekannt ist, wo sich die Person befindet. Je reicher der Kontext, desto besser entwirft das Team.

Die Motivation benennt, was der Stakeholder erreichen will. Sie lässt innere Kräfte zu, Sorge, Eile, Gewohnheit, ebenso äussere, eine Frist, eine Rechnung, ein wartendes Gegenüber. Die Funktion hält das Format daraus fern: "Ich möchte einen Knopf auf dem Startbildschirm" schliesst den Entwurf, und das Team erbt eine Lösung.

Das erwartete Ergebnis sagt, was die Motivation befriedigt oder was sie beruhigt. Es wird als Zustand formuliert, den die Person erreicht, was es beobachtbar macht, sobald die Lösung ausgeliefert ist.

Eine Situation, mehrere Akteure

Derselbe Auslöser bringt bisweilen mehrere Personen mit unterschiedlichen Bedürfnissen in Bewegung. Ihre Rollen treten dann in das Segment "wenn" ein und der Satz wechselt in die dritte Person: "wenn jemand Situation, möchte Akteur Motivation, damit erwartete Ergebnisse". Die Situation bleibt einzig, die Motivationen vervielfachen sich, eine je Akteur, bevor sie auf ein gemeinsames Ergebnis zulaufen. In der User Story zwingt eine Rolle je Karte dazu, so viele Karten zu schreiben, wie es Rollen gibt, und lässt die Verbindung zwischen ihnen offen.

Eine Job Story schreiben

1. Die Situation im Feld erheben
   Der Auslöser ist ein empirisches Datum. Er stammt aus einem Interview, aus einer Beobachtung am Arbeitsplatz, aus einem Support-Ticket oder aus einer Nutzungsaufzeichnung. Eine vom Schreibtisch aus geschriebene Situation ist eine Annahme im Gewand einer Tatsache.
2. Den Kontext mit den Worten der beobachteten Person schreiben
   Projektvokabular glättet das, was die Einschränkung ausmacht: "Das System ist langsam" hat "Ich habe drei Patienten, die am Empfang warten" ersetzt.
3. Von der Funktion zurück zum Bedürfnis gehen
   Wenn die befragte Person einen Bildschirm, einen Knopf oder einen Bericht verlangt, fragt man, wozu er dienen soll, und schreibt die Antwort auf. Die Motivation ist das, was übrig bleibt, wenn kein Element der Oberfläche mehr genannt wird.
4. Das erwartete Ergebnis und die Grösse benennen, die es belegt
   Ein Ergebnis, das sich nicht beobachten lässt, wird nie geprüft: Man benennt zugleich, wo die Wirkung ablesbar wird, in einer Zählung, in einem Nutzungsprotokoll oder im Anrufvolumen.
5. Den Satz von je einer Person aus jeder betroffenen Rolle gegenlesen lassen
   Dort bestätigt sich ein geteilter Auslöser: Jede Rolle erkennt den Moment wieder und korrigiert ihre eigene Motivation. Der Satz wechselt dann in die dritte Person.
6. Den Satz ins Backlog stellen und zerlegen
   Eine Job Story zerfällt in kleinere Job Stories, die je für sich den Weg über Verfeinerung und Priorisierung nehmen.
7. Akzeptanzkriterien vor der Schätzung anhängen
   Das Format liefert keine, also wählt das Team die Form: ausführbare Beispiele, eine Liste von Bedingungen oder klassische Akzeptanzkriterien. Diese Wahl wird einmal für das ganze Backlog entschieden.

Job Story oder User Story

Beide Formate belegen denselben Platz auf einem Backlog und unterscheiden sich in einem einzigen Segment, dem ersten. Die folgenden Segmente behalten dieselbe Funktion.

Die Situation ist das richtige erste Segment, wenn der Moment des Auslösers bestimmt, was gebaut wird: Interaktionsgestaltung, ein von mehreren Profilen geteilter Ablauf, die Frage nach dem "Warum jetzt". Die Rolle wird es wieder, sobald eine Abgrenzung der Zugriffsrechte zu dokumentieren oder eine Prüfung diszipliniert zu führen ist. Dann kommt die User Story mit INVEST.

Die Agile Extension sieht vor, dass beide nebeneinander bestehen: Die Job Story trägt Motivation und erwartetes Ergebnis, die User Story trägt die mögliche Funktion. Der Leitfaden benennt das Risiko dabei, ein Team, das sich beim Wechsel zwischen den Formaten verirrt. In der Praxis behält man ein Format einer Phase vor, etwa der Entdeckung, statt beide in einer einzigen Warteschlange zu mischen.

Was eine Job Story scheitern lässt

Die Persona zurück in der Situation

"Wenn ich Systemadministrator bin" setzt eine Rolle in das Segment der Situation. Dort zu schreiben, wer die Person ist, holt jene Verzerrung durch die Persona zurück, die das Format beiseitelässt.

Die Lösung in der Motivation

"Ich möchte einen CSV-Export" sieht aus wie eine Motivation und der Satz bleibt wohlgeformt; es ist eine Bestellung einer Funktion, die nichts mehr zu entwerfen übrig lässt.

Der Satz, der aufquillt

Das Format ist wortreicher als die User Story, da es Kontext, Akteure und Ergebnisse trägt. Ab drei Zeilen ist die Job Story im Verfeinerungstermin nicht mehr lesbar. Den Kontext hält man auf das, was eine Entwurfsentscheidung ändert.

Das erwartete Ergebnis, das die Motivation wiederholt

"Ich möchte meinen Saldo kennen, damit ich meinen Saldo kenne" ist ein verlorenes Segment. Das erwartete Ergebnis liegt jenseits der Anwendung, in dem, was die Person dank ihr entscheidet oder vermeidet.

Die Zerlegung ohne Folge

Eine Job Story von guter Grösse zerfällt in fünf oder sechs kleinere Sätze. Jeder kommt mit zu setzender Priorität und zu führender Verfeinerung ins Backlog; ohne diese Führung verlängert die Zerlegung die Warteschlange und klärt nichts.

Nie geschriebene Akzeptanzkriterien

Das Format verlangt keine. Ein Team, das es unbedacht übernimmt, steht am Ende mit Sätzen voller Absicht da, von denen niemand sagen kann, ob sie erfüllt sind.

KI-Überlegungen

Ein Modell leistet bei diesem Format drei Dienste. Es konvertiert einen Bestand: Ein Stapel User Stories, Support-Tickets oder Interviewzitate wird zu einer Liste von Kandidaten für die drei Segmente, die das Team anschliessend korrigiert. Es prüft mechanisch, was das Format ungeprüft lässt: die in das Segment Motivation geschobene Funktion, die als Situation verkleidete Rolle, das erwartete Ergebnis, das die Motivation wiederholt. Das sind Formfehler. Es variiert die Situationen: Aus einem beobachteten Auslöser schlägt es Varianten desselben Moments unter anderen Bedingungen vor, nachts, ohne Verbindung, unterwegs, die das Team behält oder verwirft.

Die Grenzen liegen im Material des ersten Segments. Die Situation ist eine Beobachtung aus dem Feld: Ein Modell erzeugt plausible Auslöser, die niemand erlebt hat, und eine Job Story auf einem erfundenen Moment stellt die Verzerrung durch die Persona wieder her. Die Sorgen und Reibungen, die die Motivation tragen soll, stammen von realen Kundinnen und Kunden, gehört oder beobachtet; erzeugt beschreiben sie nur die Regelmässigkeiten des Trainingsbestands. Die Priorisierung bleibt eine Geschäftsentscheidung, getragen von Wert und Häufigkeit dieser Organisation. Schliesslich tragen Support-Tickets und Interviewzitate Personendaten im Sinne des DSG, oft Gesundheits- oder Finanzdaten, und gehen ohne Rechtsgrundlage oder Anonymisierung nicht in einen öffentlichen Dienst.

Beispiele

Eine Krankenkasse erwägt, ihrer App die Übersicht der verbrauchten Franchise hinzuzufügen. Gespräche in den Agenturen bringen einen immer gleichen Moment zutage: Der Arzt schlägt eine Behandlung vor, die warten kann, und die versicherte Person weiss nicht, wo ihre Jahresfranchise steht. Das Bedürfnis lässt sich dann in einem Satz schreiben.

"Wenn mein Arzt mir im November eine nicht dringende Behandlung vorschlägt und ich nicht weiss, wo meine Jahresfranchise steht, möchte ich den bereits verbrauchten Anteil sehen und das, was bei einem Beginn jetzt zu meinen Lasten geht, damit ich entscheiden kann, ob ich den Termin noch dieses Jahr oder im Januar vereinbare."

Die Situation reicht bis "Jahresfranchise" und trägt alles, was die Entscheidung möglich macht. Die Motivation liegt in den beiden Beträgen, welche die versicherte Person sucht, ohne den Bildschirm zu nennen, der sie ihr zeigen wird. Das erwartete Ergebnis ist der Termin, den sie setzen wird.

Eine dreissigjährige versicherte Person und eine Rentnerin erleben diese Situation gleich, sodass der zu entwerfende Bildschirm für beide derselbe ist. Eine User Story hätte eine Rolle wählen müssen, eine Unterscheidung ohne Wirkung auf den Entwurf.

Nach KVG wird die Franchise am 1. Januar auf null gesetzt: Wer sie bereits erreicht hat, zahlt bis zum 31. Dezember nur noch den Selbstbehalt, und wer die Behandlung aufschiebt, beginnt wieder bei einer vollen Franchise. Eine lesbare Übersicht des Saldos bündelt die nicht dringenden Behandlungen dieser Versicherten daher in den letzten Wochen des Jahres, eine Wirkung, welche die Kasse in ihren Abrechnungen abliest. Die Motivation selbst hält beim Bedürfnis inne und lässt mehrere Lösungen offen: eine Benachrichtigung im November, ein Rechner zur Kostenbeteiligung, ein Hinweis in der Quartalsabrechnung.

Visualisierungen

Der Fall mit mehreren Akteuren ist eine Verzweigung, eine Situation hin zu mehreren Motivationen und dann zu einem gemeinsamen Ergebnis, eine Form, die keine Aufzählung wiedergibt. Der Vergleich mit der User Story ist ein Tausch der Position, den man zeichnet, indem man beide Sätze Segment für Segment übereinanderlegt. Die Technik erzeugt schliesslich einen gegliederten Satz, beschriftete Blöcke: Die Karte der Job Story zeigt die drei Segmente und was jedes von ihnen trägt. Die inhaltlichen Unterschiede zwischen den beiden Formaten bestehen aus Zeilen und Spalten und gehören in eine Tabelle.

Aufwand

Werkzeuge

Die Job Story ist eine Schreibkonvention, also ist das Werkzeug der Träger, auf dem der Satz lebt. Das Whiteboard und Haftnotizen genügen im Workshop, mit einer einmal gezogenen Vorlage aus drei Bändern: Der visuelle Zwang der drei Segmente lässt das nachlässig gefüllte Segment hervortreten. Kollaborative Online-Whiteboards (Miro, Mural, FigJam) übernehmen dieselbe Rolle für ein verteiltes Team und halten die Varianten einer Situation nebeneinander fest.

Die Werkzeuge zur Backlog-Verwaltung (Jira, Azure DevOps, GitLab) nehmen den Satz auf, sobald er priorisiert, geschätzt und mit dem verbunden werden muss, was ihn erfüllt. Zwei Einstellungen genügen dafür: eine Ticketvorlage, welche die drei Segmente als eigene Felder verlangt statt als einen Block freien Textes, sowie eine Beschriftung, welche Job Stories von User Stories unterscheidet, wenn beide Formate nebeneinander bestehen. Die Segmente werden damit filterbar, was erlaubt, alle Backlog-Elemente zu derselben Situation wiederzufinden.

Die Werkzeuge der Nutzerforschung und die Support-Plattformen (Dovetail, Zendesk) sind die vorgelagerte Quelle der Situationen, da sie die Zitate bewahren, in denen die Auslöser auftauchen. Kein Werkzeug ist erforderlich: Drei mit dem Filzstift auf einen Papierstreifen geschriebene Segmente sind eine vollständige Instanz der Technik.

Quellen

• IIBA, Agile Extension to the BABOK Guide, §7.4 Job Stories: die Definition, die erste und die dritte Person, die drei Elemente (Situation, Motivation, erwartetes Ergebnis), die Stärken des Formats und seine Grenzen, darunter die Wortfülle, die zu führende Zerlegung und die Verwechslung der Formate auf einem Backlog.
• Alan Klement, Replacing The User Story With The Job Story, 2013: der Ursprung des Begriffs und des Satzes aus drei Segmenten, mit dem Argument gegen die Persona.
• Paul Adams, Designing Features Using Job Stories, Intercom: die auf den Entwurf von Funktionen angewandte Fassung, in der Form "wenn, möchte ich, damit", welche die Agile Extension übernimmt.
• Clayton M. Christensen, Taddy Hall, Karen Dillon, David S. Duncan, Know Your Customers' Jobs to Be Done, Harvard Business Review, 2016: die Theorie der Jobs to Be Done, aus der das Format hervorgeht.