Mandat, Stakeholder-Map, Kick-off. Das war die Grundlage, jetzt läuft das Projekt. Und damit kommen die Fragen, die sich erst im Alltag stellen: Wie halte ich das Backlog sauber? Wie kommuniziere ich mit Gremien, die plötzlich neue Anforderungen mitbringen? Und was tue ich, wenn niemand entscheiden will?

Hier fünf Bereiche aus der Arbeit als Product Owner:

1. Daueraufgabe Backlog-Management

Ein Backlog wächst. Immer. Neue Wünsche, Prioritäten, Anforderungen. Um nicht den Überblick – und damit die Kontrolle über das Projekt, zu verlieren – muss die vorgebeugt werden.

Es gilt das Grundprinzip: Priorität nach Wert, nicht nach Lautstärke des Absenders.

• Regelmäßiges Refinement: Anforderungen schärfen, schätzen, einordnen

• Priorisierungslogik früh festlegen (z.B. MoSCoW oder einfache Werteinstufung)

• Anforderungs-Inflation aktiv verhindern: jede neue Anforderung verdrängt eine andere

• User Stories für Hochschul-Kontext formulieren: Wer nutzt die Seite und wozu?

Kernfrage im Verlauf: Was bringt dem Nutzer den größten Mehrwert – jetzt, im nächsten Sprint?

2. Stakeholder-Kommunikation im laufenden Betrieb

Auf einem sorgsam gelegten Fundament kommen schon bald nach dem Kick-Off die ersten Nachfragen und Nachforderungen. Die Stakeholder-Arbeit wird intensiver.

So kann es gut funktionieren:

• Sprint Review: Das ist das zentrale Format für Stakeholder. Keine Folien, keine Statusberichte – funktionierende Ergebnisse zeigen. Was man sieht, versteht man. Was man liest, interpretiert man.

• Reporting schlank halten: Ein regelmäßiges, kurzes Format reicht. Wer zu viel berichtet, erzeugt mehr Rückfragen, nicht weniger.

• Nein sagen: Gehört zur Rolle. Aber ein Nein ohne Begründung erzeugt Widerstand – ein Nein mit Alternative kommt meistens durch.

• Erwartungen korrigieren: Lieber früh und unbequem als spät und dramatisch. Mid-project-Korrekturen sind normal.

• Gremien, Senate, Beiräte: Wollen eingebunden sein, auch ohne operative Rolle. Festen Rhythmus finden – und daran festhalten.

3. Hochschultypische Störquellen

Wer noch nie ein Projekt an einer Hochschule gemacht hat, unterschätzt das. Aber es hilft, um sie zu wissen. Dies sind typische Störquellen:

Man sollte Störquellen immer benennen und sie nicht ignorieren. Am Besten in den Meetings und unbedingt im Backlog als Risiken sichtbar machen.

4. Zusammenarbeit mit dem Scrum Master

Product Owner und Scrum Master sind keine Doppelspitze – sie haben verschiedene Verantwortlichkeiten.

• Product Owner: Was wird gebaut, in welcher Reihenfolge?

• Scrum Master: Wie arbeitet das Team, was blockiert es?

• Impediments gehören dem Scrum Master – der Product Owner eskaliert, löst nicht selbst

• Das Team vor externem Druck schützen: Direkt-Anfragen an Entwickler unterbinden

• Velocity als Planungsbasis: realistisch einschätzen, nicht schönrechnen

5. Fortschritt sichtbar machen

„Wie weit seid ihr eigentlich?" – irgendwann fragt das jemand. Kurz vor der Senatssitzung, nach drei Wochen Funkstille, oder weil die Hochschulleitung plötzlich ein Update will. Diese Tools, helfen:

• Inkremente zeigen: Eine funktionierende Teilseite sagt mehr als zehn Folien. Was man klicken kann, überzeugt – was man lesen muss, erzeugt Rückfragen.

• Burnup-Chart: Für Nicht-Techniker das zugänglichste Format. Gesamtumfang gegen erledigten Anteil – man sieht sofort, ob das Projekt in der Spur ist.

• Meilensteine vs. Sprint-Ergebnisse: Beides kommunizieren, aber nicht vermischen. Meilensteine sind strategische Ankerpunkte, Sprint-Ergebnisse operative Lieferungen.

• Transparenz zahlt sich aus: Wer auch über Verzögerungen offen kommuniziert, baut mehr Vertrauen auf als jemand, der nur Erfolge meldet.

Checkliste für einen gesunden Projektverlauf:

• Wird der Backlog regelmäßig gepflegt und priorisiert? ✓

• Werden die Stakeholder im Sprint-Rhythmus informiert? ✓

• Werden die Scope-Änderungen dokumentiert und bewertet? ✓

• Ist die Team-Velocity realistisch? ✓

• Sind die Risiken im Backlog sichtbar? ✓

Im nächsten Artikel der Reihe: Wie der Product Owner den Go-Live vorbereitet – und warum das Deployment (die Liveschaltung) erst der Anfang ist.