Serviceentwicklung: Trans­parenz und Nachvoll­ziehbar­keit durch offene Roadmaps

„Public money, public code“ ist ein zentrales Mantra der Verwaltungsdigitalisierung. Was mit öffentlichem Geld entwickelt wird, soll offen sein und allen zur Verfügung stehen. Zugänglich zu machen, was bereits vorhanden ist, ist gut. Sichtbar zu machen, was als Nächstes entwickelt wird, ist noch besser – dafür nutzen wir offene Roadmaps.

„Arbeite offen“ ist einer der sechs Werte des DigitalService. Doch wie füllen wir ihn mit Leben? Das werden wir häufig gefragt. Hier folgt ein weiterer Teil der Antwort. Denn dass öffentlich finanzierte Software öffentlich sein sollte, haben wir bereits in unserem Beitrag über Open Source dargelegt. Das bezieht sich auf das, was bereits entwickelt wurde. Seit Herbst 2025 macht der Servicestandard über die „Standardverordnung Onlinezugang“ Open Source zur Vorgabe. Nun müssen Serviceteams begründen, warum sie proprietäre statt Open-Source-Software beschaffen oder entwickeln wollen.

Darüber hinaus zu zeigen, was für die Weiterentwicklung als Nächstes geplant ist, macht jenseits der Nachnutzung zukunfts­orientierte Beteiligung möglich. In der Entwicklung digitaler Produkte und Services ermöglichen offene Roadmaps dies. Damit sind sie ein wichtiger Beleg für offenes Handeln. Als staatliche Einheit wollen wir und die Bundesbehörden, mit denen wir zusammenarbeiten, transparent machen, woran wir derzeit arbeiten.

Im Folgenden zeigen wir, was offene Roadmaps sind, warum und wie wir sie veröffentlichen und wie andere es auch einfach machen können.

Roadmaps, die mittlerweile auch der Duden kennt, sind Pläne für die zukünftige Entwicklung von Technologien und Produkten. Wenn wir Software offen entwickeln, gehören offene Roadmaps dazu. Sie zeigen an einem für alle zugänglichen Ort:

• woran das Team derzeit arbeitet,
• was als Nächstes ansteht,
• und was bereits abgeschlossen ist.

Die Idee ist nicht neu. Verwaltungen in Großbritannien, Kanada und den USA leben es vor. Eine gut gepflegte Übersichtsseite kennt noch weitere internationale Beispiele. Unternehmen wie GitHub, Obsidian oder Trello setzen ebenfalls schon lange auf offene Roadmaps.

Für Projekte des DigitalService begannen wir Anfang 2025 erstmals öffentlich kundzutun, was bereits existiert und woran wir noch arbeiten. Für das Rechtsinformationsportal entwickelten wir die erste knappe Übersicht über alle Aktivitäten. Nach wenigen Monaten veröffentlichten wir ähnliche Übersichten für den Digitalcheck und den Servicestandard. Einige Monate später folgte ein Überblick über die Produktentwicklung im Projekt „Zugang zum Recht“.

Unsere Teams hatten gute Gründe ihre Entwicklungspläne offenzulegen:

Offene Roadmaps machen es für Dritte vorhersehbar, was als Nächstes veröffentlicht wird, wie sich ein Service verändert und welches das nächste Feature ist. Diese Transparenz ist bei staatlichen Angeboten besonders wichtig, denn das Geld der Steuerzahlenden sollte nachvollziehbar und sinnvoll eingesetzt werden. Einsehbare Pläne führen zu ehrlichen Gesprächen mit internen Stakeholdern und Auftraggebern. Sie machen die erwartbare Umsetzung von Projekten greifbar und jederzeit abrufbar.

Zugleich wirkt der Transparenzgedanke auch in Richtung der Nutzenden und externen Stakeholder. Durch das Offenlegen der Pläne werden die aktuelle und die zukünftige Arbeit nachvollziehbar und jederzeit selbstständig einsehbar. Das baut Vertrauen auf, ermöglicht gezielte Mitarbeit und öffnet eine weitere Stelle im Entwicklungsprozess für Feedback.

In Angeboten der Wirtschaft sehen wir offene Roadmaps insbesondere dann, wenn Veränderungen an einem Service viele weitere Akteure betreffen. So können diese sich früh darauf einstellen oder bereits in einem frühen Stadium daran mitwirken. Hierdurch entstehen neue Ideen, Kooperationsmöglichkeiten und das Umsetzungsteam kann durch dieses Feedback seine Prioritäten besser setzen.

Eine Roadmap ermutigt ein Team, sich regelmäßig damit auseinanderzusetzen, welche Ergebnisse es erzielen will und wie es diese erreichen möchte. Offene Roadmaps ermöglichen all dies und stellen die Ergebnisse, gemeinsam mit einer Dokumentation dessen, was bereits passiert ist, offen zur Verfügung. Folglich entsteht eine Service­historie, wodurch auch in Zukunft nachvollziehbar bleibt, woran und wieso gearbeitet wurde. Somit schließen wir die Lücke zwischen Vision und veröffentlichtem Code.

In den letzten Jahren erarbeiteten Teams beim DigitalService verschiedene Ausprägungen von offenen Roadmaps. Wir hießen die Kreativität einzelner Teams bewusst willkommen, denn das ermöglichte uns zu verstehen, welche Funktionen auf welche Bedürfnisse reagieren. Im Frühjahr dieses Jahres glaubten wir, es sei an der Zeit, diese Arbeiten zu vereinheitlichen.

In nunmehr fünf Projekten konnten wir vier wiederkehrende Elemente beobachten:

Direkt sollte ersichtlich sein:

• wann die Roadmap zuletzt aktualisiert wurde,
• wie häufig sie aktualisiert wird,
• wie man das Team kontaktieren kann, um Feedback zu geben,
• was der Kontext ist – was Vision, Mission, angestrebte Value Proposition des Services sind.

Diese Elemente ermöglichen es Interessierten, sich schnell in die Roadmap und den Kontext einzuarbeiten. Wir empfehlen, offene Roadmaps in Bereichen wie „Über den Service“ von Angeboten zu platzieren.

Die Roadmap besteht aus:

• In Arbeit / jetzt: Dinge, an denen das Team gerade arbeitet
• In Zukunft / später: der Backlog mit bislang noch unerledigten Aufgaben
• Fertig: die bereits umgesetzten und erledigten Aufgaben

Wir schlagen für noch nicht abgeschlossene Aufgaben eine Kachelansicht vor. Um für eine breite Zielgruppe verständlich zu sein, sollten Inhalte in einfacher Sprache formuliert sein. Der Titel einer Kachel sollte jeweils das Ziel beschreiben. Darunter sollte ein kurzer Text die Aufgabe beschreiben.

Für bereits erledigte Aufgaben eignet sich ein knapper Zeitverlauf. Darin sollten in chronologischer Reihenfolge Versionen, Veröffentlichungen und umgesetzte Funktionen ersichtlich sein. Idealerweise sollten die jeweiligen Features über Links einsehbar sein.

Der Inhalt muss durchsuchbar und strukturiert sein, damit Lesende sich schnell zurechtfinden und Änderungen nachvollziehen können.

Agile Software-Entwicklung lebt davon, immer auf Änderungen reagieren zu können. Zugleich ist eine Roadmap keine Funktion eines Services, der den Nutzenden primär Mehrwert bietet. Darum sollen diese Entwicklungspläne einfach anzupassen und zu pflegen sein. So werden dem Serviceteam keine unnötigen Hürden in den Weg gelegt. Es kann während der Umsetzung lernen, den aufgestellten Plan kontinuierlich reflektieren und entsprechend anpassen.

Eine Roadmap entfaltet ihre volle Kraft, wenn Teams nicht nur zeigen, was sie bauen, sondern auch, welche Wirkung sie erzielen wollen. Sind für den Service bereits Wirkungsziele formuliert, sollte jeder Roadmap-Eintrag im Text deutlich machen, auf welche Metrik die Aktivität einzahlen soll und welche Kennzahl man erreichen möchte. Auch in diesem Fall verknüpft mit einem transparenten und offenen Reporting dieser Kennzahlen. Dies ist die nächste Entwicklung, die wir für das Roadmap-Pattern andenken und bereits skizziert haben.

Zunächst für die Teams beim DigitalService entwickelt, machen wir jetzt unser Roadmap-Pattern öffentlich. Es ist für das KERN Designsystem entwickelt und nutzt die visuelle Sprache der Digitalen Dachmarke. Das Pattern ist modular aufgebaut und lässt sich daher gut an servicespezifische Gegebenheiten anpassen.

Beim DigitalService sind gerade mehrere Serviceteams damit beschäftigt, ihre bestehenden offenen Roadmaps an das Pattern anzupassen. Die erste überarbeitete Veröffentlichung war die Seite „Daran arbeiten wir“ des Zentrum für Legistik. Als Zweites folgte eine gleiche Übersicht auf dachmarke.gov.de. Weitere Angebote des Bundesdigitalministeriums folgen in Kürze.

Noch immer sind offene Roadmaps für Verwaltungsangebote selten. Insbesondere bei Basiskomponenten, die wiederum von vielen Teams genutzt werden, sind sie essenziell. Aufgrund der Abhängigkeit ist das Feedback der integrierenden Teams besonders wichtig. Positive Beispiele hierfür sind die Roadmap der Übermittlungskomponente FIT-Connect sowie die des KERN Designsystems selbst. Auch existieren Roadmaps für andere große Transformationsvorhaben wie die Digitalisierung der Sozialverwaltung.

Die Figma-Datei unseres aktuellen Stands des Patterns haben wir öffentlich gestellt. Wir sind im Austausch mit dem Team des KERN Designsystems, um das Pattern dort in Kürze auffindbar zu machen.

Wir sind daran interessiert, zu verstehen, welche Hürden Teams haben, wenn sie ihre Entwicklungspläne offen und nachvollziehbar bereitstellen wollen. Gerne teilen wir jenseits des Patterns weitere Argumentationshilfen.