Story-Typen: User, Project und Devteam Story
Nicht jede Arbeit schafft direkten Nutzen für Kundschaft. Trotzdem will sie sichtbar sein. Betterplan unterscheidet deshalb drei Arten von Stories. Alle durchlaufen dieselben Zustände, unterscheiden sich aber in Blickrichtung und in dem, was sie zur Planung beitragen.
Die drei Typen
| Typ | Blickrichtung | Beispiel aus QuickCart | Schätzung und Velocity |
|---|---|---|---|
| User Story | Nach außen: konkreter Wert für Nutzerinnen und Nutzer. | Produktsuche, Lieferzeitfenster wählen | Wird geschätzt und zählt in die Velocity. |
| Project Story | Auf die Rahmenbedingungen: Organisation, Hardware, Zugänge, Dokumentation, Entscheidungen. | Sicherheits-Audit, Benutzer-Onboarding-Docs | Keine Schätzung, keine Velocity. |
| Devteam Story | Nach innen: Was braucht das Team, um mit hoher Qualität weiterzuliefern? Refactoring, Build-Pipeline, technische Schulden. | Such-Index-Optimierung, Produktbild-CDN | Keine Schätzung, keine Velocity. |
In der Oberfläche heißen die Typen Story, Dev-Story und Projekt-Story, Letztere beiden zum Beispiel im Filter unter Aufgabentypen und im Dialog Umwandeln in.
Wann welcher Typ?
Gehe die Fragen der Reihe nach durch und höre bei der ersten Antwort „ja“ auf:
- Liefert die Arbeit direkten Wert für Nutzerinnen oder Nutzer? Dann ist es eine User Story. Sie hängt unter einem Epic.
- Ist sie technisch und intern im Entwicklungsteam? Zum Beispiel Refactoring, CI/CD oder Teststrategie. Dann ist es eine Devteam Story.
- Ist sie organisatorisch, vertraglich oder dokumentarisch, oder hält sie eine Entscheidung fest? Dann ist es eine Project Story.
- Ist es nur ein kleiner Schritt, der hilft, eine Story in der Iteration abzuarbeiten? Dann ist es kein Story-Typ, sondern ein Workitem.
Steckt in einer Story Nutzerwert und technische Arbeit, bleibt der Nutzerwert die User Story. Den technischen Teil lagerst du nur dann in eine Devteam Story aus, wenn er wirklich übergreifend ist. Bleibt er an dieser einen Story, gehört er als Workitem dazu.
Warum gibt es die Trennung?
- Ehrliche Velocity. Nur User Stories fließen in die Velocity ein. So misst sie, wie viel Wert das Team pro Iteration wirklich liefert, und nicht, wie viel es gearbeitet hat. Mehr dazu unter Schätzen: die Grundlagen.
- Sichtbare Nebenarbeit. Devteam und Project Stories bekommen keine Punkte, tauchen aber auf den Boards auf. So geht Arbeit, die sonst untergeht, nicht verloren.
- Bessere Diagnose. Ist die Velocity niedrig, lohnt ein Blick auf die Verteilung: Zu viele Devteam und Project Stories in der Iteration lassen weniger Kapazität für User Stories. Die Ursache ist dann kein langsames Team, sondern ein überladener Rahmen.
Typen im Alltag
- Anlegen: Beim Anlegen einer Aufgabe wählst du Story, Dev-Story oder Projekt-Story.
- Filtern: Im Filter schränkst du die Ansicht über Aufgabentypen auf einzelne Typen ein. Beachte: Dev- und Projekt-Storys gehören zu keinem Epic und verschwinden, solange du nach Epics filterst.
- Typ ändern: Im Bearbeitungsfenster einer Aufgabe wechselst du unter Hierarchie mit Umwandeln in den Typ, zum Beispiel von einer User Story in eine Dev-Story.
Mehr zum Hintergrund
Warum drei Blickrichtungen? Der Blogartikel 6 Bausteine, mit denen ich Übersicht in meinen Projekten schaffe erzählt, wie es dazu kam, und Velocity ist keine Geschwindigkeit erklärt, warum technische Arbeit nicht in die Velocity gehört.