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.
Was brauchen Sie für ein Scrum Projekt?
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:
Agiles Manifest
Menschen und Interaktionen
mehr als
Prozesse und Werkzeuge
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.
Prozesse und Tools, die Menschen und Interaktionen unterstützen
Jira ist ein Tool und erfüllt keinen Selbstzweck. Während in früheren Versionen nach meiner Ansicht nach, das Tool noch diverse Probleme mit agile Frameworks wie Scrum hatte, ist es in der aktuellen Version deutlich besser geworden.
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.
Projekt und Produkt
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.
Hinweis Komponenten
Mit Komponenten können Sie ein Backlog kategorisieren. Sie können auf die Komponenten filtern und ebenso im (Sprint) Backlog anzeigen lassen.
Planung und Forecast
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.
Hinweis Planung
Egal welche Form oder Art der Planung Sie nutzen. Achten Sie immer darauf, dass die Planung immer von den Personen kommt, die auch die Arbeit tun. Das ist in der Regel immer das Entwicklungsteam.
Versionen und Releases
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
Sie können in der Angabe der Releases in Jira zum Beispiel gleich mit angeben, ob es sich um ein MVP, ein MMF oder ein Inkrement handelt. Da es in der Regel nur ein MVP gibt und nur ein MMF ist jedes Release damit ein Inkrement.
Wie in Scrum üblich, bedeutet das nicht, dass der Product Owner dieses releasen muss. Er entscheidet, ob diese dieses Release an den Kunden geht (und oft gehen nicht alle Releases an den Kunden).
In Jira wird jede Version, die veröffentlicht wird, zu einem Release. Wenn Sie eine Version in der entsprechenden Projektmaske veröffentlichen, dann können Sie weitere Daten zu Ihrem Release angeben und finden dann folgende Maske zur Durchführung.
Bestätigen Sie dann die Eingabe, dann haben Sie Ihr erstes Release erstellt und Sie haben eine Verbindung von Anforderungen zu einem Release hergestellt.
Vorgangstypen in Jira
In Jira gibt es sogenannte Vorgangstypen. Diese entsprechen weitestgehend dem typischen Aufbau von Epic, User Story und Task.
Jeder dieser Vorgangstypen hat ein kleines Icon, das die visuelle Einordnung schnell ermöglicht.
Epics
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.
Stories
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
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.
Eigenschaften von Vorgängen in Jira
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).
Komponenten
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
Releases sind Versionen einer Software, die an den Kunden geliefert werden können oder öffentlich zur Verfügung stehen.
Ihre Jira Scrum Konfiguration
Machen wir nun ein passendes Beispiel zu unseren Vorübergegangen und schauen uns dann ebenso die Umsetzung im Jira dafür an.
Definieren Sie Ihre Komponenten des Produktes
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.
Hinweis zu Teamaufteilungen
Oft geht mit der Bestimmung von Komponenten der Wunsch einer Teamteilung einher. Wenn das bei Ihnen ebenso der Fall ist, überlegen Sie bitte immer, ob diese Aufteilung direkt auch das Entwicklungsteam erfolgende sollte.
Ein häufiges Problem tritt auf, wenn durch das Management ein Team festgelegt wird, dass an einer Komponente arbeiten soll. Das Entwicklungsteam entwickelt den Mehrwert für den Kunden und hat dadurch (und durch den Expertenstatus) in der Regel die bessere Sicht auf eine mögliche Teilung des Teams.
Idealerweise sind dann die Komponenten so, dass die Product Backlog Items durch Teams als Feature Teams der Komponente umgesetzt werden können.
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.
Komponenten != Komponententeam
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. So könnte eine solche Komponente des Produktes bei einem Onlinehändler die komplette Suche (von der UI bis zur Datenbank) sein.
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.
Tragen Sie Ihre Komponenten im Jira ein
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.
Legen Sie die Releases fest
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.
Jira Scrum Konfiguration in der Praxis
In diesem letzten Abschnitt wollen wir uns noch kurz damit beschäftigen, wie diese Jira Scrum Konfiguration auf Ihre Fortschritts- und Analysemöglichkeiten zum Produkt einzahlt.
Fortschritt anhand der Version erkennen
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.
Sichtbarkeit des Backlogs für Teams
Arbeiten mehrere Teams an einem Produkt, dann können die entsprechenden Komponenten so gefiltert werden, dass eine bessere Übersicht über das Product Backlog vorhanden ist. Gerade für die Filtermöglichkeiten im Jira ist das ein nicht zu unterschätzendes Element in Ihrer Konfiguration for das Projekt.
Eingabe der Komponenten und Versionen
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.
Versionen -> Releases
Während der Entwicklung Ihres Produktes arbeiten Sie mit Versionen. Ist die Version für eine Veröffentlichung bestimmt, dann wird aus dieser Version ein Release.
Im Ticket direkt können Sie die Version eintragen. Die Version kann dann später bei der Veröffentlichung zu einem Release werden.
Komponenten
Komponenten können Sie schnell und bequem bei der Anlage oder Sichtung im Backlog einem Ticket hinzufügen.
Jedes Ticket erlaubt die Angabe der Komponenten, von denen mehrere angegeben werden können.