Sobald ein Softwareteam das vertraute Terrain von Wasserfall- oder anderen herkömmlichen Projektmanagementverfahren verlässt, steht es vor dem Problem, wie die Arbeit strukturiert werden soll. Zum Glück bietet die agile Entwicklung vier klare Bereitstellungsinstrumente, die für Struktur in jedem agilen Projekt sorgen: Epics, User Storys, Versionen und Sprints:

Epic
Große Aufgabeneinheit, die Storys beinhaltet
Story
Kleinste Arbeitseinheit, auch Aufgabe genannt
Version
Der Release von Software an den Kunden
Sprint
Iteration in Teamarbeit

Mithilfe dieser Instrumente können Softwareteams ihre Arbeit so strukturieren und in machbare Einheiten unterteilen, dass sie Kundenfeedback priorisieren und den ursprünglichen Plan ändern können, ohne das Gefühl zu haben, dass um sie herum alles zusammenbricht.

Die Möglichkeit, zukünftige Planungen auf der Basis aktueller Einblicke zu ändern und anzupassen, ist eins der Kennzeichen der Agilität. In diesem Artikel definieren wir diese vier Bereitstellungsinstrumente und zeigen dir, wie sie gemeinsam bei deinen Aufgaben für Struktur sorgen. Sprechen wir aber zunächst über den Unterschied zwischen den einzelnen Bereitstellungsinstrumenten.

Epic vs. Story

Epics sind größere Aufgabeneinheiten, die aus den einzelnen Storys entstehen. Ein Epic kann mehrere Sprints und Versionen umfassen. Versionen unterscheiden sich von Epics, da sie einen Zeitpunkt abbilden, an dem die Software an den Kunden ausgeliefert wird. Eine Version kann mehrere Epics enthalten. Epics helfen Teams dabei, eine Hierarchie und Struktur zu erstellen. Storys helfen Teams dabei, bestimmte Details der jeweiligen Aufgabe zu verfolgen, und sie können in untergeordnete Aufgaben weiter unterteilt werden.

Epic vs. Storys – Strukturierung deines agilen Projekts

Die Aufgaben in dem obigen Diagramm könnten für eine Version ausgewählt werden, die während einem oder mehreren Sprints abgeschlossen wird.

Initiative finden auf der Portfolioebene statt. Dies ist wichtig, hier hervorzuheben, damit du sehen kannst, dass Epic in der Regel zu stärker strategischen Zielen oder Initiativen zusammenlaufen. Du kannst diese Initiativen während deiner langfristigen Planung entwickeln und dies in einem Tool wie Portfolio for Jira festhalten.

Was ist ein Epic?

Ein Epic ist eine größere Aufgabeneinheit, die in mehrere kleinere Storys unterteilt werden kann, wie zum Beispiel Aufgaben im Zusammenhang mit der Performance in einem Release. Ein Epic kann mehr als ein Projekt umfassen, wenn mehrere Projekte im Board des Epics enthalten sind. 

Im Gegensatz zu Sprints sind Änderungen des Umfangs in Epics im Laufe der Zeit ein selbstverständlicher Aspekt der agilen Entwicklung. Epics werden fast immer über einen Satz von Sprints bereitgestellt. Wenn ein Team durch Entwicklungs- und Kundenfeedback mehr über ein Epic lernt, werden User Storys hinzugefügt und entfernt, um die Release-Zeit des Teams zu optimieren.

Beispiel für ein Epic

Je nachdem, welches agile Framework du verwendest (Scrum, Kanban oder deine ganz eigene Methode), können agile Epics auf verschiedene Weise genutzt werden.

Bei Kanban können Epics als Swimlanes zur Segmentierung verschiedener Arbeitsströme genutzt werden. Wenn du Scrum verwendest, können Epics bei der Benennung der Aufgaben in deinen Sprints helfen, wie du im unten stehenden Beispiel sehen kannst. "Mission to Mars" ist ein Epic in diesem Sprint. TIS 1, TIS 2 usw. sind User Storys in diesem Sprint (TIS Sprint 1). Es befinden sich also mehrere User Storys und Epics in diesem einen Sprint.

 

Möchtest du das Ganze mal ausprobieren? Registriere dich oder logge dich in Jira Software ein >>

Wähle den Projekttyp (Scrum oder Kanban) und befolge eines dieser Tutorials zum Einstieg in das Set-up von Epics:

Messen deiner Epics

Burndown-Charts können auch für die Visualisierung von Epics verwendet werden. Sie sorgen dafür, dass Teams motiviert und Stakeholder der Unternehmensführung informiert bleiben. In einem guten Epic-Burndown-Chart wird die agile Beschaffenheit der Entwicklung widergespiegelt. Der Fortschritt des Teams ist klar erkennbar, ebenso an welchen Stellen der Product Owner User Storys hinzugefügt oder entfernt hat. Durch diese deutlich erkennbaren Datenpunkte bleiben alle auf demselben Stand. Zudem werden Gespräche über die Weiterentwicklung des Produkts und Abschlussprognosen vereinfacht. Ganz zu schweigen davon, dass Transparenz Vertrauen schafft!

Profitipp: Feature-"Flags" (oder "Toggles") können ein effektives Mittel für die Entwicklung größerer Epics darstellen, weil neuer Code während der Entwicklung hinter einem Ein-/Aus-Schalter versteckt werden kann. Durch das Feature-Flagging kann ein Entwicklerteam den Code für ein Epic ausliefern und ihn in die Produktionsanwendung aufnehmen, ihn aber erst nach der vollständigen Implementierung sichtbar machen. (Mehr dazu erfährst du in unserem Artikel zu Feature Branching.) 

Was ist eine User Story?

Eine Story oder User Story ist in einem agilen Framework die kleinste Aufgabeneinheit. Sie ist eine Softwaresystemanforderung, die in wenigen kurzen Sätzen ausgedrückt wird, idealerweise in nicht-technischer Sprache.

Ziel einer User Story ist, dem Kunden einen bestimmten Wert zu liefern. "Kunde" muss hier nicht der externe Endbenutzer im herkömmlichen Sinn sein. Es kann sich auch um interne Kunden oder Kollegen in deinem Unternehmen handeln, die von deinem Team abhängig sind.

User Storys werden mit einigen Sätzen in einfacher Sprache verfasst, in denen das gewünschte Ergebnis beschrieben ist. Die Anforderungen müssen nicht detailliert ausgeführt werden.

Beispiel für eine User Story

User Storys werden vom Product Owner grob skizziert. Die ausführlicheren Anforderungen werden dann vom gesamten Produktteam gemeinsam entschieden. Mit diesen granularen Aufgabeneinheiten können die Implementierungselemente für die Story und den anstehenden Sprint definiert werden.

In einer Story befindet sich eine Reihe erforderlicher Aufgaben. Diese Aufgaben sollten während der Schätzung der User Story ausgearbeitet und im Issue Tracker des Teams verlinkt werden. 

Im selben Beispiel wie oben sehen wir die Schätzungen, Prioritäten, Zuweisungen, Epics und Beschreibungen der Storys in diesem Sprint, sodass jeder einen schnellen Überblick über die anstehenden Aufgaben erhält.

Weiterführende Informationen: Decomposing User Stories

Agile ist neu für dich? Erstelle anhand dieses interaktiven Tutorials ein agiles Projekt.>>

Was ist eine Version?

Versionen sind die tatsächlichen Releases von Software an Kunden. Du erinnerst dich, dass das Team am Ende jedes Sprints Software an Kunden ausliefern können sollte. Versionen sind die durchgeführten Änderungen, die der Product Owner tatsächlich ausliefert.

Versionen werden oft über einen Satz von Sprints entwickelt, ähnlich wie Epics. Erfahrene Product Owner entscheiden möglicherweise, ein Epic über mehrere Versionen bereitzustellen. Ein Epic muss nicht komplett in einer Version enthalten sein. Wenn ein Epic über mehrere Versionen bereitgestellt wird, kann der Product Owner ermitteln, wie der Markt auf das Epic reagiert. Statt ein gigantisches Release herauszubringen, kann er zunächst gut kalkulierte Entscheidungen über die zukünftige Ausrichtung treffen.

Beispiel für eine Version

Ein Product Owner kann die Release-Strategie wie folgt strukturieren:

  • Version 1: Anmeldung, Abmeldung, Kennwortverwaltung
  • Version 2: Kaufverlauf
  • Version 3: Speichern von Einstellungen
  • usw.

Änderungen des Versionsumfangs sind ebenfalls ein selbstverständlicher Teil der agilen Entwicklung. Burndown-Charts halten das gesamte Team über die Weiterentwicklung einer Version über die Zeit auf dem Laufenden. Änderungen an einer Version sollten mit dem gesamten Team besprochen werden, damit alle auf demselben Stand bleiben.

Möchtest du das Ganze mal ausprobieren? Registriere dich oder logge dich in Jira Software ein >>

Was ist ein Sprint?

Ein Sprint ist ein kurzer Zeitraum, in dem das Entwicklerteam eine einzelne potenziell auslieferbare Anwendungsverbesserung, z. B. eine funktionierende Meilensteinversion, implementiert und liefert. Wenn du Sprints bisher noch nie angewendet hast, empfehlen wir eine feste Dauer von zwei Wochen pro Sprint. Das ist lange genug, um etwas zu erreichen, aber auch so überschaubar, dass das Team regelmäßiges Feedback erhalten kann.

Hinweis: Sprints gehören nur zum Scrum-Framework. Kanban-Teams bearbeiten dagegen das nächste Element des Backlogs, sobald ihre Kapazität dies zulässt. Es sind keine Prognosen erforderlich. 

In Scrum schließen Teams einen Satz von User Storys innerhalb eines festen Zeitraums ab. Im Allgemeinen sind Sprints ein, zwei oder vier Wochen lang. Die Länge eines Sprints wird vom Team festgelegt. Nachdem ein Sprint-Rhythmus festgelegt ist, hält das Team diesen Rhythmus beständig ein. Sprints mit fester Länge ermöglichen eine bessere Schätzungskompetenz und Prognose der zukünftigen Velocity des Teams, sobald Daten von mehreren abgeschlossenen Sprints vorliegen.

Beispiel für einen Sprint

Hier noch einmal dasselbe Beispiel wie oben: Der abgebildete Sprint TIS Sprint 1 ist eine Sammlung von User Storys.

Was du über Sprints wissen solltest:

  • Nachdem ein Team einen Satz von User Storys für den Sprint beschlossen hat und der Sprint gestartet wurde, liegt es in der Verantwortung des Scrum Masters, Änderungen an den User Storys abzuwehren. Dann bleibt das Team konzentriert und "Scope Creep" wird vermieden (Hinzufügen weiterer Aufgaben nach dem Starten eines Sprints). Das Team kann keine präzisen Prognosen und Schätzungen erstellen, wenn mitten in einem Sprint weitere Aufgaben hinzugefügt werden.
  • Am Ende jedes Sprints muss das Team eine funktionierende Softwarekomponente liefern. In Scrum wird das als PSI (Potentially Shippable Increment) bezeichnet. Letztendlich entscheidet der Product Owner, wann das PSI an Kunden released wird, die Arbeit sollte jedoch entsprechend abgeschlossen sein, damit am Ende des Sprints ein Release möglich ist.

Messen deiner Sprints

Ein großartiges Tool für jedes Scrum-Team sind Burndown-Charts. In diesen Diagrammen wird während des Sprints der Fortschritt der "verbleibenden Aufgaben" auf der y-Achse und die "Zeit" auf der x-Achse umfassend nachverfolgt. Burndown-Charts sind eine wirkungsvolle Motivation für das Team und sorgen während eines Sprints für Konzentration. Vor allem aber bieten Burndown-Charts unterstützende Daten für Gespräche über den Fortschritt eines Sprints. 

Skalierung

In größeren Unternehmen arbeiten oft mehrere agile Teams an einem gemeinsamen Programm und die Portfolioplanung ist ein wichtiger Teil der Ausführung agiler Methoden in einem großen Maßstab. Epics und Versionen bilden die Grundlage für ein robustes agiles Portfoliomanagement auf der Teamebene. Das agile Portfoliomanagement umfasst die Nachverfolgung von Programmen in mehreren Teams bei gleichzeitiger Aufrechterhaltung desselben Agilitätslevels in höheren Unternehmensebenen. Mehr über agile Methoden in einem großen Maßstab erfährst du im Abschnitt Agiles Portfolio

Dargestelltes Produkt
Jira Software-Logo
Projekt- und Vorgangsnachverfolgung