Stories, keine Braindumps

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:

• Stories werden wie Notizen an sich selbst geschrieben: Commit-Hashes, Dateipfade, Middleware-Namen, "siehe Thread in Slack," kein Nutzer in Sicht.
• Arbeit wird in viele kleine Tasks zerlegt, und diese Tasks hängen direkt an Epics, die Story-Ebene wird komplett übersprungen.
• Akzeptanzkriterien sind mit Implementierungsnotizen verwoben, sodass niemand sagen kann, was "fertig" bedeutet, ohne den Code zu lesen.

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.¹ Das ist nicht das Problem. Das Problem ist, wofür jede Ebene da ist:

• Epic. Ein Arbeitskörper, meist über mehrere Sprints. Formuliert als Ergebnis, nicht als Feature-Liste. "Kunden können per SEPA-Lastschrift bezahlen." "Admins können Team-Mitgliedschaft selbst verwalten."
• Story. Ein Stück nutzersichtbarer Wert, der in einen Sprint passt. Hier lebt das Wer, Was, Warum. Die Einheit, über die Product und Design nachdenken können.
• Task. Arbeit ohne direkten nutzersichtbaren Wert. Library-Upgrades, CI-Kleinkram, eine Infra-Migration, toten Code löschen. Echte Arbeit, wert zu tracken, aber niemand wird fragen "was hat das geliefert?"
• Subtask. Engineering-Detail innerhalb einer Story oder Task. Der Ort für Implementierungsschritte, nicht für das übergeordnete Arbeitsitem.

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.

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:

1. Der Titel ist die Implementierung. "Auth-Middleware auf v2 migrieren." Kein Nutzer, kein Ergebnis. Vergleiche: "Nutzer bleiben bei Tab-Reloads angemeldet." Gleiche Arbeit. Das eine ist eine Story. Das andere ist eine Task, die der Engineer für sich selbst geschrieben hat.
2. Akzeptanzkriterien mit technischen Notizen vermischt. "AC: 1) Sessions überleben Reload. 2) 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:²

Es sieht wie eine Formalität aus. Ist es nicht. Es zwingt dich, drei Fragen zu beantworten, die du sonst überspringst:

1. Wer ist das für? Wenn du keine Rolle benennen kannst, schreibst du wahrscheinlich eine Task.
2. Was versuchen sie zu tun? In ihren Worten, nicht in deinen.
3. Warum ist es wichtig? Das ist die schwerste Klausel und die, die am meisten wert ist, erhalten zu bleiben. Alles andere lässt sich lockern. Das "damit" ist der Teil, der ein Refactoring des Templates überlebt.

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).³ 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.⁴ Zwei Jahrzehnte später ist es immer noch einer der kompaktesten Sanity-Checks, die es gibt.

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.

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.

1. Sie sind keine Stunden. Sie schätzen Größe, die Komplexität, Unsicherheit und Aufwand in eine relative Zahl bündelt. Eine 3 ist grob die dreifache Größe einer 1. Es sind keine drei Stunden, drei Tage oder drei von irgendwas Festem.
2. Fibonacci, nicht linear. Die kanonische Begründung ist Webers Gesetz: Menschen können Mengen, die sich nur um ein kleines Verhältnis unterscheiden, nicht zuverlässig unterscheiden.⁵ Eine 4-Punkte-Story und eine 5-Punkte-Story sind Rauschen. Eine 3 und eine 8 sind tatsächlich unterschiedlich. Die Lücken sind Absicht.
3. Der Wert ist das Gespräch, nicht die Zahl. Wenn drei Engineers unabhängig schätzen und bei 2, 2, 13 herauskommen, stoppt. Bildet keinen Durchschnitt. Die 13 hat etwas gesehen, was die anderen nicht gesehen haben. Das ist der ganze Sinn des Schätzens.
4. 13 ist ein Signal, keine Schätzung. Wenn sich der Raum auf 13 einigt, ist der richtige nächste Schritt fast immer "wir verstehen das noch nicht, lass uns das aufteilen oder einen Spike machen."

Eine kleine Taxonomie, die sich quer durch Teams bewährt:

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.

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.⁶ 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:

• Story oder Task? Eine Story beschreibt eine Veränderung im Systemverhalten aus Nutzerperspektive. "Refactor das Payment-Modul" und "Upgrade der ORM" sind keine Stories, und kein Splitting-Pattern macht Stories daraus. Splitting-Patterns wirken auf Stories; Tasks bekommen eine andere Behandlung.
• Besteht sie INVEST außer Small? Wenn der einzige fehlende Buchstabe S ist, ist Splitten das richtige Werkzeug. Wenn sie zusätzlich an Valuable (niemand profitiert) oder Testable (kein beobachtbares Ergebnis) scheitert, liegt das Problem im Framing, nicht in der Größe. Fixe die Story, bevor du sie schneidest.
• Ist sie wirklich zu groß? Ein brauchbares Sanity-Verhältnis: Ein Sprint sollte grob 6 bis 10 Stories für das gesamte Team komfortabel fassen. Wenn eine einzelne Story ein Drittel des Sprints auffrisst, will sie geschnitten werden. Wenn das Team zwölf Stories pro Sprint fertig bekommt und diese hier 5 Punkte hat, ist der Splitting-Impuls vielleicht verfrüht.

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:

• Ungefähr gleich große Slices sind besser. Ein 5-5-5-Split gibt Product drei lieferbare Optionen. Ein 12-1-1-Split gibt ihnen eine echte Story und zwei Rundungsfehler.
• Bevorzuge Splits, bei denen Slice eins etwas lehrt. Wenn Slice eins ein Nutzungsmuster bestätigt, ein Datenproblem offenlegt oder eine Integration beweist, werden Slices zwei und drei deutlich billiger zu schätzen und zu bauen. Der Punkt beim Slicing ist nicht nur kleiner, sondern kleiner und schneller zu lernen.

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

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:

1. Spike. Steckt in dieser Story ein echtes Unbekanntes? Wenn ja, zieh die Recherche als eigenes timeboxed Ticket raus und plane den Rest neu.
2. Paths. Beschreibt die Story mehr als einen Pfad durchs System? Wenn ja, zieh den Happy Path als eigenen Slice raus.
3. Interface. Macht die UI-Interaktion den meisten Aufwand aus? Wenn ja, liefere eine schlichte Variante jetzt und schmücke später nach.
4. Data. Sind verschiedene Datenformen im Spiel? Wenn ja, starte mit der einfachsten.
5. Rules. Stecken mehrere Geschäftsregeln drin? Wenn ja, liefere eine Regel nach der anderen.

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:

Und hier ist die gleiche Arbeit, geschrieben als Story:

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?)

• Sie hat einen Akteur, ein Ergebnis und einen Grund (die drei Connextra-Fragen).
• Sie hat mindestens ein testbares Akzeptanzkriterium.
• Abhängigkeiten sind verlinkt, nicht angenommen.
• Niemand beim Refinement geht raus und sagt "ich weiß immer noch nicht so richtig, was das ist."
• Sie passt in einen Sprint. Wenn nicht, wird sie geteilt, bevor sie in einen reinkommt.

Definition of Done (darf diese Story den Sprint verlassen?)

• Alle Akzeptanzkriterien sind von jemandem verifiziert, der nicht der Implementierer ist.
• Tests existieren auf der passenden Ebene und laufen grün.
• Die Änderung ist gemergt, im Zielumfeld deployed und beobachtbar.
• Dokumentation, Release Notes und interne Ankündigungen sind dort aktualisiert, wo sie es sein müssen.
• Das Ticket selbst ist geschlossen, mit einem kurzen Kommentar, was tatsächlich ausgeliefert wurde, besonders wenn sich der Scope geändert hat.

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.

1. Story und Task sind absichtlich unterschiedlich. Story hat einen Nutzer und einen Wert. Task ist Plumbing. Hänge Tasks nur für Plumbing-Arbeit direkt unter Epics; greife zur Story, wann immer ein Mensch profitiert.
2. Schreibe für den Leser, der nicht du ist. Das Wer, das Was und das Warum gehören in einfacher Sprache ins Ticket. Commit-Hashes und Dateipfade nicht.
3. INVEST ist ein günstiger Sanity-Check. Geh die sechs Buchstaben durch, bevor du eine Story in einen Sprint ziehst. "Testable" ist der, an dem die meisten Teams scheitern.
4. Punkte messen Größe, nicht Zeit. Fibonacci ist kein Gimmick; die Lücken sind da, weil dein Gehirn eine 4 nicht von einer 5 unterscheiden kann. Die Zahl ist weniger wichtig als das Gespräch, das sie produziert hat.
5. Schneide vertikal, nicht horizontal. Finde das Kernverhalten und schäle Variationen außen ab: Workflow-Schritte, CRUD-Operationen, Geschäftsregeln, Datenformen, Eingabemethoden. Jeder Slice sollte eigenständig ausliefern und dem Team etwas beibringen, das den nächsten Slice billiger macht.

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.

• Atlassian: Epics, Stories, Themes und Initiatives

  Die kanonische Referenz dafür, wie Jiras Hierarchie gedacht ist, inklusive der gleichrangigen Beziehung zwischen Story und Task.

• Bill Wake: INVEST in Good Stories, and SMART Tasks

  Der Artikel von 2003, der das Akronym INVEST eingeführt hat. Kurz, immer noch die beste Zusammenfassung.

• Ron Jeffries: Card, Conversation, Confirmation

  Die 3 C's von User Stories aus 2001. Zwei Seiten, immer noch essenziell.

• Agile Alliance: User Story Template

  Herkunft und Verwendung des Connextra-Templates 'Als, möchte ich, damit'.

• Mike Cohn: Why the Fibonacci Sequence Works Well for Estimating

  Die Begründung über Webers Gesetz für Fibonacci-Story-Points, von der Person, die sie populär gemacht hat.

• Humanizing Work: The Guide to Splitting User Stories

  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.

• Mike Cohn: What Is SPIDR?

  Ein kompaktes Fünf-Buchstaben-Mnemonic (Spikes, Paths, Interfaces, Data, Rules), das die häufigste Teilmenge der Humanizing-Work-Patterns abdeckt.

• Dan North: Introducing BDD

  Ursprung des Given / When / Then-Formats für Akzeptanzkriterien.

• Atlassian Team Playbook: User Stories

  Ein aktueller, praktischer Facilitation-Guide, um eine Story-Writing-Session als Team durchzuführen.