Jira Scrum Konfiguration: Epics, Komponenten, Releases

Eine gute Jira Scrum Konfiguration benötigen Sie für Ihr digital durchgeführtes Scrum Projekt mit Jira: In diesem Beitrag möchte ich Ihnen einen kleinen Einblick in eine Mögliche Konfiguration von der Komponenten und Versionen/Releases in Jira für Scrum vorstellen.

Lassen Sie uns zu Beginn kurz beleuchten, was Sie für ein Scrum Projekt brauchen und dann, wie wir diese Anforderungen in Jira umsetzen können. Bei allen Fragen und Wünschen rund um das Tool, dürfen Sie eines nicht vergessen:

Nehmen Sie nicht das Tool und lassen Sie sich einen Prozess aufzwängen. Sondern leben Sie Ihren Prozess, prüfen Sie was Sie benötigen und ermächtigen Sie das Team Entscheidungen zu treffen, die den Prozess verbessern können.

Doch auch hier gilt: Augen auf vor dem Toolkauf! Haben Sie Jira schon im Einsatz? Dann sollten Sie prüfen, ob Ihr Prozess wirklich durch den Bedarf diesen zu leben entstanden ist, oder ob gar das Tool diesen "aufzwingt". Wenn Sie noch kein Tool haben, dann prüfen Sie Ihren Prozess und schauen sich aufbauend darauf ein Tool an.

Um das Beispiel etwas anschaulicher zu machen, wollen wir uns einmal folgendes Szenario vorstellen. Wir gehen davon aus, dass wir ein Produkt haben, an dem mehrere Teams arbeiten. Dieses Produkt hat mehrere Bereiche oder Komponenten.

Sie können jedes Produkt aufteilen und es lassen sich so Komponenten finden. Diese Komponenten können dann auch die sein, die Jira kennt. Komponenten stellen damit ein Gruppierungselement dar, nach dem Sie auch Ihr Backlog sortieren können. Ein Vorgangstyp in Jira kann dabei mehrere Komponenten betreffen.

Da wir (auch in diesem Beispiel) leider nicht unbegrenztes Budget und Zeit haben, müssen wir über den Umfang des Projektes gehen. Das ist in agilen, wertgetrieben Vorgehen üblich und diesen Sachverhalt können Sie im Projektdreieck noch einmal nachvollziehen.

Der Grund, warum wir eine Planung und mögliche Daten für eine Auslieferung benötigen, ist meist der Kunde. Er möchte gerne wissen, wann er mit dem Produkt in Serie gehen kann, es auf einer Messe zeigen kann oder ähnliche Fragestellungen.

Kurz gesagt, irgendein Stakeholder in Ihrem Projekt möchte eine zeitliche Aussage bekommen und dann sind Sie an der Reihe so eine Aussage zu liefern.

Versionen und Releases sind weder in Scrum noch in Jira ein Problem und jeder, der in einem Projekt gearbeitet hat, ist mit diesen Begriffen vertraut. Wir wollen Sie kurz für den Rest des Artikels wie folgt benutzen

In Scrum sind Epics sind größere Initiativen, die nicht in einen Sprint passen. In Jira wird das Epic häufig nur als Gruppierungselement genutzt und dient damit als eine Art Container für Stories. Stories können einem Epic zugeordnet werden.

Ein Epic kann auch unter dauerndem Refinement verkleinert werden und sich dann irgendwann zu einer Story entwickeln. Am häufigsten begegnet mir aber die "Container-Variante" die Jira aktiv durch die Anzeige im Backlog auch unterstützt.

User Stories gibt es in Jira nicht, hier heißt diese Ebene schlicht "Story". Viele Kunden nutzen auch gar keine User Stories sondern arbeiten mit anderen Bezeichnungen, Formaten und Schreibweisen für diese Ebene. Eine User Story ist in Scrum nicht verpflichtend, bietet sich nur sehr oft als hilfreiches Werkzeug an.

Aufgaben ist das nächste, granularere Element. Es entspricht damit weitestgehend der Arbeit, dem "work", wie es sonst gerne bezeichnet wird. Üblicherweise werden solche Aufgaben in der Sprint Planung 2 erstellt oder aber bereits durch ein Team des Entwicklungsteam im Backlog ergänzt.

In Jira haben die Vorgangstypen gewisse Eigenschaften, die sich auf in Ihrem Scrum Projekt erfolgreich nutzen lassen. In diesem Artikel lege ich den Fokus auf die Komponenten und die Releases (Versionen).

In Jira können Komponenten genutzt werden, um bestimmte Teile des Systems zu adressieren. Das sieht je nach Architektur anders aus und wird ebenso von Team zu Team unterschiedlich gehandhabt.

Releases sind Versionen einer Software, die an den Kunden geliefert werden können oder öffentlich zur Verfügung stehen. 

Machen wir nun ein passendes Beispiel zu unseren Vorübergegangen und schauen uns dann ebenso die Umsetzung im Jira dafür an.

Wenn Sie mit mehreren Teams an einem Produkt arbeiten, können Sie Komponenten des Produktes erstellen. So wäre es eine Möglichkeit, dass ein Team an einer Komponente A arbeitet und ein anderes an der Komponente B.

In der Realität gibt es hier natürlich die unterschiedlichsten guten und weniger guten Ausprägungen dieser Komponenten. Ich kann hier nur empfehlen, dass so eine Teilung (wenn Sie denn nötig ist) wie oben beschrieben im Team durchgeführt wird.

Lassen Sie sich durch den Begriff der Komponente nicht verwirren. Das muss nicht bedeuten, dass Sie ein - im agilen Kontext weniger präferiertes - Komponententeam bevorzugen. 

Wählen Sie in Ihrem Jira Projekt den Bereich Komponenten aus und erstellen Sie die benötigten Komponenten. Im folgenden Beispiel sehen Sie den Ablauf. Beachten Sie bitte, dass es beispielhafte Werte sind. Im richtigen Umfeld würden Sie dann hier zum Beispiel "Shop-Suche" nutzen.

Ich sehe bei den Release in der Regel zwei unterschiedliche Varianten, wie verfahren wird. Meisten finden Unternehmen, die nicht in den echten Inkrement Gedanken pflegen sich in der ersten Aussage wieder.

Auch wenn ich persönlich zur zweiten Variante tendiere, muss im konkreten Fall betrachtet werden, was wirklich nützt. Wie ich Anfang schon beschrieben habe, sollten Prozesse immer die Individuen und Menschen unterstützen. Wenn Sie das reflektieren, dann haben haben eine gute Möglichkeit, Ihre Variante auszuwählen.

Weitere Details finden Sie in meinem Artikel zur Releaseplanung in Scrum.

Ein Sprint erzeugt in Scrum immer ein Inkrement. An diesem Inkrement und an Ihrem Sprint Backlog sehen Sie immer den aktuellen Fortschritt. Unterstützt durch ein Burndown haben Sie eine sehr gute Möglichkeit den Fortschritt zu verfolgen.

Jetzt gibt es durchaus die Möglichkeit, dass Ihre - Versionen und später dann - Releases (nehmen wir zum Beispiel das oben angesprochene MMF (Minimal Marketable Feature). Das könnte jetzt eine Kombination aus unterschiedlichen Anforderungen (z.B. User Stories) über verschiedene Teams hinweg sein.

Zudem haben Sie sehr wahrscheinlich auch nie alle Anforderungen in einem Sprint, die immer nur auf das eine Sprint Ziel einzahlen. Ein Release könnte zum Beispiel nach drei Sprints fertig sein, das dritte Inkrement ist dann (vgl. iterative und inkrementelle Entwicklung) das Release, zur Betrachtung (zum Fortschritt) zeigt das Release die Vervollständigung über die Sprints hinweg an. Das wird oft dann relevant, wenn mehrere Teams an so einem Release beteiligt sind.

Die Komponenten und Releases können (und müssen) aktiv im Jira eingetragen werden, damit Sie diese als Eigenschaften an den Vorgängen sehen können.