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.
Ursprung
|
Ziel
|
Stichwort
|
Wer macht Was ? |
---|---|---|---|
Neu | Backlog | + RED-Backlog | Der PO prüft alle neuen Tickets und verschiebt diese ins Backlog. |
Backlog | Refinement | + RED-Refinement | PO und TL bereiten im Rahmen der Backlog Pflege das Refinement Meeting vor und verschieben ausgewählte, kurzfristig relevante Tickets ins Refinement. Der Refinement Bereich soll nach jedem Meeting wieder aufgeräumt werden. |
Refinement | DoR | + RED-DoR
– RED-Refinement |
Das Entwickler Team übernimmt alle vollständig geschätzten und geklärten Tickets in das Sprint Backlog. Aus diesem werden die folgenden Sprints im Planning Meeting befüllt. |
Refinement | Refinement | + RED-Question | Sollte das Entwickler Team ein Ticket nicht schätzen können, wird dies zur Klärung zurückgestellt und markiert. |
Refinement | Backlog | – RED-Refinement | PO und TL räumen im Anschluss an das Refinement Meeting den Bereich wieder auf und versuchen die offenen Fragen zu klären |
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.
Board
|
Beschreibung
|
---|---|
Ideenspeicher | Das Board zeigt alle Tickets, die im gesamten Projekt existieren. Es kann über Filter eingeschränkt werden. |
Refinement | Es werden nur die zu besprechenden Refinement Tickets angezeigt. |
SCRUM Board | Es werden nur die aktuell geplanten Sprints angezeigt und alle Tickets, die reif für die Umsetzung sind. |
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.
Filter
|
Regel
|
Zweck
|
---|---|---|
Neu | Label not in (Backlog) | Zeigt alle neuen Tickets, die noch nicht geprüft wurden |
Idee | Label not in (Refinement, DoR) | Zeigt nur Ideen, die noch nicht zur Umsetzung ausgewählt worden sind |
Frage | Label = Question | Zeigt alle Tickets mit offenen Fragen |
Refinement | Label = Refinement | Zeigt nur Tickets, die für das Refinement vorgesehen sind |
DoR | Label = DoR | Zeigt alle Tickets im Sprint Backlog |
Offen | Status = Open | Zeigt alle offenen Tickets |
In Work | Status != Open | Zeigt alle nicht offenen Tickets |
!Sprint | Sprint != OpenSprint() | Blendet alle Tickets aus, die einem Sprint zugeordnet sind |
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.
Farbe | Filter | Beschreibung |
---|---|---|
orange | (labels not in RED-Backlog) or labels is Empty | Neue Tickets |
rot | labels = RED-Question | Tickets mit Rückfragen aus dem Team |
blau | labels = RED-Refinement | Tickets, die im Refinement Board für das nächste Refinement anstehen |
grün | labels in (RED-DoR) | Tickets, die reif für die Umsetzung sind |
Senior IT Analyst
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.