24. April 2026
Eine praktische Auffrischung zum Schreiben von Jira-Arbeit, die das ganze Team tatsächlich nutzen kann. Wie die Hierarchie gedacht ist, was eine Story von einem technischen Braindump unterscheidet, und die wenigen Gewohnheiten, die ein Team Sprint für Sprint ausgerichtet halten.
21 Min. Lesezeit
Die meisten Teams, die schon eine Weile Scrum fahren, können Arbeit gut herunterbrechen. Die Ticket-Anzahl steigt. Das Board sieht beschäftigt aus. Arbeit wird fertig. Und trotzdem: Wenn jemand von außerhalb des Teams ein Ticket öffnet, kann er oft nicht erkennen, was eigentlich ausgeliefert wird und für wen. Die Informationen sind technisch gesehen da. Sie sind nur für die Person organisiert, die sie geschrieben hat, nicht für irgendjemand anderen, der sie lesen muss.
Ein paar gängige Drift-Muster:
Nichts davon ist falsch im Sinne von "du hast die Regeln von Jira verletzt." Es ist falsch im Sinne von "niemand außerhalb des Kopfes des Autors kann diese Tickets verwenden." Product kann daraus keine Roadmap machen. Design kann keine Reibung erkennen. QA kann nichts verifizieren. Ein neuer Kollege hat keine Chance.
Dieser Beitrag ist eine praktische Auffrischung der Gewohnheiten, die die Arbeit eines Teams für alle drumherum lesbar halten: die Hierarchie, die Anatomie einer Story, Schätzen, Schneiden und die zwei kurzen Checklisten, die das Ganze zusammenhalten. Das Ziel ist kein Prozess-Theater. Das Ziel ist, Arbeit zu schreiben, die den Kontakt mit anderen Menschen als ihrem Autor überlebt.
Erstmal der mechanische Teil. Jiras Standard-Hierarchie sieht so aus:
Atlassian behandelt Story und Task als gleichrangig, beide können unter einem Epic sitzen und beide können Subtasks haben. Technisch kannst du also, ja, Tasks direkt unter ein Epic hängen, und Jira wird nicht meckern.1 Das ist nicht das Problem. Das Problem ist, wofür jede Ebene da ist:
Wenn ein Team ein Epic direkt in Tasks zerlegt und Story überspringt, passieren zwei Dinge. Erstens wird jedes Item zu einer technischen Arbeit, egal ob es tatsächlich Nutzerwert liefert, denn "Task" signalisiert "Plumbing" für jeden, der ein Board liest. Zweitens hat die Frage "warum machen wir dieses Epic überhaupt?" keinen Ort zum Leben. Die Epic-Beschreibung enthält meist eine Zeile und einen Figma-Link. Die Tasks sind Implementierung. Das Warum verflüchtigt sich.
Kurzer Selbstcheck
Öffne dein aktuelles Epic. Kannst du die direkten Kinder lesen und die Frage beantworten "was wird ein Nutzer oder Operator tun können, was vorher nicht ging?" Wenn die Antwort aus den Implementierungsnotizen der Tasks kommt, brauchst du eine Story-Ebene.
Verwende Task für den Kleinkram. Verwende Story für alles mit einem Nutzer, einem Kunden, einem Operator oder einem internen Tool-Nutzer auf der anderen Seite. Subtasks gehören hinein. Das ist die Form.
Der eine Test, der die meisten schlechten Stories erwischt:
Wenn die Antwort nein ist, hast du einen Braindump geschrieben, keine Story. Beide können dieselben Informationen enthalten. Sie sind nur anders organisiert, weil sie unterschiedlichen Lesern dienen.
Ein Braindump wird von der Person geschrieben, die den Kontext bereits kennt, für die Person, die sie morgen sein wird, wenn sie sich wieder an die Tastatur setzt. Er beginnt mit "Refactor useAuthController, um die neue Session-Struktur aus DEV-1234 zu berücksichtigen." Er ist effizient, privat und völlig in Ordnung als Notiz an sich selbst. Er ist keine Story.
Eine Story ist ein Vertrag zwischen Product, Design und Engineering. Sie beschreibt die Änderung in Begriffen des Ergebnisses, nicht des Mechanismus. Der Implementierungsplan gehört in Subtasks, ein verlinktes Tech-Design-Dokument oder in eine PR-Beschreibung. Halte sie getrennt.
Zwei gängige Fehlermuster:
getSession() refactoren, um den neuen Cookie-Helper zu verwenden. 3) Das alte legacyAuth-Modul löschen." Das erste ist ein Akzeptanzkriterium. Die anderen beiden sind Implementierung. Trenne sie.Das Connextra-Template von 2001 ist immer noch der schnellste Weg, eine Story in Form zu zwingen:2
Es sieht wie eine Formalität aus. Ist es nicht. Es zwingt dich, drei Fragen zu beantworten, die du sonst überspringst:
Sei nicht zimperlich mit der Formulierung. Schreib sie in klarer Prosa, wenn du das lieber magst. Aber wenn eine Story diese drei Fragen nicht irgendwo in ihrem Text beantworten kann, ist sie noch keine Story.
Ron Jeffries hat dieselbe Idee 2001 als die 3 C's formuliert: Eine Story ist eine Card (kurz, auf einer Karte, weil die Karte nicht alles halten kann), eine Conversation (die Details werden im Gespräch gefüllt) und eine Confirmation (die Akzeptanzkriterien, die beweisen, dass sie fertig ist).3 Das Wichtigste auf der Card ist die Absicht. Der Rest ist, wofür die Conversation und die Acceptance Criteria da sind.
Bill Wake schlug INVEST 2003 als Checkliste für "ist diese Story bereit?" vor.4 Zwei Jahrzehnte später ist es immer noch einer der kompaktesten Sanity-Checks, die es gibt.
| Buchstabe | Bedeutung | Was er erwischt |
|---|---|---|
| I | Independent | Kann das gebaut werden, ohne auf zwei andere Stories zu warten? Wenn nicht, sequenziere sie. |
| N | Negotiable | Ist das Wie noch offen, oder ist die Lösung schon in die Beschreibung eingebacken? |
| V | Valuable | Wer profitiert und wie? Wenn du es nicht beantworten kannst, hast du eine Task, keine Story. |
| E | Estimable | Ist der Scope klar genug, dass drei Engineers sich grob über die Größe einig sein könnten? |
| S | Small | Passt in einen Sprint. Wenn nicht, teile sie auf. |
Der Buchstabe, der in der Praxis am häufigsten verletzt wird, ist Testable. Akzeptanzkriterien wie "das Feature funktioniert korrekt" oder "Nutzer können X verwenden" sind nicht testbar. Sie sind ein Vibe. QA braucht beobachtbares Verhalten.
Given / When / Then
Dan Norths BDD-Notation liest sich immer noch so sauber wie 2006. "Given ein Nutzer mit einer abgelaufenen Session, When er die App öffnet, Then sieht er den Anmeldebildschirm." Drei Klauseln, keine Mehrdeutigkeit, keine Implementierung. Du kannst das QA übergeben und weggehen.
Eine Bullet-Liste beobachtbarer Ergebnisse funktioniert genauso gut. Das Format ist weniger wichtig als die Eigenschaft: ein neutraler Leser kann erkennen, ob die Story fertig ist, ohne den Engineer zu fragen.
Story Points sind die Quelle von mehr Team-Drama als jedes andere einzelne Item auf dem Board. Hier die Kurzfassung.
Eine kleine Taxonomie, die sich quer durch Teams bewährt:
| Punkte | Was es meist bedeutet |
|---|---|
| 1 | Trivial. Config-Änderung, Copy-Anpassung, ein kleiner Bugfix. |
| 2 | Klein und gut verstanden. Ein paar Dateien, ein Test, keine Überraschungen erwartet. |
| 3 | Mittel. Berührt einen Bereich, ein oder zwei Edge Cases zum Nachdenken. |
| 5 | Substanziell. Schneidet durch ein paar Module oder hat echte Unsicherheit. |
| 8 | Groß. Will wahrscheinlich zwei Stories sein. Akzeptiere es, wenn du musst, flagge es. |
| 13 | Nimm das nicht in einen Sprint. Teile es, spike es, oder mach ein richtiges Epic daraus. |
Story-Splitting ist die am meisten geübte Fähigkeit in einem reifen Agile-Team und die am deutlichsten fehlende in einem Team, das abdriftet. Macht man es richtig, liefert jeder Sprint sichtbaren Fortschritt. Macht man es falsch, füllt sich das Board mit Tickets "in progress", die erst landen können, wenn drei andere Tickets gelandet sind.
Wenn eine Story zu groß ist, schneiden Engineers sie instinktiv horizontal, nach technischer Schicht: eine Backend-Story, eine Frontend-Story, eine Migrations-Story, vielleicht eine Analytics-Story. Saubere Trennung, jeder hat seine Spur, jeder versteht sein Stück.
Das ist der schlechteste mögliche Schnitt.
Kein einziger dieser Slices liefert nutzersichtbaren Wert für sich allein. Die "Zwei-Wochen-Story" ist immer noch zwei Wochen lang. Nur hat sie jetzt die dreifachen Koordinationskosten, drei separate Reviews und einen harten Integrationsschritt am Ende, in dem jedes verrutschte Stück alles andere blockiert. Nichts wird ausgeliefert. Nichts wird gelernt. Das Team ist genauso langsam, nur mit mehr Meetings.
Horizontale Splits brechen INVEST gleich dreifach
Der Backend-only-Slice ist nicht Independent (Frontend wartet darauf), nicht Valuable (kein Nutzer profitiert von einer API, die niemand aufruft) und aus Nutzersicht nicht wirklich Testable. Drei der sechs Buchstaben verletzt. Wenn ein Split INVEST schlimmer verletzt als die ursprüngliche Story, ist es kein Split.
Die Alternative ist der vertikale Slice: ein dünner, durchgängiger Schnitt durch dasselbe Feature, der jede Schicht berührt, die das Feature braucht (Daten, Logik, UI, alle Integrationen), aber ein kleineres Stück nutzersichtbaren Werts liefert. Jeder vertikale Slice ist eigenständig lieferbar. Jeder lehrt das Team etwas über das Problem, bevor der nächste Slice startet.
Diese Formulierung aus dem Humanizing-Work-Guide zum Story-Splitting ist das nützlichste mentale Modell fürs Schneiden, das es gibt.6 Jede schneidbare Story hat ein essenzielles Verhalten und eine Menge von Variationen, die darauf aufliegen: Datentypen, Nutzerrollen, Edge Cases, Regelvarianten, UI-Reichtum. Liefere den Kern zuerst. Variationen werden separate Stories, die auf eigener Grundlage priorisiert, verschoben oder fallen gelassen werden können.
Ein kurzer Preflight, bevor du zu den Splitting-Patterns greifst:
Der Humanizing-Work-Guide fasst neun bewährte Splitting-Patterns zusammen. Sie stehen in grober Reihenfolge von breit nützlich zu spezialisiert. Arbeite die Liste nach unten durch; für die meisten Stories produziert eines der ersten fünf einen sauberen Schnitt.
1. Workflow-Schritte. Eine Story, die einen mehrstufigen Prozess beschreibt, schneidet sich meist sauber entlang dieser Schritte. Liefere zuerst den einfachsten durchgängigen Pfad, dann die Zwischenschritte als eigene Stories.
Beispiel. "Editor:innen veröffentlichen Artikel über Legal- und Marketing-Freigabe." Aufgeteilt in: direkt veröffentlichen ohne Review; veröffentlichen mit Editor-Review; mit Legal-Review; mit Marketing-Review; Vorschau im Staging vor dem Veröffentlichen. Fünf lieferbare Slices, jeder durchgängig sichtbar.
2. Operationen (CRUD). Das Wort "managen" im Story-Titel ist fast immer ein Hinweis: es versteckt mehrere Operationen hinter einem Verb. "Nutzer managen ihren Account" ist in Wirklichkeit Create (registrieren), Read (Profil ansehen), Update (Einstellungen ändern), Delete (Account schließen). Vier Stories, oft mit sehr unterschiedlicher Priorität.
3. Variationen in Geschäftsregeln. Ein Feature, viele Regeln. Liefere die Kernregel jetzt; jede zusätzliche Regel ist eine eigene Story. "Flüge mit flexiblen Daten suchen" unterstützt vielleicht "innerhalb von N Tagen eines Zieldatums", "irgendein Wochenende in einem gegebenen Monat" und "plus/minus N Tage eines Fensters". Drei verschiedene Regeln, drei Stories, oft mit sehr unterschiedlichem Wert und Aufwand.
4. Variationen in Daten. Starte mit der einfachsten Datenform, die das Feature braucht, und erweitere später. Eine Ortssuche liefert zuerst nur Länder, dann Städte, dann Stadtteile. Das Feature lebt nach Slice eins durchgängig; spätere Slices erweitern, was es verarbeitet. Wichtig: Oft stellt sich heraus, dass spätere Datenvarianten weniger gewünscht sind als der Kern und depriorisiert werden können.
5. Eingabemethoden. Die UI macht den meisten Aufwand aus, nicht die zugrundeliegende Logik. Liefere das Feature mit minimalem Input zuerst (einfaches Textfeld, schlichtes Formular, getippte Werte); die polierte Interaktion (Kalender-Picker, Autocomplete, Drag-and-Drop) ist ein Folge-Slice. Das Feature funktioniert ab Tag eins, es sieht nur schlicht aus.
6. Major Effort. Die erste Variante trägt den gesamten Infrastrukturaufwand; nachfolgende Varianten sind fast kostenlos, sobald sie gelandet ist. Kreditkartenverarbeitung: einen Kartentyp zuerst durchgängig implementieren. Die anderen drei hinzuzufügen ist eine viel kleinere Story, sobald die Zahlungspipeline existiert, und unterwegs hast du genug gelernt, um den Restaufwand solide zu schätzen.
7. Einfach, dann komplex. Im Planning wächst der Scope, weil das Team immer wieder "ja, aber was ist mit X?" sagt. Halte den einfachen Kern als erste Story fest; jedes "was ist mit X?" wird ein Kandidat für eine eigene Story, die Product priorisieren, verschieben oder fallen lassen kann. Das ist die Kur gegen Scope Creep im Refinement.
8. Performance verschieben. Wenn ein signifikanter Teil der Schätzung "schnell machen" statt "funktionsfähig machen" ist, trenne beides. Liefere die korrekte, aber langsame Variante zuerst, mit einem Loading-State wenn nötig. Optimiere in einer Folge-Story, sobald echte Nutzungsdaten zeigen, wo die Zeit tatsächlich hingeht. Verfrühte Optimierung verbrennt Schätzaufwand.
9. Spike. Das ausdrückliche letzte Mittel. Wenn das Team die Implementierung wirklich nicht gut genug versteht, um zu schätzen, timebox eine Recherche-Story. Ihre Akzeptanzkriterien sind die Fragen, die beantwortet werden müssen. Die eigentliche Feature-Arbeit wird die Story nach dem Spike, geschätzt mit echten Informationen. Greif nur dann dazu, wenn die anderen Patterns nicht passen. Ein Spike ist kein Split, er ist das Eingeständnis, dass du noch nicht schneiden kannst.
Der häufigste Fehler beim Anwenden dieser Patterns ist, beim ersten funktionierenden Split stehenzubleiben. Die Patterns schließen sich nicht aus. Jede hinreichend große Story lässt sich meist drei oder vier verschiedene Arten schneiden: nach Workflow, nach Daten, nach Regeln, nach Interface. Erzeuge mehrere Kandidaten, skizziere sie am Board, und wähle dann den Split, der Product am saubersten erlaubt, die wenigst wertvollen Slices zu depriorisieren.
Zwei Faustregeln fürs Wählen zwischen Kandidaten:
Zwei oder drei Übungen, kein Vortrag
Der schnellste Weg, Story-Splitting zu vermitteln, ist kein Workshop. Nimm eine echte, zu große Story aus dem Backlog ins Refinement. Erzeuge drei verschiedene Splits mit drei verschiedenen Patterns. Lass das Team abstimmen, welchen es lieber ausliefern würde. Macht diese Übung zweimal, vielleicht dreimal, über zwei Refinements verteilt. Teams lernen das mit rund zwei bis drei Stunden gezielter Praxis, nicht mit Wochen.
Die Neun-Pattern-Liste ist der komplette Werkzeugkasten. Aber im laufenden Refinement, wenn eine 13-Punkte-Story am Board klebt und drei Leute dich erwartungsvoll anschauen, willst du etwas Kürzeres, das du laut aussprechen kannst. Genau dafür ist Mike Cohns SPIDR da.7 Fünf Buchstaben, jeder ein Impuls für einen gängigen Splitting-Winkel. Kein Ersatz für die neun Patterns; eine komprimierte Teilmenge, leichter zu merken, wenn die Zeit drängt.
| Buchstabe | Steht für | Wann du dazu greifst | Kleines Beispiel |
|---|---|---|---|
| Spikes | Recherche | Das Team kann nicht schätzen, weil der Implementierungsansatz unklar ist | "Untersuche, welche Payment-Provider zu unseren Constraints passen" (timeboxed) |
| Paths | Workflows | Eine Story deckt mehrere User Journeys oder Workflow-Schritte ab | Happy Path zuerst; Fehlerpfade als Folge-Stories |
| Interfaces | Input-UX | Die UI macht den meisten Aufwand aus, nicht die darunterliegende Logik | Einfaches Textfeld jetzt; Autocomplete und Typeahead später |
| Data | Scope | Die Story muss verschiedene Datenformen, Bereiche oder Locales verarbeiten | Mit Ländern starten; Städte, dann Stadtteile nachziehen |
Gegen die volle Liste gemappt: Spikes deckt Pattern 9 ab, Paths Pattern 1, Interfaces Pattern 5, Data Pattern 4, Rules Pattern 3. SPIDR trifft die fünf häufigsten Situationen. Nicht abgedeckt: Operationen / CRUD (Pattern 2), Major Effort (6), einfach-dann-komplex (7), Performance verschieben (8). Wenn SPIDR keinen sauberen Split liefert, arbeite die volle Liste durch.
SPIDR in der Praxis. Wenn eine Story zu groß aussieht, sag das Akronym laut und gehe die Buchstaben der Reihe nach durch:
Meist hast du schon bei Buchstabe zwei oder drei eine Antwort. Genau das ist der Wert von SPIDR: im Refinement hast du keine zehn Minuten, um neun Patterns durchzugehen. Du hast zwei, und SPIDR findet in dieser Zeit für die meisten Stories einen Split.
Hier ist die Art von Story, die oft als Braindump geschrieben wird:
Task
AUTH-482
To do
Beschreibung
Braucht Updates in authMiddleware.ts und sessionStore.ts. Hängt
von DEV-1234 (neuer Cookie-Helper) ab. Sollte außerdem den
Legacy-parseToken-Pfad löschen. @mark kennt den Kontext. Siehe
Thread in #squad-auth vom letzten Donnerstag.
AC: useAuthController nutzt die neue Session-Struktur,
Legacy-parseToken-Pfad ist weg, bestehende Auth-Tests bleiben
grün.
Und hier ist die gleiche Arbeit, geschrieben als Story:
Story
AUTH-482
To do
Beschreibung
Als angemeldeter Nutzer möchte ich, dass meine Session das Neuladen oder das Öffnen neuer Tabs überlebt, damit ich während normaler Multi-Tab-Nutzung nicht gezwungen bin, mich erneut anzumelden.
Kontext
Aktuell regenerieren wir den Session-Token bei jedem Seitenaufruf, was Sessions bei gängigen Multi-Tab-Mustern fallen lässt. Support hat das als Top-Beschwerde dieses Monats markiert.
Akzeptanzkriterien
Nicht im Scope: "Angemeldet bleiben" über Browser-Neustarts hinweg (separate Story).
Subtasks: neuen Cookie-Helper aus DEV-1234 übernehmen;
Legacy-parseToken-Pfad entfernen; Integration-Tests für Reload-
und Neuer-Tab-Flows hinzufügen.
Gleiche Arbeit. Gleicher Engineer. Zehn Minuten mehr im Vorfeld. Der Product Manager kann jetzt sehen, was ausgeliefert wird. QA kann es verifizieren. Ein neuer Kollege liest drei Bullets und ist orientiert. Nächstes Quartal, wenn jemand fragt "warum haben wir die Auth-Schicht angefasst?", antwortet das Ticket für sich selbst.
Zwei kurze Checklisten, eine an jeder Sprint-Grenze. Sie sind keine Zeremonie. Sie sind der Mechanismus, der Stories davor bewahrt, mitten im Sprint zu vergammeln.
Definition of Ready (darf diese Story in einen Sprint?)
Definition of Done (darf diese Story den Sprint verlassen?)
Beide Listen sind Team-Artefakte. Schreibt eure gemeinsam, haltet sie kurz, pinnt sie im Team-Bereich. Schaut jedes Quartal oder so in einer Retro drauf. Der Punkt ist nicht, eine perfekte Liste zu haben. Der Punkt ist, eine gemeinsame Liste zu haben.
Nichts davon ist neu. Die meisten Referenzen unten sind über zwanzig Jahre alt. Was für jedes Team neu ist, ist der konstante Druck des Driftens: neue Leute kommen, alte Gewohnheiten verblassen, das Board füllt sich langsam mit Tickets in einer privaten Sprache. Die Heilung ist nicht mehr Zeremonie. Sie ist eine geteilte, kurze, wiederholbare Messlatte für das, was eine Story ist und was sie enthalten muss.
Einigt euch auf die Regeln, nicht auf den Prozess. Dann macht die langweilige Sache konsistent, Sprint für Sprint, und die Arbeit des Teams wird für alle drumherum wieder lesbar.
Es gibt einen Skill dafür
INVEST, Connextra und SPIDR gibt es als Agent-Skill, der ein Ticket-Draft
umschreibt und zu große Storys aufteilt. Installation mit npx skills@latest add saschb2b/skills --skill to-story oder direkt zum vollen
to-story-Skill.
Die kanonische Referenz dafür, wie Jiras Hierarchie gedacht ist, inklusive der gleichrangigen Beziehung zwischen Story und Task.
Herkunft und Verwendung des Connextra-Templates 'Als, möchte ich, damit'.
Die 3 C's von User Stories aus 2001. Zwei Seiten, immer noch essenziell.
Der Artikel von 2003, der das Akronym INVEST eingeführt hat. Kurz, immer noch die beste Zusammenfassung.
Die Begründung über Webers Gesetz für Fibonacci-Story-Points, von der Person, die sie populär gemacht hat.
Die umfassendste Behandlung von vertikalem Slicing, die es gibt. Neun Patterns, ein klarer Entscheidungsfluss und das Framing, auf dem der gesamte Splitting-Abschnitt dieses Posts aufbaut. Schick ihn deinem Team.
Ein kompaktes Fünf-Buchstaben-Mnemonic (Spikes, Paths, Interfaces, Data, Rules), das die häufigste Teilmenge der Humanizing-Work-Patterns abdeckt.
Ursprung des Given / When / Then-Formats für Akzeptanzkriterien.
Ein aktueller, praktischer Facilitation-Guide, um eine Story-Writing-Session als Team durchzuführen.
| Testable |
| Sind die Akzeptanzkriterien für jemanden beobachtbar, der nicht du ist? |
| Rules |
| Logik |
| Ein Feature, mehrere Geschäftsregeln liegen darauf |
| Basis-Preisregel zuerst; Promo- und Tier-Regeln folgen |