Descending the Tower of Babel: Epics, Features & Co.

Teile diesen Beitrag mit deinen Freunden!

„Die Sprachverwirrung“, Gustave Doré (1832–1883)

Einmal glattziehen: Feature – Epic – User Story – Task – Aufgabe – Unteraufgabe – und andere, wie unterscheiden sich diese Begriffe und wie spielen sie zusammen?

Damit wir in Diskussionen das gleiche Verständnis der Begriffe haben, müssen wir manchmal im Team zuvor die Begrifflichkeiten definieren. In der nachstehenden Situation gehe ich von dem Einsatz einer Definition of Ready aus, die alle User Storys erfüllen müssen, bevor sie in den Sprint gezogen werden können.

Vorab die gute Nachricht von Mike Cohn: „First, the terms don’t matter that much“[1], d.h. wir müssen nur die Begrifflichkeiten in der Kaskade vom Großem zum Kleinen festlegen. Es hilft jedoch, wenn man sich eine Struktur überlegt, die auch von den zum Einsatz kommenden Tools unterstützt wird.

Produktbeispiel mit Features (rot umrandet)

Ich stelle mir gerne eine (Software-)Produktverpackung vor, auf deren Seite die wesentlichen Merkmale aufgelistet sind. Diese bezeichne ich als Features. Schaut man in der Bedienungsanleitung dann nach, was sich hinter diesem Feature verbirgt, kommt man zu den Epics (oder den großen, großen User Storys). Geht man noch weiter ins Detail, findet man weitere Eigenschaften, die für die User einen Mehrwehrt darstellen. Das sind die kleineren User Storys, die vielleicht immer noch mehrere Akzeptanzkriterien haben (und dadurch potentiell noch weiter verkleinert werden können). Das Ende dieses Drill-Downs ist dann erreicht, wenn nur noch 1 Akzeptanzkriterium vorhanden ist. Das wäre dann die kleinste, unteilbare User Story. Darunter existieren nur noch (Unter-) Aufgaben, die zur Realisierung dieser atomaren User Story umgesetzt werden müssen, aber für sich genommen keinen Mehrwert für den Anwender darstellen.

 

 

 

 

 

 


Feature Auch bekannt als „Thema,“ „Initiative“,
“ Size XL Story“
Dies würden die Marketing Leute auf die Verpackung schreiben oder ein Vertriebler im Elevator Pitch ansprechen. Beantwortet die Frage: Was soll umgesetzt werden?

Die Kaskade.
Epic Auch bekannt als „Big big User Story“,
„Size L Story“
Ein Feature besteht aus mehreren Epics.
User Story Auch bekannt als „Big User Story“,
„Size M Story“
Ein Epic besteht aus mehreren User Storys. Sie liefern einen Mehrwert für den User. Hat mehrere Akzeptanzkriterien.
Atomare (=unteilbare) User Story Auch bekannt als „User Story“,
„Size S Story“
Etwas, das einen ersten Mehrwert für den User liefert. Die kleinste User Story liefert den kleinsten Wertzuwachs für den User.

Ein (1) Akzeptanzkriterium

Sub-Task [2] Auch bekannt als „Unteraufgabe“ Eine User Story besteht aus Unteraufgaben, die zur Umsetzung der User Story erledigt sein müssen. Beantwortet die Frage: Wie soll umgesetzt werden?

 

Diese Struktur passt auch zu dem Konzept von Jira: [3]

Abbildung Copyright © 2017 Atlassian

 

Daneben gibt es noch Tickets, die sich nicht unmittelbar in die Feature-Kaskade einreihen lassen, aber eine wichtigen Beitrag in der Produktentwicklung liefern. Hier würde ich auch alle Tätigkeiten auflisten, die zum Erreichen der Definition of Ready erfüllt sein müssen. Typischerweise finden sich hier Tätigkeiten, die „unter der Motorhaube“ stattfinden.

Task Auch bekannt als „Aufgabe“, „Technische Story“, „Developer Story“ z.B. Refactoring-Themen, Architektur-Themen, vorbereitende Tätigkeiten, Konzept, Design, Datenvorbereitung, Test-Themen

 

 


[1] https://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

[2] Wenn ich Jira verwende, wird die Story in den Issuetype „Sub-Task“ heruntergebrochen. Der Issuetype „Task“ wird verwendet, um andere Backlog-Items zu beschreiben (z.B. Explorationen, Vorarbeiten, Refactoring).

[3] https://www.atlassian.com/agile/delivery-vehicles

 

Teile diesen Beitrag mit deinen Freunden!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *