Von innen


4 Min. Lesezeit

Stories dünner schneiden

Acht Arten, eine User Story zu teilen, ohne ihren Wert zu verlieren

Teil acht der Werkzeugkiste des Product Owners. Im letzten Teil haben wir eine gute User Story geschrieben. Die meisten Stories fangen nicht so gut an. Sie fangen zu gross an.

Schneiden heisst, eine Story in kleinere, in sich stimmige Stücke zu teilen, die sich schätzen, bauen und testen lassen, alles innerhalb eines Sprints. Die Gründe sind verschieden: die Kapazität des Sprints, die Komplexität der Story, ein Teil davon, der noch unklar ist.

Es gibt eine Regel: Jedes Stück muss noch einen Teil des Werts liefern. Schneide die Story vertikal, durch alle Schichten des Systems, sodass jedes Stück etwas ist, das ein Nutzer tatsächlich verwenden kann. Eine dünne Scheibe, die von vorne bis hinten funktioniert, schlägt eine dicke, die nur in einer Schicht fertig ist.

Nach Schichten Nach Scheiben Story 1: Oberfläche Story 2: Logik Story 3: Daten Nichts, was ein Nutzer ausprobieren kann, bis die letzte Story fertig ist. Oberfläche Logik Daten Ganze Tage Halbe Tage Übertrag Mehr Arten Jede Scheibe funktioniert von A bis Z.
Dieselbe Arbeit, auf zwei Arten geschnitten. Nur die Scheiben rechts lassen sich einzeln abnehmen.

Wie man schneidet

  1. Prüf die Grösse und Komplexität der Story.
  2. Wähl eine Schneidetechnik oder eine Kombination und schneide die Story in zwei oder mehr Stories.
  3. Prüf jede neue Story:
    • Ist sie klein genug für einen Sprint?
    • Ist sie einfach genug, um sie zu schätzen?
    • Lässt sie sich testen?

In der Praxis kombinierst du meistens mehrere Techniken.

Acht Techniken

Sie stammen aus der Arbeit von Richard Lawrence zum Schneiden von Stories. Jede ist an einer Story des Ferientools gezeigt.

1. Workflow-Schritte. Enthält eine Story einen ganzen Workflow, teil ihn in Schritte, oder bau zuerst den Happy Path und später die Ausnahmen, Schleifen und Verzweigungen. Ferientool: «Antrag mit Bewilligung durch Teamleitung und HR» wird zu «Bewilligung durch die Teamleitung», später gefolgt von «HR bestätigt».

2. Varianten der Geschäftsregeln. Hat eine Story mehrere Geschäftsregeln, priorisier sie und bau sie nacheinander. Ferientool: zuerst ganze Tage. Danach halbe Tage. Die Regeln zum Übertrag am Jahresende später.

3. Varianten der Daten. Muss eine Story mit verschiedenen Datensätzen umgehen, bestimm sie, fang mit einem an und ergänze die anderen nach und nach. Ferientool: zuerst Ferien. Dann Krankheit, unbezahlter Urlaub, Militärdienst und Elternurlaub, jeweils als eigene Story.

4. Varianten der Schnittstellen. Spricht eine Story mit mehreren Schnittstellen oder bietet mehrere an, trenn sie und ergänze sie einzeln, zum Beispiel Web vor Mobile oder iOS vor Android. Ferientool: zuerst Bewilligung in der Web-App. Dann Bewilligung über einen Link in einer E-Mail. Später Bewilligung im Team-Chat.

5. Grösster Aufwand. Verursacht ein Teil der Story den grössten Aufwand, mach daraus eine eigene Story und bau sie zuerst. Die Stories danach werden günstig. Ferientool: «Abwesenheiten im Teamkalender anzeigen» bezahlt die Kalenderkomponente einmal. «Offene Anträge anzeigen» und «unterbesetzte Wochen markieren» verwenden sie wieder.

6. Einfach oder komplex. Hat die Story einen einfachen Kern, der den grössten Teil des Werts liefert, bau zuerst den Kern und sammle die Sonderfälle in einer oder mehreren eigenen Stories. Ferientool: zuerst ein Antrag innerhalb eines Kalenderjahres. Anträge über Neujahr, mit zwei verschiedenen Guthaben, später.

7. Performance nachlagern. Zieh Anforderungen an Performance, Sicherheit und Benutzbarkeit in eigene Stories heraus. Ferientool: «Der Teamkalender lädt für 300 Leute in unter einer Sekunde» wird eine eigene Story. Das wichtige Wort ist Story. Eine Anforderung aufzuschieben ist in Ordnung. Sie zu vergessen nicht. Gib ihr einen Namen und stell sie in den Backlog.

8. Operationen. Enthält eine Story Erstellen, Lesen, Ändern und Löschen, bau die Operationen einzeln. Ferientool: Antrag stellen. Antrag stornieren. Die Daten eines offenen Antrags ändern.

Der Schnitt, der nicht funktioniert

Der Schnitt, zu dem Teams zuerst greifen, geht nach Schichten: «Backend für Ferienanträge», dann «Frontend für Ferienanträge», dann «Tests». Keines davon liefert für sich etwas, keines kann der Product Owner abnehmen, und der Wert zeigt sich erst, wenn das letzte fertig ist. Endet der Sprint dazwischen, hast du drei halbfertige Dinge statt eines fertigen.

Die andere Falle ist die «Recherche»-Story ohne Ergebnis. Wenn du etwas herausfinden musst, begrenz die Zeit und vereinbare vorher, was die Antwort entscheiden soll.

Als Nächstes

Der Backlog ist jetzt voll mit kleinen, wertvollen Stories. Nächstes Mal: wie er so bleibt und wie man ihn mit den Leuten priorisiert, die anderer Meinung sind.

Mehr in Von innen

Teilen