Fast jeder kennt Jira. Als reines Ticketsystem aus der Ursuppe rund um Bugzilla entsprungen, hat es sich in den letzten Jahren spätestens seit der Zusammenführung von Jira und Jira Agile (Greenhopper) zu Jira Software zum Standardwerkzeug vieler agiler Teams etabliert.
Man legt fleißig Tickets an und organisiert seine Projekte wahlweise über agile Boards für Scrum oder Kanban. Jira beherrscht ausgeklügelte Reports zur Auswertung von Sprints oder des Kanban-Workflows. Und mit Tempo für Jira – das wir auch hier bei Mayflower verwenden – erhält man ein mächtiges Plugin, um auf Basis von Tickets Arbeits- und Projektzeiten zu tracken, Ressourcen zu planen oder sogar Kostenkontrolle zu betreiben.
Lobeshymne!
Eine Lobeshymne auf Jira und seine Plugins? Nicht ganz. Wie jedes andere Tool da draußen hat auch Jira Schwachstellen. Sucht man nach passenden Lösungen, findet man oft nie umgesetzte Feature Requests aus vergangenen Jahren mit vielen hundert Befürwortern. Also wird man gezwungenermaßen kreativ und entwickelt über die Zeit Tricks und Kniffe, die die Organisation des Jira-Backlogs vereinfachen sollen.
Genau diese Tricks und Kniffe aus unserem Alltag möchte ich euch hier verraten, damit auch ihr die Organisation eures Jira-Backlogs vereinfachen könnt.
1. Trenner-Tickets im Backlog
Je weiter oben Tickets im Backlog sind, umso schärfer sind sie. Tickets die an oberster Stelle im Backlog stehen, sollten die Definition of Ready erfüllen und sind bereit, um in Kürze bearbeitet zu werden.
Dennoch wünscht man sich als Product Owner oft eine granulare Aufteilung des Backlogs. Beispielsweise, um Tickets zusammenzufassen, die als nächstes im Refinement besprochen werden sollen, die besonders wichtig sind oder die man für später aufheben möchte, weil sie aktuell keine Priorität haben. Hierfür kann man sich Trenner-Tickets anlegen, die die entsprechende Bereiche im Backlog eingrenzen.
Es bietet sich an, die Ticket-Titel mit Pfeilen und ähnlichen Unicode-Zeichen zu versehen. Dadurch ergibt sich die Lese-Richtung und sie springen in der Masse von Tickets im Backlog sofort ins Auge.
2. Unicode-Zeichen zum Markieren von Tickets
Apropos Unicode-Zeichen: Jira bietet von Haus aus einige Möglichkeiten an, Tickets im Backlog hervorzuheben. Dies gelingt zum Beispiel über die Ticket-Priorität, Labels oder Zuweisungen zu einem Epic. Genügt das nicht, kann man zusätzlich beliebige Unicode-Zeichen in den Ticket-Titel einfügen, um sie hervorzuheben.
Das klingt im ersten Augenblick banal. Allerdings verwenden wir in einigen unserer Projekte ein Ampel-System für jedes einzelne Ticket, um sichtbar zu machen, ob sich die Tickets noch in ihrer ursprünglichen Schätzung befinden bzw. ob während der Entwicklung unbekannte Risiken entdeckt wurden, die in größere Runde besprochen werden sollten.
Bei einem grünen Herz ist alles in Ordnung, bei einem gelben Herz gibt es kleinere Hindernisse, bei einem roten gebrochenen Herz gibt es große Hindernisse, die den Gesamtfortschritt gefährden. Super praktisch und sehr übersichtlich. Natürlich sind der Kreativität keine Grenzen gesetzt, individuelle Markierungen über ein Unicode-Zeichen sichtbar zu machen. Eine gute Anlaufstelle ist emojipedia.org, um geeignete Zeichen zu finden.
3. Unübliche Schätzgrößen im Ticket-Titel
Generell bietet sich der Ticket-Titel aufgrund seiner prominenten Sichtbarkeit im Backlog an, um zusätzliche Informationen darzustellen. Jira kann in der Scrum-Ansicht des Backlogs Story Points nur als Zahl in einem kleinen grauen Kasten darstellen. Verwendet man eher unübliche Schätzgrößen wie zum Beispiel eine Drei-Punkt-Schätzung oder T-Shirt-Sizes, kann man sie nicht im Estimation-Field eintragen, da es nur numerische Werte akzeptiert. Stattdessen kann man die Schätzung in eckigen Klammern an das Ende des Ticket-Titels notieren.
- Drei-Punkt-Schätzung: Dies ist der Ticket-Titel [1-2-3]
- T-Shirt-Sizes: Dies ist der Ticket-Titel [XXL]
Die Kanban-Ansicht in Jira kennt keinerlei Schätzgrößen – die Kern-Metrik in Kanban ist die Lead- und Cycle-Time. Natürlich spricht nichts dagegen, auch in Kanban Tickets zu schätzen; möchte man das tun, kann man auch hier Schätzungen im Ticket-Titel eintragen und sichtbar machen.
4. Komplette Tickets drucken
Man mag es kaum glauben, aber Jira bietet in der Standardkonfiguration keine Möglichkeit an, mehrere Tickets samt deren kompletten Inhalts zu drucken – analog zur Webansicht, wenn man ein einzelnes Ticket betrachtet. Man könnte nun jedes einzelne Ticket im Browser öffnen und den Fensterinhalt drucken. Der damit verbundene manuelle Aufwand bei sehr vielen Tickets steht aber in keinem Verhältnis.
Über die Ticketsuche kann man stattdessen nach den gewünschten Tickets suchen. In der Ergebnisansicht befindet sich ein Button Export, der unterschiedliche Export-Möglichkeiten bietet.
Wider Erwarten versteckt sich der gewünschte Inhalt nicht hinter Printable (liefert nur eine einfache Liste der gefundenen Tickets), sondern hinter Full Content. Hier werden alle gefunden Tickets mit ihrem kompletten Inhalt ausgegeben.
Die Tickets sind mit einer horizontalen Linie voneinander getrennt. Um diese Liste druckbar zu machen, muss man die Entwickler-Tools seines Browsers bemühen, die horizontale Linie auswählen (hr class=fullcontent) und an ihren CSS-Eigenschaften page-break-after: always; ergänzen.
Auch wenn es etwas Bastelei ist, überzeugt das Ergebnis: Druckt man die Ansicht nun aus, landet der gesamte Ticket-Inhalt sauber auf einer Seite. Bei sehr langen Tickets empfiehlt es sich, auf Vorder- und Rückseite zu drucken.
Um Papier zu sparen und die Umwelt zu schonen, sollte man bei großen Mengen zu druckender Tickets als Format A5 wählen.
5. Weniger ist mehr
Falls sich jemand fragt, warum man so viele Tickets überhaupt ausdrucken möchte, hier ein möglicher Anwendungsfall: Zum gemeinsamen Ausmisten.
Gerade in langlebigen Projekten sammeln sich über die Zeit hunderte oder gar tausende Tickets im Backlog. Irgendwann ist der Punkt erreicht, an dem die Übersicht verloren geht und man bei vielen Tickets gar nicht mehr weiß, was einem der Autor damit eigentlich sagen wollte. Hier empfiehlt es sich, die betroffenen Tickets auszudrucken, auf einem großen Tisch auszulegen und mit dem gesamten Entwickler-Team sowie allen Stakeholdern ähnlich wie beim Magic Estimation Game gemeinsam pro Ticket zu entscheiden, ob es weg kann oder im Backlog verbleiben darf.
Erfahrungsgemäß verschwinden hierbei sehr viele Tickets in der Bedeutungslosigkeit. Bei einem sehr großen Stapel an Tickets und einer ausreichend großen Anzahl an Teilnehmern kann man den Stapel auch aufteilen und von Gruppen bearbeiten lassen. So lässt sich der Backlog in kürzester Zeit aufräumen – er sollte nicht mehr als 100 Tickets enthalten.
Und ihr?
Das waren die Kniffe, die wir uns über die Zeit erarbeitet haben und die wir in unseren Projekten gerne anwenden. Welche Tricks nutzt ihr, um euch die Organisation eures Jira-Backlogs zu vereinfachen?
Schreibe einen Kommentar