Folge 92: Epics, User Stories, Tasks und andere Vorgangstypen

Auch in dieser Folge widmen wir uns einem Hörervorschlag. Themole wollte wissen, welche Vorgangstypen es denn eigentlich gibt und welche sinnvoll sind. Dabei müssen wir zuallererst mit einiger Verwirrung aufräumen, die es – wohl auch gerade dank JIRA – rund um die Begriffe Epics, User Stories, Tasks, Subtasks und anderer solcher „Vorgangstypen“ gibt. Wir lösen uns dabei von JIRA und schauen, welche Begriffe denn überhaupt gängig sind und was sie üblicherweise bedeuten und was wir darunter verstehen.

Abschließend widmen wir uns auch der Frage, wie und wann diese unterschiedlichen Einheiten überhaupt entstehen und zum Einsatz kommen und, was wir glauben, warum sich Thomale mit dieser Unterteilung in seinem Projekt im Embedded Systems Umfeld schwer tut.

Kurzer Hinweis in eigener Sache: Wir mussten die Folge aufgrund einer Unterbrechung in zwei Teilen aufnehmen und reißen in dem Zusammenhang auch kurz das Thema an, wie man eigentlich als Moderator mit Störungen und Unterbrechungen umgeht.

Picks

Sounds

Beitragsbild von Jacopo Romei, Published under CC BY-SA 2.0

Ein Gedanke zu „Folge 92: Epics, User Stories, Tasks und andere Vorgangstypen“

  1. Hi zusammen,

    wir verwenden in unserem Jita das Tool „Portfolio for Jira“, das eine neue Ebene mit dem Vorgangstyp „Initiative“ einführt. Dieser Vorgangstyp entspricht vermutlich eurem „Theme“. Unsere Hierarchie ist dann Initiative – > Epic – > User Story/Task.

    Eine Initiative kann auch Produktteamübergreifend sein, da man ihr Epics aus verschiedenen Produktteams (bei uns pro Produktteams ein eigenes Jira-Projekt) Epics zuordnen kann. Das klappt bei uns recht gut, um große (ggf. Produktteamübergreifende) Themen anzulegen und die bricht dann jedes Betroffene Produktteams für sich in Epics und diese dann in User Stories runter.
    Für die Zeitplanung kann man in Portfolio dann auch einen Zeitplan erstellen, auf dem die Initiativen, Epics usw drauf stehen, man kann die Abhängigkeiten zwischen ihnen abbilden und auch die Release Termine reinpacken. Wenn man seine Vorgänge sauber pflegt, hat man damit in Echtzeit gleich ein Reporting dabei, das man auf oberer Managementebene zeigen kann, da es den agilen Ansatz dann etwas abstrahiert und die heißgeliebte Planungssicht anzeigt.

    Viele Grüße
    Markus

Schreibe einen Kommentar

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