1. Einleitung

Die Software Entwicklung bei Thalia ist agil und wird von mehreren Teams per SCRUM durchgeführt. Zur generellen Verwaltung der einzelnen Aufgaben wird in der gesamten IT das Ticketsystem JIRA von Atlassian verwendet. Dieser Artikel soll einige Erfahrungen aus einem unserer Teams weitergeben, wie sich der SCRUM Alltag mit Hilfe von JIRA organisieren lässt. Er richtet sich dabei vor allem an Anwender, die bereits erste Erfahrungen mit SCRUM und JIRA haben.

Im folgenden sind einige Anregungen, wie ein SCRUM Team Daily Meetings digital abhalten kann, der PO beim Planning durch JIRA unterstützt wird bzw. die Durchführung der Meetings organisiert werden kann.

2. Daily

Für die Dailys verwendet das Team das Standard JIRA SCRUM-Board mit der Ansicht des aktiven Sprints. Dieses wird auf einem großen 40″ Monitor dargestellt. Die einzelnen Team-Mitglieder können das Board während des Meetings direkt per Trackpad bedienen.

Vorteile:

• Das digitale Board wird den ganzen Tag angezeigt und gibt damit einen permanenten Überblick
• Einfache Zusammenarbeit
  • Tickets können während der Arbeit vom Platz aktualisiert werden.
  • Standortübergreifende Teams haben ein einheitlichen Blick auf das Board. Das war vorher bei der Verwendung von Pinnwänden schwierig.
  • Flexible Zusammenarbeit auch bei Teammitgliedern im HomeOffice
• Interaktion im Daily bleibt erhalten
  • Das Trackpad wird als „Staffelstab“ an den jeweiligen Redner übergeben
  • Tickets können schnell und einfach direkt während des Daily in andere Statusspalten geschoben werden.
  • Tickets können schnell und einfach direkt während des Daily anderen Personen zugewiesen werden.

3. Planung

Bei Thalia hat jedes Entwickler-Team sein eigenes JIRA-Projekt. Die Planung für unser Team erfolgt daher innerhalb unseres eigenen Projekts und dem dort zur Verfügung gestellten Backlog. In diesem werden die Tickets des Teams erfasst und verwaltet.

Grundsätzlich lässt sich mit dem Backlog und einzelnen Sprints mit JIRA ohne weitere Veränderung arbeiten. In der alltäglichen Arbeit zeigt sich aber, das die Bedürfnisse von PO und SCRUM Team in einigen Punkten abweichen und die Arbeit durch kleine Anpassungen erleichtert werden kann.

Das Backlog wird im Laufe der Zeit mit verschiedensten Tickets befüllt, die ab einer bestimmten Menge das SCRUM Team überfordern können. Es geht der Überblick verloren, welche noch aktuell sind oder eventuell neu geschätzt werden müssen. Daher ist eine weitere Unterteilung unter Umständen hilfreich.

3.1 Stadien eines Tickets

Eine genauere Betrachtung der Tickets zeigt, dass diese während ihrer Lebenszeit verschiedene Stadien durchlaufen. Hierbei wird deutlich, dass es unterschiedliche Standpunkte bzw. Schwerpunkte gibt, was genau der Status eines Tickets ist.

Aus Sicht des Teams

Das Team hat vor allem die Bearbeitung des Tickets im Blick. Am Anfang ist das Ticket noch Offen und wird dann Bearbeitet. Von dort wandert es über ein Review in den Test bis es nach einer Abnahme geschlossen werden kann.

Bearbeitung: Offen > In Bearbeitung > [Review] > Test > [Abnahme] > Geschlossen

Aus Sicht des PO

Die Arbeit des PO fängt bereits lange vor der Bearbeitung durch das Team an. Es kommen neue Tickets ins Backlog, die eventuell auch von außerhalb des Teams kommen können und daher als Neu kenntlich sein müssen. Diese können ins Backlog aufgenommen oder abgelehnt bzw. verändert werden. Alle Tickets, die im Backlog sind, müssen zur Feinplanung an das Team gegeben werden und geschätzt werden. Dabei können sie als Sprint tauglich (Definition of Ready erfüllt) bewertet werden. Alle Tickets, die den DoR-Status haben, stehen damit für einen nächsten Sprint zur Verfügung.

Planung: Neu > Ins Backlog aufgenommen > Feinplanung > Sprint Tauglich > In Sprint übernommen.

Zwischenfazit

Es gibt also zwei Ebenen, die Bearbeitung und die Planung. Da Tickets aus einem laufenden Sprint auch wieder ins Backlog wandern können, existieren unter Umständen Tickets im Backlog, die bereits bearbeitet wurden und einen entsprechenden Status haben. Das zeigt, dass diese beiden Zustandstypen parallel existieren können. Daher haben wir uns dafür entschieden, die Planungszustände nicht über den Status abzubilden, sondern als parallelen Zustand zu implementieren.

Im Folgenden wird daher gezeigt wie sich mit einfachen Mitteln in JIRA diese beiden Stränge parallel verwalten lassen.

3.2 Organisation

Die Organisation der Tickets findet in einem einzigen Projekt Backlog statt. In diesem Backlog erfolgt die Zuordnung zu den einzelnen Phasen der Bearbeitung über den Ticket Status. Die Zuordnung zu den einzelnen Phasen der Planung erfolgt durch Stichwörter.

Eine Aufteilung kann recht einfach durch „virtuelle Trennlinen“  in Form von Tickets mit Titeln wie „=======“ visualisiert bzw. organisiert werden. Da JIRA aber einige Eigenheiten beim Sortieren von Tickets aufweist, können sich schnell Tickets in andere Bereiche schummeln. Durch die Verwendung von Stichwörtern lässt sich das vermeiden.

Stichwörter

Das Backlog wird durch die Stichwörter in einzelne Planungsphasen aufgeteilt. Diese helfen bei der Organisation und unterstützen die zielgerichtete Vorbereitung der Scrum Meetings.

3.3 Boards

Für die alltägliche Arbeit stehen mehrere Boards zur Verfügung. Das Entwickler-Team nutzt dabei für die tägliche Arbeit nur das SCRUM Board, während der PO überwiegend im Ideenspeicher unterwegs ist. Als Schnittstelle zwischen beiden dient das Refinement Board.

 3.4 Kleine Helfer im Alltag

Filter

Vor allem der PO steht vor der Herausforderung das Board stets aktuell zu halten, das Team mit priorisierten Aufgaben zu versorgen und einen Überblick über neue und abgeschlossene Tickets zu behalten. Das führt zu häufigen Wechseln zwischen Planung und Sprint Übersicht.

Um das zu vereinfachen, haben wir im Ideenspeicher-Board eine Reihe von Filtern eingerichtet, durch die es je nach Bedarf weiter eingeschränkt werden kann. Dadurch kann die Sichtbarkeit in den einzelnen Boards geprüft werden, ohne dass die Boards gewechselt werden müssen.

Farbkennzeichnung der Tickets

Ein weiterer Aspekt hat sich in der Sichtbarkeit des Planungsstandes der Tickets gezeigt. Für den PO ist es wichtig zu wissen, welche Tickets beim Team liegen, neu sind oder wo noch Fragen offen sind. Um dafür nicht jedes Mal die Filter benutzen zu müssen, lässt sich der Status auch als Farbkennzeichnung realisieren.

Jens Zech

Senior IT Analyst
Thalia Bücher GmbH

Team Leiter des Teams RED - Redaktionelle Dienste. Ich bin seit mehr als 20 Jahren in der Software Entwicklung tätig . Zusammen mit meinem Team bilden wir eines der OmniChannelService Teams.

Keine weiteren Artikel