Wie Sie "Meta"-Sprints in Jira verwenden, um Ihren Scrum-Prozess zu vereinfachen

Viele Unternehmen nutzen Jira, um ihren Backlog zu organisieren und um Sprints zu planen. Aufgrund von Einschränkungen in der Software und dem, was im Scrum-Alltag passiert, entstehen dadurch einige Probleme, für die ich einen Workaround präsentiere, der sie während meiner Zeit als Product Owner gelöst hat. Dieser Artikel wurde größtenteils automatisiert aus dem Englischen übersetzt. 

Derzeit verbringe ich einen großen Teil meiner Arbeitszeit als Berater in einem Scrum-Team eines großen Telekommunikationsunternehmens.

Ich konzentriere mich hauptsächlich darauf, ihnen beim Bau von Modulen und Komponenten für ihre Neos CMS-Installation zu helfen. Aber als Teil ihres Teams verfolge ich auch genau, wie sie mit Scrum und den dazugehörigen Tools arbeiten.

In den letzten 6 Jahren habe ich als Product Owner und in anderen Scrum-Rollen in einer Agentur gearbeitet. Ich habe viel gelernt und auch gute Lösungen für die Probleme gefunden, die man hat, wenn man versucht, eine synchrone digitale Darstellung seiner Prozesse zu haben. Das Konzept, das ich erläutern werde, sollte auch mit jedem anderen Tool, das die Umsetzung von Geschichten in Sprints unterstützt, perfekt funktionieren.

In der Agentur arbeiteten wir auch mit Jira zusammen, und ich musste sicherstellen, dass unsere Kunden und mein Team die gemeinsamen Jira-Boards ansehen und verstehen konnten, was aktuell geschieht und was jeder von ihnen zu tun hat. Ich wollte auch die Möglichkeit von Fehlern minimieren, da dies zu Irrtümern, zum Verlust des Überblicks über wichtige Aufgaben und schließlich auch zu einem zunehmenden Arbeitsaufwand für mich geführt hätte, um den Gesamtüberblick zu behalten.

Jeder Kunde hat sein eigenes Board, auf dem er sein Backlog, Aufgaben, die vorbereitet werden, und Aufgaben, an denen gearbeitet wird, einsehen kann. Sie würden in ihrem Vorstand Prioritäten setzen und diese mit mir synchronisieren, so dass wir an den wichtigsten und wertvollsten Aufgaben für ihr Projekt arbeiten könnten.

Intern hatten wir ein Board, das die Aufgaben aller Kunden (5+), für die mein Team gearbeitet hat, zusammenfasst. Sie brauchten einen Weg, um sofort zu verstehen, was als nächstes zu tun war und worum sie sich bei den Verfeinerungen und Planungen kümmern mussten. Ich hätte ihnen immer sagen können, was als nächstes zu tun ist, aber das hätte bedeutet, dass ich mich an alles hätte erinnern müssen. Sie würden auch ein Problem haben, wenn ich nicht da bin. Deshalb habe ich über zwei Jahre mit unseren Kunden und dem Team an mehreren Iterationen von "Meta“-Sprints gearbeitet, die die Geschichten in unserem Vorstand so organisieren sollten, dass sie für alle Beteiligten Sinn machen. Am Ende hatte ich eine Struktur, die für alle funktionierte, und ich brauchte selten jemandem zu sagen, wo neue Geschichten hinkommen sollten oder woran ich in den Sprint-Meetings arbeiten sollte. Ich musste nur sicherstellen, dass ich dem gemeinsamen Board Priorität einräumte, um sicherzustellen, dass die Geschichten jedes Kunden an der richtigen Stelle im Verhältnis zueinander standen, und um einen guten Überblick darüber zu behalten, welche Geschichten eine hohe Priorität hatten.

Bei dem genannten Unternehmen arbeiten wir derzeit nur an einem Projekt, das jedoch eine sehr hohe Komplexität mit vielen Komponenten, Abhängigkeiten zu anderen Teams und Beteiligten aufweist. Während der ersten paar Planungssitzungen und Verfeinerungen wurde mir klar, dass sie im Grunde genommen die gleichen Probleme hatten wie wir bei unserer Agenturarbeit. Die Leute sind sich nicht immer sicher, wo sie die Geschichten hinstellen sollen, woran sie in einer Sitzung arbeiten sollen, und es besteht eine hohe Abhängigkeit vom Product Owner. Und es gibt ein andauerndes Problem mit Jira, das zu Problemen führen kann, wenn man einen Sprint beendet und die nicht beendeten Geschichten mit den bereits in den nächsten Sprint gesetzten vermischt werden. Ich verstehe aus technischer Sicht, dass es für Jira schwierig ist, die richtige Stelle für jede Geschichte zu finden, besonders wenn man sie mit mehreren Boards organisiert, aber es ist immer noch ärgerlich und kann viel Zeit kosten, die Dinge wieder richtig zu sortieren. Das ist noch schlimmer, wenn man das ganze Team dort sitzen und warten lässt.

Um meine Sprints visueller zu erklären, habe ich einen einfachen Jira-Cloud Trial eingerichtet und einige Sprints und Geschichten erstellt, die meinem zukünftigen Raketenstart helfen werden, zum Mond zu fliegen und mich reich zu machen.

Zuerst werde ich fast ganz unten starten, knapp über dem "Backlog".

Wenn Sie viele Jahre lang an Projekten arbeiten, kann sich Ihr Backlog mit allen möglichen Aufgaben füllen. Manche Leute sagen, man solle einfach alles entfernen, was ein bestimmtes Alter hat, aber wenn man mit mehreren Kunden arbeitet, kann das zu diplomatischen Problemen führen, für die es sich manchmal nicht lohnt zu kämpfen. Deshalb habe ich akzeptiert, dass wir eine gewisse Anzahl von "Zombie"-Geschichten haben, die irgendwann einmal passieren könnten oder auch nicht. Das hat mich dazu veranlasst, den ersten "Meta"-Sprint zu erstellen. Der "Upcoming" genannte (Dank an einen gewissen anderen PO, der einen besseren Namen als ich gefunden hat!) Dies trennt den üblichen Rückstand von Aufgaben, die in absehbarer Zukunft tatsächlich relevant sind, oder Aufgaben, die aufgrund der Entscheidung einiger Interessenvertreter vorübergehend aus der Priorität herausgefallen sind. Ich habe versucht, die Anzahl der Aufgaben in diesem Sprint unter 20 zu halten, um nicht den Überblick zu verlieren und einen weiteren "Zombie"-Rückstand zu erzeugen.

Wie Sie auf dem Screenshot sehen, könnten die Aufgaben im "Upcoming"-Sprint bereits Story-Punkte haben, da sie sogar aus einem bereits laufenden Sprint stammen können. Wenn sie irgendwann ihre Relevanz verlieren, dann ist es in Ordnung, sie in das Backlog zu legen oder sie einfach zu schließen.

Sie sehen, dass ich das Sprint-Zielfeld benutzt habe, um zu klären, worum es beim "Meta"-Sprint geht. Das ist ein wichtiger Teil, da ich diese Texte mehrmals wiederholt und mit jedem Kunden überprüft habe, ob es für ihn Sinn macht. Ich wollte sicher sein, dass ihre neuen und alten Geschichten immer an die richtige Stelle kommen.

Der nächste "Meta“-Sprint ist der "Refinement"-Spint. Er enthält alle Aufgaben, die in der nahen Zukunft gemacht werden sollten und die vom PO vorbereitet werden, um während der Verfeinerungssitzungen des Scrum-Teams mit Details gefüllt zu werden. In unserem Jira-Workflow befanden sich diese Stories im Schritt "Requirements Engineering".

Während dieser Sitzungen ging das Team einfach jede Aufgabe von oben nach unten durch und stellte sicher, dass jede Aufgabe ihre "Definition von Fertig" erfüllte. Viele Teams schätzen die Aufgaben während der Planungssitzungen, was mir nie gefallen hat. Eine Schätzung zu bekommen, kurz bevor ich eine Aufgabe in einen Sprint bringen wollte, hat mir viel Stress bereitet. Ich hatte fast keine Zeit, zu reagieren, wenn eine Aufgabe eine größere Schätzung erhielt, als ich oder die Beteiligten erwartet hatten. Und ich konnte nicht sicherstellen, dass alle Fragen, die während einer Schätzung auftauchen könnten, beantwortet werden konnten, bevor ein neuer Sprint gestartet wurde. Deshalb hatten wir während unserer zweiwöchigen Sprints zwei einstündige Verfeinerungssitzungen, und ich hatte genug Zeit, um mit den Stakeholdern Details oder Prioritäten zu besprechen und gegebenenfalls Aufgaben aufzuteilen. Und auch das Team hatte mehr Zeit, um technische Fragen zu lösen, die möglicherweise Hilfe von außen benötigen.

Wenn das Team in der Verfeinerungssitzung mit der Vorbereitung einer Aufgabe fertig war, würde diese Aufgabe Punkte haben und im Arbeitsablauf als "offen" markiert werden. Das bedeutet, dass sie jederzeit bearbeitet werden konnte, wenn sie in einem Sprint priorisiert wurde. Dies sollte die "Definition von bereit" in Scrum zusammen mit allen anderen Anforderungen, die Ihr Prozess an die Stories stellen könnte, darstellen. 

Ich hatte nun eine Menge Aufgaben an der Spitze des "Refinement"-Spints, mit denen ich als PO arbeiten konnte. Also habe ich die Aufgaben, bei denen ich mir sicher war, dass sie priorisiert werden können, in den nächsten "Meta“-Sprint namens "Priorisierung“-Sprints gestellt. 

Bei einigen Aufgaben wollte der Entscheider nur eine Einschätzung haben oder die Komplexität verstehen, bevor er eine Entscheidung trifft. Diese habe ich wieder in den "Upcoming“-Sprint gelegt und der verantwortlichen Person zugeordnet. Sie konnten sich dann auch entscheiden, sie wieder in den "Prioritäts“-Sprint zu geben. Das bedeutete, dass wir als Team an ihnen entsprechend der Priorität der Entscheiders/Kunden arbeiten konnten.

Wenn man diesen Sprint weit weg vom Backlog hat, verhindert man normalerweise, dass plötzlich eine Aufgabe drin ist, die gerade erstellt oder versehentlich von jemandem dort abgelegt wurde.

Als wir montags mit den Sprints begannen, habe ich immer sichergestellt, dass jeder Kunde in der Woche zuvor eine Aktivität in seiner Priorität zeigte, so dass ich wusste, dass ich mich beim nächsten Sprint auf die Liste verlassen konnte.

Am oberen Rand des Bildschirms sind die "normalen" Sprints zu sehen. Es gibt den derzeit aktiven Sprint, der die laufenden Aufgaben zeigt, und den leeren Sprint, der als nächstes kommt. Dieser sollte leer bleiben, bis man den aktuellen Sprint während der nächsten Planungssitzung beendet.

Wenn der aktuelle Sprint beendet ist, gehen alle noch nicht abgeschlossenen Aufgaben in den nächsten Sprint über und bleiben in Reihenfolge. Auf diese Weise können Sie leicht erkennen, welche Aufgaben noch nicht beendet sind, und Sie können überprüfen, ob sie in den nächsten Sprint gehen sollten. Manchmal sind die Aufgaben tatsächlich fertig, aber jemand hat vergessen, sie abzuschließen. Dies sollte eher überprüft werden, bevor man den alten Sprint abschließt, damit Ihre Metriken diese hart verdienten Story-Punkte zeigen.

Wenn dies erledigt ist, kann das Team nun das kleine Ziehen-Symbol am unteren Rand des Sprints verwenden, um die Aufgaben aus dem "Priorisierungs"-Sprint in den nächsten Sprint zu verschieben. Die Anzahl der Story-Punkte steigt, und das Team kann aufhören, wenn es glaubt, den von ihm gewählten Betrag erreicht zu haben.

Hier sehen Sie die gesamte Tafel mit allen Sprints:

Wenn Ihre Anzahl an Aufgaben größer wird, definieren Sie einige Filter im Board, die es Ihnen ermöglichen, Aufgaben zu erkennen, die sich im falschen Sprint befinden. Ein Filter, der nur die Aufgaben anzeigt, die noch nicht "fertig" sind, hilft Ihnen, sie aus den Sprints zu entfernen, in die sie nicht passen. Dasselbe gilt für andere Status und Schritte in Ihrem Workflow.

Ich habe jeden Monat ein wenig Zeit damit verbracht, meine Filter und mein Jira-Dashboard zu verbessern, damit ich schnellstmöglich Stories erkennen kann, die nicht an der richtigen Stelle sind. Zum Beispiel könnten Kunden "Bugs" erzeugen, die überwacht und behoben werden sollten. Aber wenn sie gestresst sind, könnten sie es in den falschen Sprint oder am Ende des Rückstands, wo niemand sie entdeckt, stecken. Oder ein Entwickler fügt eine Aufgabe in den Sprint ein, ohne jemandem davon zu erzählen. Ihr Dashboard sollte nur diese Art von Pannen anzeigen. Es geht nicht darum, den Leuten zu sagen, dass sie etwas falsch gemacht haben, sondern darum, sicherzustellen, dass alle synchronisiert sind.

Wenn Sie einen Schritt in Ihrem Arbeitsablauf haben, der zwei Dinge bedeuten kann, fügen Sie einfach einen weiteren Schritt ein und beseitigen Sie die Quelle der Verwirrung.

Bis vor kurzem fühlte sich dieses System für mich so natürlich an, dass ich nicht daran dachte, es aufzuschreiben. Jetzt habe ich das Gefühl, dass dies anderen Teams helfen könnte, Fehler und Verwirrung zu reduzieren und effektiver zu sein. Probieren Sie es in Ihrem Jira aus oder setzen Sie einen Versuch an.

Jedes Mal, wenn Sie das Gefühl haben, dass Dinge vermischt sind, die getrennt werden sollten, gehen Sie einen Schritt weg von Ihrem Thema und versuchen Sie, es in kleinere Teile zu zerlegen. Dann erobern Sie sie!

Wenn das der Fall ist, würde ich gerne von Ihren Erfahrungen wissen. Und wenn Sie ein ähnliches oder anderes System haben, das gut für Sie funktioniert, würde ich auch gerne mehr darüber erfahren.