Beyond the backlog: Scrum managen – Längerfristige Planung mit Jira Roadmaps

Viele aus der agilen Community zucken bei diesem Titel wahrscheinlich bereits zusammen. „Scrum managen“ – bitte was? Denn Scrum-Teams werden nicht gemanagt.
Scrum als agiles Framework rückt das Team in den Mittelpunkt sämtlicher Produkt- und Projektaktivitäten. Hierbei macht der Scrum Guide deutlich, dass das Team, bestehend aus Product Owner, Scrum Master und dem Dev-Team eigenverantwortlich arbeitet: „Es (das Team) ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert.“ (Vgl. German Scrum Guide 2021)

Und auch die Sprint-Planung liegt, nach dem Scrum Guide, in der Eigenverantwortung des Teams: „Im Gespräch mit dem/der Product Owner wählen die Developer Einträge aus dem Product Backlog aus, die in den aktuellen Sprint aufgenommen werden sollen“, um das Sprintziel für den gewählten Sprintzeitraum zu erreichen.

Die Pflege und Priorisierung des Backlogs liegt hierbei ganz klar in der Verantwortung der Person in der Rolle des Product Owners (kurz PO), unterstützt durch den/die Scrum Master. In der Praxis stellt genau diese Tätigkeit eine der elementarsten im ganzen Scrum-Prozess dar. Denn ein gut sortiertes Backlog mit einem klaren Produktziel schafft Klarheit und Transparenz für das Scrum-Team und auch für weitere Stakeholder.

Der heilige Gral: Ein gutes Backlog

Das Füllen des Backlogs sowie die Pflege und die initiale Priorisierung liegen beim PO. Man kann diese Tätigkeit fast als Königsdisziplin im Scrum-Prozess beschreiben, baut doch der Erfolg des Produkts und auch das Gelingen des Sprints auf der Güte des Backlogs auf. Und auch in der Praxis zeigt sich, wie mächtig die Auswirkungen der Tätigkeiten des/der POs hier sind. So ist doch, wenn man auf ebenfalls nach Scrum arbeitende Menschen trifft, oft die erste Frage: „Und – wie ist euer/e PO?“. An die Rolle des POs wird auf dem Papier „nur“ die Erwartung gestellt, die unterschiedlichen Anforderungen an das Produkt bezogen auf Größe, Wert und möglicher Risiken zu evaluieren und im besten Fall anhand der Formel

(Value + Risk Exposure) / Size = Order Rank

ins Backlog einzusortieren (vgl. Scrum.org PSPO I training deck).

Easy oder? Puh!

Backlog Management ist Stakeholder Management

In der Praxis sind es jedoch genau die Tätigkeiten, die nirgendwo ausführlicher beschrieben sind, die Product Owner an ihre Grenzen bringen können. Auch in dedizierten Scrum-Trainings und Schulungen kann nur bedingt auf die Fülle von Methoden und Techniken zur Erstellung und Pflege eines Backlogs eingegangen werden: „There are many techniques beyond Scrum to help create and order Product Backlogs.“ (vgl. scrum.org PSPO I Training Deck)

Vor allem Scrum-Teams, die in Organisationen und Unternehmen eingebunden sind, können oft nicht als autarke Einheit agieren, sondern haben Abhängigkeiten. Diese Abhängigkeiten sind vielschichtig und einerseits natürlich technischer Natur. Beispielsweise Release-Zyklen, Datenstrecken oder Schnittstellen, die von und mit anderen Teams genutzt werden. Andererseits hängt das Backlog aber vor allem an fachlichen Anforderungen, die konkret durch Personen, dem Management oder Fachbereichen gestellt werden.

Diese Anforderungen in Form von Stakeholder Management aufzunehmen, stetig zu re-diskutieren, zu priorisieren und mit den oben beschriebenen Anforderungen an das Produkt selbst zu matchen, erleben viele POs in der Praxis als Zerreißprobe.

Und das neben Fragestellungen, die vor allem in größeren Organisationen einem PO oft on top als „Projektleiter“ aufgeladen werden: Budgetplanung für das nächste Jahr sowie Personal- und Ressourcenplanung.

Das Backlog hinter dem Backlog

Viele POs behelfen sich in der Praxis mit dem, was sie seit Jahren kennen und können: Excel-Listen. So ist es oft gelebte Selbstverständlichkeit, neben dem Backlog noch eine (Excel-)Liste mit Prioritäten zu pflegen, in der To Dos oder Punkte aufgeführt werden, die mal zu konkreten Anforderungen an das Produkt selbst werden könnten.

Oder auch gern gesehen: Eine Liste, die das Backlog spiegelt und für die Stakeholder verständlich und zugänglich macht. Diese Storys in Jira sind schließlich „schrecklich technisch“ und man kann „in dieser Liste gar nicht sehen“, wann die gestellte, eigene Anforderung umgesetzt ist.

In vielen Produkt- und Projektteams sind Excellisten mittlerweile durch visuelle (Miro) Boards ersetzt worden. Denn diese bieten bereits eine Jira-Integration, sodass Storys und Tickets einfach verlinkt werden können und man im besten Fall ein Board nutzen kann, um Anforderungen sowie Prios mit Stakeholdern und Team zu besprechen. Die Doppelpflege neben dem Jira Backlog ein Miro-Board zu verantworten, bleibt für den/die PO allerdings auch hier.

Visualisierung als Schlüssel

Ein tolles Feature, um diese unterschiedlichen Anforderungen zu vereinen und eine wirkliche Übersicht ohne Doppelpflege zu schaffen, ist Jira Roadmaps. Mit Roadmaps kann gerade in langlaufenden Projekten die Arbeit für mehrere Monate im Voraus auf Epic-Ebene geplant und visualisiert werden.

(Quelle: https://www.atlassian.com/software/jira/guides/roadmaps/basic-roadmaps)

Epics beschreiben hierbei größere Arbeitspakete, die als eine Einheit angesehen werden und die in weitere kleinere, konkrete Arbeitsschritte heruntergebrochen werden können. Eben diese konkreten Arbeitsschritte sind dann als Storys, Tasks oder Bugs die Grundlage für die Arbeit der Entwickler:innen.

Jira Roadmaps ermöglicht es, die anstehende Planung für externe Stakeholder visualisierbar und besprechbar zu machen, ohne ein zusätzliches Tool/eine zusätzliche Liste pflegen zu müssen. Gleichzeitig bietet sich auch die Option, Abhängigkeiten durch Verknüpfungen sichtbar zu machen. So wird auch für das Entwicklungsteam schnell klar, welche Features Abhängigkeiten zueinander aufweisen und deshalb in einer bestimmten Reihenfolge entwickelt werden sollten.

Durch die Verknüpfung einer Story mit dem entsprechenden Epic füllt sich die Roadmap automatisch und synchronisiert sich laufend. So kann immer tagesaktuell nach dem Fortschritt oder anderen Merkmalen (Assignee, Status, Label oder Issue Type) gefiltert werden. Und auch die aktuellen Sprints oder zukünftigen Sprints können in der Roadmap abgebildet werden.

Roadmaps sind eine Möglichkeit für das Team, den eigenen Fortschritt zu tracken, und unterstützen den/die PO gleichzeitig darin, das Big Picture durch eine gute Visualisierung ohne Doppelpflege an die Stakeholder zu vermitteln.