· Torsten  · 3 min read

6 Bausteine, mit denen ich Übersicht in meinen Projekten schaffe

Was ist ein Epic, was eine User Story, was ein Subtask? Wohin mit querschnittlicher Arbeit? In fast allen Projekten gab es darüber Verwirrung. Ich habe sechs Bausteine gefunden, die das lösen.

Was ist ein Epic, was eine User Story, was ein Subtask? Wohin mit querschnittlicher Arbeit? In fast allen Projekten gab es darüber Verwirrung. Ich habe sechs Bausteine gefunden, die das lösen.

In fast allen Projekten, in denen ich bisher gearbeitet habe, gab es Verwirrung um die verschiedenen Arten von Tickets. Was ist ein Epic, was eine User Story, was ein Subtask? Wohin mit querschnittlicher Arbeit, die keinem Feature zugeordnet werden kann? Und vor allem: Was kommt wohin? Das Ergebnis war meistens: Irgendwie ist alles eine Story. Das Ganze in einer flachen Liste sorgt schnell für Kopfschmerzen — beim Team und beim PO.

Ich habe zuletzt gute Erfahrungen mit sechs Bausteinen gemacht, die sich in zwei Gruppen aufteilen und unterschiedlichen Zwecken dienen.


Zwei Bausteine schaffen Struktur — sie geben Richtung, werden aber nicht selbst umgesetzt.

Ich nutze Initiativen für das große Ziel. Kein Task, kein Ticket — eine Richtung. „Nutzer sollen sich selbst onboarden können.” Und Epics für die Schritte dorthin: Registrierung, Profil anlegen, erste Aktion. Wer das sauber aufbaut, hat eine Geschichte, die jeder im Team nachvollziehen kann — auch wer gerade erst dazukommt.


Vier Bausteine sind für die Umsetzung — drei davon sind Story-Typen, die jeweils eine andere Sicht auf das Vorhaben abbilden.

User Stories sind der Blick nach außen. Konkreter Wert für Nutzer oder Kunden, marktorientiert gedacht. Sie sind die einzigen Stories, die ich schätze und die in die Velocity einfließen. Damit sind sie mein Maßstab dafür, wie viel Wert das Team pro Iteration wirklich liefert.

Devteam Stories sind der Blick nach innen. Was braucht das Team, um weiter mit hoher Qualität liefern zu können? Refactoring, Teststrategien, Wissenstransfer — oft querschnittlich, oft wiederkehrend. Keine Schätzung, keine Velocity. Reine Transparenz darüber, was neben der Wertlieferung passiert.

Project Stories sind der Blick auf die Rahmenbedingungen. Hardware, Zugänge, Workshops, Entscheidungen. Oft die Voraussetzung dafür, dass das Team überhaupt arbeiten kann. Auch hier: keine Schätzung, keine Velocity — aber Sichtbarkeit für Arbeit, die sonst untergeht.

Wenn die Velocity mal niedrig ist, schaue ich mir die Verteilung an. Zu viele Devteam und Project Stories im Sprint? Dann bleibt schlicht weniger Kapazität für User Stories. Die Ursache ist dann kein langsames Team, sondern ein überladener Rahmen.

Workitems sind die kleinste Einheit und optional. Sie hängen an einer Story und zerlegen sie in Tagesschritte. Wer Daily Standups macht, kennt die Frage: „Woran arbeitest du heute?” Workitems geben die Antwort. Sie helfen bei der Planung und schaffen Transparenz im Tagesgeschäft.


Diese Bausteine sind für mich nicht nur ein Denkmodell. Ich arbeite damit in Betterplan, wo sie direkt in vier Sichten eingebettet sind: Auf der Story Map strukturiere ich das Vorhaben mit Initiativen, Epics und User Stories — das große Bild. Im Backlog priorisiere ich die Stories nach Reifegrad. Auf dem Iteration Board sehe ich, wer gerade woran arbeitet — runter bis auf Workitem-Ebene. Und die Delivery Timeline zeigt mir, wann was voraussichtlich fertig wird. Vier Sichten, dieselben Bausteine, alles verbunden. Das gibt mir die Übersicht, die ich in keinem anderen Tool so hatte.

Wie strukturiert ihr eure Vorhaben? Ist bei euch alles ein Ticket?

Zurück zu Ressourcen

Ähnliche Artikel

Alle Ressourcen »